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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to