Re: Dyamic updates of NEW with pl/pgsql

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Dyamic updates of NEW with pl/pgsql
Дата
Msg-id b42b73151003162008s126985d7ua34eaaf240025267@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Dyamic updates of NEW with pl/pgsql  (Florian Pflug <fgp.phlo.org@gmail.com>)
Ответы Re: Dyamic updates of NEW with pl/pgsql  (Florian Pflug <fgp.phlo.org@gmail.com>)
Список pgsql-hackers
On Tue, Mar 16, 2010 at 5:53 PM, Florian Pflug <fgp.phlo.org@gmail.com> wrote:
> which returns the field named <field> from the record. The expected
> field type is specified by providing a default value in <defval> of the
> expected type. Since that argument's type is ANYELEMENT, just like the
> return type, the type system copes perfectly with the varying return
> type. You can choose whether to auto-coerce the field's value if it has
> a type other than <defval>'s type or whether to raise an error.
>
> So in essence I'm using the ANYELEMENT trick to get a poor man's version
> of your idea that doesn't require core changes.
>
> My post about this module got zero responses though...

Why should we use what you've already written when we can just write
it ourselves?  Next you are going to say you're already using it and
it works really well :-).

I think it's pretty cool.  Is it safe to have the main functions
immutable and not stable though?  Is there any benefit missed by not
going through pl/pgsql directly (I'm guessing maybe more elegant
caching)?  It's a little weird that you can return anyelement from
your function in cases that don't guarantee a type from the query.
Are there any downsides to doing that?

merlin


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

Предыдущее
От: Hitoshi Harada
Дата:
Сообщение: Re: Bug in 9.0Alpha4
Следующее
От: KaiGai Kohei
Дата:
Сообщение: [v9.1] access control reworks in ALTER TABLE