Re: Anonymous code blocks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Petr Jelinek <pjmodos(at)pjmodos(dot)net>, 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:12:40
Message-ID: 14669.1253412760@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Yeah. The presented examples aren't tremendously convincing, as they
both beg the question "why not just do a SELECT?". It's also not
exactly apparent to me why redefining the behavior of SELECT in a
plpgsql function would be a better thing than having RETURN do it.

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.

BTW, what happens with the current patch if you try to do a RETURN?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2009-09-20 02:23:13 Re: operator exclusion constraints [was: generalized index constraints]
Previous Message David E. Wheeler 2009-09-20 02:08:13 Re: updated hstore patch