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
