Re: SQL-standard function body - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: SQL-standard function body
Date
Msg-id CAOBaU_ZMMwnkygU4OMc3gUtbt5FS0fbQBzQC=rJm6xYi4qEYKg@mail.gmail.com
Whole thread Raw
In response to Re: SQL-standard function body  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: SQL-standard function body  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jun 7, 2021 at 4:52 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> Your patch filters out empty statements at the parse transformation
> phase, so they are no longer present when you dump the body back out.
> So your edits in the test expected files don't fit.

Oh, somehow the tests aren't failing here, I'm not sure what I did wrong.

> I suggest we just prohibit empty statements at the parse stage.  I don't
> see a strong reason to allow them, and if we wanted to, we'd have to do
> more work, e.g., in ruleutils.c to print them back out correctly.

I always thought extraneous semicolons were tokens to be ignored,
which happens to be internally implemented as empty statements, so
deparsing them is not required, similar to deparsing extraneous
whitespaces.  If the spec says otherwise then I agree it's not worth
implementing, but otherwise I'm not sure if it's really helpful to
error out.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: missing GRANT on pg_subscription columns
Next
From: Amit Kapila
Date:
Subject: Re: locking [user] catalog tables vs 2pc vs logical rep