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
