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

From Andrew Dunstan
Subject Re: PL/PgSQL "bare" function calls
Date
Msg-id 41485D8D.20401@dunslane.net
Whole thread Raw
In response to Re: PL/PgSQL "bare" function calls  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PL/PgSQL "bare" function calls  (Joe Conway <mail@joeconway.com>)
Re: PL/PgSQL "bare" function calls  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers

Tom Lane wrote:

>Neil Conway <neilc@samurai.com> writes:
>  
>
>>(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?
>>    
>>
>
>That seems fairly unworkable.  For example
>
>    SELECT (2,3,4);
>
>is valid SQL.  Also I'm not sure if you can extend this to cope with
>schema-qualified function names.
>
>
>  
>

ISTM that this is being done at the wrong level anyway. I'd like to see 
a facility available in our SQL, e.g.
 CALL foo();

with the restriction that foo() should be declared to return void. Of 
course, that doesn't remove the keyword requirement as Neil wanted, but 
doing that would probably require a lot more work - we'd have to make 
procedures a whole lot closer to  first-class objects.

cheers

andrew


pgsql-hackers by date:

Previous
From: "Jeroen T. Vermeulen"
Date:
Subject: Re: WIN1250 as server encoding
Next
From: Tom Lane
Date:
Subject: Re: WIN1250 as server encoding