Re: PL/PgSQL "bare" function calls

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

In response to

Browse pgsql-hackers by date

  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