Re: Dyamic updates of NEW with pl/pgsql

From: Florian Pflug <fgp(dot)phlo(dot)org(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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-16 21:53:46
Message-ID: 4B9FFDEA.50002@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 13.03.10 18:38 , Tom Lane wrote:
> I wrote:
>> ... Maybe it would work to devise a notation that allows fetching
>> or storing a field that has a runtime-determined name, but
>> prespecifies the field type. Actually only the "fetch" end of it is
>> an issue, since when storing the field datatype can be inferred
>> from the expression you're trying to assign to the field.
>
> [ after more thought ]
>
> I wonder if it could work to treat the result of a
> "record->fieldname" operator as being of UNKNOWN type initially, and
> resolve its actual type in the parser in the same way we do for
> undecorated literals and parameters, to wit * you can explicitly cast
> it, viz (record->fieldname)::bigint * you can let it be inferred from
> context, such as the type of whatever it's compared to * throw error
> if type is not inferrable Then at runtime, if the actual type of the
> field turns out to not be what the parser inferred, either throw
> error or attempt a run-time type coercion. Throwing error seems
> safer, because it would avoid surprises of both semantic (unexpected
> behavior) and performance (expensive conversion you weren't expecting
> to happen) varieties. But possibly an automatic coercion would be
> useful enough to justify those risks.

This is more or less what I've done in my pg_record_inspect module, only
without parser or executor changes (it works with 8.4). The code can be
found on http://github.com/fgp/pg_record_inspect.

The module contains the function

fieldvalue(RECORD, field NAME, defval ANYELEMENT, coerce BOOLEAN)
RETURNS ANYELEMENT

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...

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2010-03-17 00:29:38 Re: Streaming replication, and walsender during recovery
Previous Message Tom Lane 2010-03-16 19:56:01 Re: Bug in 9.0Alpha4