From: | Petr Jelinek <pjmodos(at)pjmodos(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: Anonymous code blocks |
Date: | 2009-09-20 02:39:22 |
Message-ID: | 4AB595DA.3020609@pjmodos.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane napsal(a):
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> Dimitri Fontaine wrote:
>>
>>> So here are the major points about this patch:
>>> - it's missing the returns declaration syntax (default value could be
>>> returns void?)
>>> - it would be much more friendly to users if it had a default output
>>> for queries, the returned object seems a good fit
>>>
>
>
>> Really? That wasn't my expectation at all. I expected that the code
>> would in effect be always returning void. I think you're moving the
>> goalposts a bit here. I don't think we need a RETURNS clause on it for
>> it to be useful.
>>
>
> I think adding onto DO capabilities is something we could do later
> if demand warrants. I'd prefer to underdesign it for starters than
> to encrust it with features that might not be needed.
>
Right, RETURNS can be added later without breaking any existing code for
users so no problem there (same goes for removing the requirement of
BEGIN ... END for example).
> BTW, what happens with the current patch if you try to do a RETURN?
>
Throws same error as function defined with RETURNS void.
--
Regards
Petr Jelinek (PJMODOS)
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-09-20 03:06:02 | Re: generic copy options |
Previous Message | David Fetter | 2009-09-20 02:23:13 | Re: operator exclusion constraints [was: generalized index constraints] |