Re: Dyamic updates of NEW with pl/pgsql - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Dyamic updates of NEW with pl/pgsql
Date
Msg-id b42b73151003162008s126985d7ua34eaaf240025267@mail.gmail.com
Whole thread Raw
In response to Re: Dyamic updates of NEW with pl/pgsql  (Florian Pflug <fgp.phlo.org@gmail.com>)
Responses Re: Dyamic updates of NEW with pl/pgsql
List 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 by date:

Previous
From: Hitoshi Harada
Date:
Subject: Re: Bug in 9.0Alpha4
Next
From: KaiGai Kohei
Date:
Subject: [v9.1] access control reworks in ALTER TABLE