Horton

Re: SQL-standard function body

Pavel Stehule <pavel.stehule@gmail.com>

View thread View on postgr.es
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Vik Fearing <vik@postgresfriends.org>
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-01T19:32:38Z
Lists: pgsql-hackers 
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? Maybe we are speaking (and thinking)
about different languages.

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

Regards

Pavel



> (There are a few statements that are not allowed, such as COMMIT.)
> --
> 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