Re: PL/PgSQL "bare" function calls

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 02:25:24
Message-ID: 1095387924.1141.16.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2004-09-17 at 00:34, Tom Lane wrote:
> I think Andrew has a point: why aren't they the same issue? It would
> certainly be no harder to support
> func( ... );
> as a SQL statement than as something allowed only in plpgsql.

If there's a consensus that it is better to modify the main grammar so
that unadorned function calls are legal anywhere, that's fine with me.
If anyone doesn't want this, speak up now.

(Note that we need to support CALL proc(...); in SQL for standards
compliance in any event.)

> I think it'd be easier to make it work in the full bison grammar
> than with some lookahead hack in plpgsql.

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). Also, we
get support for double-quotes and schema-qualified function names for
free, because of how the PL/PgSQL scanner works.

-Neil

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-09-17 03:18:12 Re: Others applying patch queue patches
Previous Message Bruce Momjian 2004-09-17 01:34:45 Others applying patch queue patches