From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 15:25:25 |
Message-ID: | 162867790909200825gf90c49fxfbc7cba94ce8d90c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/9/20 Dimitri Fontaine <dfontaine(at)hi-media(dot)com>:
> 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.
Hello
I think so RETURN there has some sense. It should be optional, and
have to specify exit status. So return non zero value means exit psql
with returned value as exit status.
It would be interesting, if we could access from anonymous block some
psql internal variables.
regards
Pavel Stehule
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-09-20 15:43:00 | Re: updated hstore patch |
Previous Message | Abhijit Menon-Sen | 2009-09-20 14:50:11 | Re: GRANT ON ALL IN schema |