From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: returning SETOF RECORD |
Date: | 2014-07-14 21:34:48 |
Message-ID: | 53C44CF8.2080501@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/14/2014 04:46 PM, Robert Haas wrote:
> On Mon, Jul 14, 2014 at 4:39 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> Is there any reasonable alternative? That is, if you have a function
>>> returning SETOF record, and the details of the record type aren't
>>> specified, is there anything you can do other than error out like
>>> this?
>> Not that I can see. What would you suggest?
> Dunno. Was hoping someone else had an idea. It'd certainly be nice
> to have some way of calling functions like this without specifying the
> shape of the return value, but I doubt there's a way to make that work
> without a lot of new infrastructure. For example, if a function could
> be called at the point where we need to know the record shape with a
> special flag that says "just tell me what kind of record you're going
> to return" and then called again at execution time to actually produce
> the results, that would be nifty.
>
> But mostly, I think it's slightly odd that the function gets called at
> all if nothing useful can be done. Why not just error out in the
> caller? So that made me wonder if maybe there is a way to do
> something useful, and I'm just not seeing it.
>
For json{b}, this only happens if you call json{b}_to_record{set}.
json{b}_populate_record{set} will always have the required info. The
downside of these is that you have to supply a value of a named type
rather than an anonymous type expression.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-07-14 21:40:26 | Re: view reloptions |
Previous Message | Jeff Janes | 2014-07-14 21:31:32 | Getting list of held lwlocks from debugger |