Dyamic updates of NEW with pl/pgsql
in [PgSql]
|
Prev: patch (for 9.1) string functions
Next: [HACKERS] Access violation from palloc, Visual Studio 2005, C-language function
From: Andrew Dunstan on 13 Mar 2010 09:20 Pavel Stehule wrote: > I see some disadvantages > > a) non intuitive name - hstore is very specific name > b) effectivity (mainly inside trigger body) - plpgsql specific > construct can be 10x faster. > > I would to see hash tables in core too, but I don't think so it is > good solution for record updating. > > Yes, the use of hstore that I illustrated upthread is a workaround, not a real solution. Having said that, it works pretty darn well in my experience. I think we need some operator on records+strings for this functionality. Something like (say we used "->"): foo := 'myfieldname'; myrec->foo := 'bar'; quux := myrec->foo; I agree that if we were to include hstore in core it needs a better name (we do need to be careful about this stuff, I know the name "bytea" confuses even seasoned users). And in any case, before we rush headlong into incorporating hstore, we should consider its limitations, particularly the fact that it's a flat map, rather than something that composes like, say, some sort of JSON object. There have certainly been times when I would have appreciated the latter. (But in case there is any misunderstanding, let me say that hstore is really great and useful. I have thanked Oleg and Teodor and Andrew many times in my head.) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 13 Mar 2010 11:40 Andrew Dunstan <andrew(a)dunslane.net> writes: > I think we need some operator on records+strings for this functionality. I don't see how you're going to do that without utterly compromising the type system. It's not so horrid to do this type of thing in plperl, pltcl etc because you've already bought into an "everything is text" worldview when you use those languages. But plpgsql is strongly typed just like SQL is, and I don't think we should undo that. (This will also be my main objection to letting hstore into core. It has not solved the problem of handling real datatypes.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Merlin Moncure on 13 Mar 2010 11:55 On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > (This will also be my main objection to letting hstore into core. > It has not solved the problem of handling real datatypes.) Is this problem solvable then? Some variant of this question comes up almost weekly. It just doesn't seem right that you should have to write N trigger functions over N tables to a highly related operations. pl/perl is a huge dependency to bring in just to able to do things this. I understand hacking things through the text route is possibly not a direction should be encouraged...but is there an alternative? Is it theoretically possible to write functions that can switch out types based on context while still having static plans? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 13 Mar 2010 11:58 2010/3/13 Tom Lane <tgl(a)sss.pgh.pa.us>: > Andrew Dunstan <andrew(a)dunslane.net> writes: >> I think we need some operator on records+strings for this functionality. > > I don't see how you're going to do that without utterly compromising the > type system. > > It's not so horrid to do this type of thing in plperl, pltcl etc because > you've already bought into an "everything is text" worldview when you > use those languages. Â But plpgsql is strongly typed just like SQL is, > and I don't think we should undo that. > strong typing isn't problem for field updating - and we can do necessary conversion to target type - for simple expression (without cached plan). I like some var = record[expression]; record[expression] = var; I don't thing so current static naturel of plpgsql is impossible problem. It needs just more inteligent assign statement. Pavel > (This will also be my main objection to letting hstore into core. > It has not solved the problem of handling real datatypes.) > > Â Â Â Â Â Â Â Â Â Â Â Â regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 13 Mar 2010 11:59
Merlin Moncure <mmoncure(a)gmail.com> writes: > On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> (This will also be my main objection to letting hstore into core. >> It has not solved the problem of handling real datatypes.) > Is this problem solvable then? I don't know, but hstore hasn't even tried. We should be very slow to institutionalize a "smash everything to text" approach in core. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |