From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/PgSQL "bare" function calls |
Date: | 2004-09-17 03:37:53 |
Message-ID: | 15876.1095392273@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Fri, 2004-09-17 at 00:34, Tom Lane wrote:
>> I think Andrew has a point: why aren't they the same issue?
> (Note that we need to support CALL proc(...); in SQL for standards
> compliance in any event.)
Right. I'm thinking we could effectively make the CALL keyword optional
(though of course this is just speculation that it can be done without
any parsing conflicts).
> Well, as it turns out, it's easy to do in PL/PgSQL as well. The SELECT
> issue you mentioned doesn't actually pose a problem, because
> SELECT (2, 3, 4);
> is _not_ legal SQL in PL/PgSQL (PL/PgSQL requires SELECT INTO).
So? Lookahead won't help you if the INTO is at the end.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2004-09-17 04:25:04 | Re: pg_dump --exclude-schema=foo |
Previous Message | Tom Lane | 2004-09-17 03:18:12 | Re: Others applying patch queue patches |