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.
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 |