PL/PgSQL "bare" function calls - Mailing list pgsql-hackers

From Neil Conway
Subject PL/PgSQL "bare" function calls
Date
Msg-id 1095257186.4915.179.camel@localhost.localdomain
Whole thread Raw
Responses Re: PL/PgSQL "bare" function calls
Re: PL/PgSQL "bare" function calls
List pgsql-hackers
I'd like to make it possible to perform function calls in PL/PgSQL
without needing to use PERFORM. I think this would be useful because (a)
it is closer to how PL/SQL works (b) PERFORM is (IMHO) a kludge, and
making it unnecessary would make programming in PL/PgSQL more natural.

Attached is a proof of concept patch that implements this. With this
patch, you can now write functions like so:

CREATE OR REPLACE FUNCTION some_func() RETURNS INT AS
'BEGIN
call_some_function();
RETURN 5;
END;
' LANGUAGE 'plpgsql';

Known issues with the patch:

(1) It seems to induce an intermittent segfault in the regression tests
on one of my machines (but not any others) which I need to fix.

(2) We should probably allow the name of a function to be double-quoted
so that it is possible to call functions with unusual names (mixed-case
and so on). I believe this should be possible, I just haven't
implemented it yet.

(3) The parser must distinguish between two cases when it sees an
unknown word (T_WORD) beginning a statement. The word could be the
beginning of a SQL statement (stmt_execsql in the grammar), such as:

UPDATE ...;

or the name of a function in a function call:

invoke_func(...);

The patch currently distinguishes between these cases by looking at the
next token -- if it is a left parenthesis, the patch assumes it is a
function call, otherwise it assumes it is a SQL statement. Is this the
best approach?

(Another method would be to teach the PL/PgSQL lexer about the basic SQL
keywords like UPDATE, INSERT, and so on, and then distinguish the two
cases that way. This would impose a maintenance burden when new SQL
commands are added, so I didn't adopt this approach.)

(4) This is proof-of-concept, so there's some mopup I still need to do
(for example, more extensive regression tests, and consider whether it
is better to reuse PLpgSQL_stmt_perform or to invent a new statement
type for this feature, update the docs, etc.)

Any comments?

-Neil




pgsql-hackers by date:

Previous
From: Sailesh Krishnamurthy
Date:
Subject: Re: beta1 & beta2 & Windows & heavy load
Next
From: Tom Lane
Date:
Subject: Re: libpq and prepared statements progress for 8.0