From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow SQL/plpgsql functions to accept record |
Date: | 2015-04-28 03:06:17 |
Message-ID: | 553EF929.6080903@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/27/2015 10:35 PM, Jim Nasby wrote:
> On 4/25/15 4:50 PM, Tom Lane wrote:
>> Well, we already support local variables of type RECORD in plpgsql, so
>> it's not immediately clear to me that function arguments would be much
>> worse. There are a lot of deficiencies with the RECORD-local-variable
>> implementation: if you try to change the actual RECORD type from one
>> call
>> to the next you'll probably have problems. But it seems like we could
>> avoid that for function arguments by treating RECORD as a polymorphic
>> argument type, and thereby generating a separate set of plan trees for
>> each actual record type passed to the function within a given session.
>> So in principle it ought to work better than the local-variable case
>> does
>> today.
>>
>> In short I suspect that Jim is right and this has more to do with a
>> shortage of round tuits than any fundamental problem.
>
> I took a stab at plpgsql and it seems to work ok... but I'm not sure
> it's terribly valuable because you end up with an anonymous record
> instead of something that points back to what you handed it. The
> 'good' news is it doesn't seem to blow up on successive calls with
> different arguments...
>
>> Not sure about the SQL-function case. That might be even easier because
>> functions.c doesn't try to cache plans across queries; or maybe not.
>
> This on the other hand was rather easy. It's not horribly useful due
> to built-in restrictions on dealing with record, but that's certainly
> not plsql's fault, and this satisfies my initial use case of
>
> create function cn(record) returns bigint language sql as $$
> SELECT count(*)
> FROM json_each_text( row_to_json($1) ) a
> WHERE value IS NULL $$;
>
> Attached patches both pass make check. The plpgsql is WIP, but I think
> the SQL one is OK.
My point remains that we really need methods of a) getting the field
names from generic records and b) using text values to access fields of
generic records, both as lvalues and rvalues. Without those this feature
will be of comparatively little value, IMNSHO. With them it will be much
more useful and powerful.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-04-28 03:24:50 | Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property? |
Previous Message | Jim Nasby | 2015-04-28 02:49:34 | Re: Temporal extensions |