From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, depesz(at)depesz(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Dyamic updates of NEW with pl/pgsql |
Date: | 2010-03-13 14:20:41 |
Message-ID: | 4B9B9F39.9090200@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-03-13 14:56:18 | Re: Warning about invalid .pgpass passwords |
Previous Message | Jaime Casanova | 2010-03-13 04:48:24 | pq_setkeepalives* functions |