Re: Dyamic updates of NEW with pl/pgsql

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

In response to

Responses

Browse pgsql-hackers by date

  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