Re: Anonymous code blocks

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)

In response to

Browse pgsql-hackers by date

  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]