Re: PL/PgSQL "bare" function calls
| От | Andrew Dunstan |
|---|---|
| Тема | Re: PL/PgSQL "bare" function calls |
| Дата | |
| Msg-id | 41485D8D.20401@dunslane.net обсуждение исходный текст |
| Ответ на | Re: PL/PgSQL "bare" function calls (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: PL/PgSQL "bare" function calls
Re: PL/PgSQL "bare" function calls |
| Список | 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 по дате отправления: