Skip site navigation (1) Skip section navigation (2)

Re: Anonymous code blocks

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Petr Jelinek <pjmodos(at)pjmodos(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: Anonymous code blocks
Date: 2009-09-20 00:03:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Petr Jelinek <pjmodos(at)pjmodos(dot)net> writes:
> I attached current version of the patch. I don't expect this to get
> committed or anything, but I'd like other eyes to take a look at it.

I'm reviewing this patch, and have early questions that might allow for
a quick returned with little feedback and much work...

Patch applies cleanly and build cleanly too, basic examples are working
fine. The problem is the following:

dim=# do $$begin select 'foo'; end;$$;
ERROR:  query has no destination for result data
HINT:  If you want to discard the results of a SELECT, use PERFORM instead.
CONTEXT:  PL/pgSQL function "inline" line 1 at SQL statement

Here's an example not so simple as to being meaningless:

  do $$
  declare v text := current_setting('server_version'); 
   case when v ~ '8.5' then select 'foo'; else select 'bar'; end case; 

And while this works:

  dim=# do $$ declare i integer; begin for i in 1..10 loop raise notice '%', i; end loop; end;$$;

One might want to have this working too:

  do returns setof integer as $$declare i integer; begin for i in 1..10 loop return next; end;$$;

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


PS: I'll go mark as returned with feedback but intend to complete this
review in the following days, by having a look at the code and
documentation. Unless beaten to it, as I won't be able to give accurate
guidance for pursuing effort.

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2009-09-20 00:23:10
Subject: Re: Anonymous code blocks
Previous:From: Jeff DavisDate: 2009-09-19 23:40:19
Subject: Re: operator exclusion constraints [was: generalized index constraints]

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group