Re: Dyamic updates of NEW with pl/pgsql

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Dyamic updates of NEW with pl/pgsql
Дата
Msg-id 162867791003121059x454713faxf21b663dd56ca9a9@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Dyamic updates of NEW with pl/pgsql  (strk <strk@keybit.net>)
Ответы Re: Dyamic updates of NEW with pl/pgsql  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
2010/3/12 strk <strk@keybit.net>:
> On Fri, Mar 12, 2010 at 10:47:45AM -0800, David Fetter wrote:
>> On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote:
>> > 2010/3/12 David Fetter <david@fetter.org>:
>> > >
>> > > This is, by the way, an excellent argument for including hstore in
>> > > core in 9.1. :)
>> >
>> > I like it - but it looking little bit strange - I thinking we need
>> > only one function (maybe with some special support from pl executor)
>> >
>> > begin
>> >   update_field(NEW, 'field', value);
>> >   ....
>>
>> This doesn't seem like a terribly useful addition, it being specific
>> to PL/pgsql.  Then there's the quoting issue, which the above doesn't
>> quite address.  Putting hstore in would let all the other PLs use it,
>> to the extent that they need such a thing. :)
>
> Plus pure SQL use !
> I was considering using hstore for a table value too for
> a form of "historic table". Just to say I'd also be happy with
> it being core in pgsql :)
>

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.

Regards
Pavel


> --strk;
>
>  ()   Free GIS & Flash consultant/developer
>  /\   http://strk.keybit.net/services.html
>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Server crash with older tzload library
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Server crash with older tzload library