Re: SQL-standard function body

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SQL-standard function body
Date: 2021-06-07 19:49:59
Message-ID: 4ad1e920-6124-9769-8ed2-7e2355d2d186@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 07.06.21 17:27, Tom Lane wrote:
> ... I tend to agree with Julien's position here. It seems really ugly
> to prohibit empty statements just for implementation convenience.
> However, the way I'd handle it is to have the grammar remove them,
> which is what it does in other contexts. I don't think there's any
> need to preserve them in ruleutils output --- there's a lot of other
> normalization we do on the way to that, and this seems to fit in.

Ok, if that's what people prefer.

> BTW, is it just me, or does SQL:2021 fail to permit multiple
> statements in a procedure at all? After much searching, I found the
> BEGIN ATOMIC ... END syntax, but it's in <triggered SQL statement>,
> in other words the body of a trigger not a procedure. I cannot find
> any production that connects a <routine body> to that. There's an
> example showing use of BEGIN ATOMIC as a procedure statement, so
> they clearly*meant* to allow it, but it looks like somebody messed
> up the grammar.

It's in the SQL/PSM part.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-06-07 19:54:33 Re: CALL versus procedures with output-only arguments
Previous Message Peter Eisentraut 2021-06-07 19:38:20 Re: Tid scan improvements