Re: Anonymous code blocks - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Anonymous code blocks
Date
Msg-id m28wg9lry7.fsf@hi-media.com
Whole thread Raw
In response to Re: Anonymous code blocks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Anonymous code blocks
List pgsql-hackers
Hi,

Tom Lane <tgl@sss.pgh.pa.us> writes:
> Andrew Dunstan <andrew@dunslane.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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pg_hba.conf: samehost and samenet [REVIEW]
Next
From: Dimitri Fontaine
Date:
Subject: Re: Anonymous code blocks