Re: Anonymous code blocks

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

Hi,

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> 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.

Yes it'd be useful without it too, and this can come in later in the
game, granted too. Will continue review without it.

> Yeah. The presented examples aren't tremendously convincing, as they
> both beg the question "why not just do a SELECT?".

Where I want to go from those example are for the first case being able
to run SQL commands on a bunch of tables and return a 3 setof
(schemaname, tablename, check bool). The second one (server_version) is
intended to go in extension install script, in order to branch on the
server_version and behave accordingly, returning what it is that have
been done or sth useful.

But I didn't give it much time yet, and I'll confess it was the first
ideas coming in while playing with the feature. Proper ways to do things
with what's currently in the patch may come after some more playing.

> 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.

Well convenience for lazy DBA only, skipping the declaring of vars in a DO
command... it's following the idea that we might want not exactly
plpgsql in there, which I can see as a very bad one too, wrt code
maintenance and all. Maybe offering later a new PL intended at
"interactive" processing would better fit this line of thoughs.

> 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?

dim=# do $$begin return; end;$$;
ERROR: invalid typLen: 0
CONTEXT: PL/pgSQL function "inline" while casting return value to function's return type

dim=# do $$begin return 1; end;$$;
ERROR: RETURN cannot have a parameter in function returning void at or near "1"
LINE 1: do $$begin return 1; end;$$;
^
Regards,
--
Dimitri Fontaine
PostgreSQL DBA, Architecte

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2009-09-20 12:31:46 Re: Anonymous code blocks
Previous Message Magnus Hagander 2009-09-20 12:09:54 Re: pg_hba.conf: samehost and samenet [REVIEW]