Horton

Re: SQL-standard function body

Vik Fearing <vik@postgresfriends.org>

View thread View on postgr.es
From: Vik Fearing <vik@postgresfriends.org>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-07-01T20:31:26Z
Lists: pgsql-hackers 
On 7/1/20 9:32 PM, Pavel Stehule wrote:
> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing <vik@postgresfriends.org>
> napsal:
> 
>> On 7/1/20 3:36 PM, Robert Haas wrote:
>>> I actually don't have a very clear idea of what the standard has to
>>> say about SQL-language functions. Does it just say it's a list of
>>> statements, or does it involve variables and control-flow constructs
>>> and stuff like that, too?
>>
>>
>> It's either a single sql statement, or a collection of them between
>> "begin atomic" and "end".  There are no variables or flow control
>> constructs or anything like that, just as there are no such things
>> outside of a function.
>>
> 
> What is the source of this comment?


The SQL Standard.


> Maybe we are speaking (and thinking)
> about different languages.


I think so, yes.


> I thought the language of SQL functions (ANSI/SQL) is SQL/PSM.


That is something else entirely, and not at all what Peter's patch is about.
-- 
Vik Fearing

Commits

  1. Don't crash on empty statements in SQL-standard function bodies.

  2. psql: Fix line continuation prompts for unbalanced parentheses

  3. Provide query source text when parsing a SQL-standard function body.

  4. Revert "Cope with NULL query string in ExecInitParallelPlan()."

  5. Undo decision to allow pg_proc.prosrc to be NULL.

  6. SQL-standard function body

  7. Move pg_stat_statements query jumbling to core.

  8. Extend SQL function tests lightly