Horton

Re: SQL-standard function body

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Julien Rouhaud <rjuju123@gmail.com>, Noah Misch <noah@leadboat.com>
Cc: Jaime Casanova <jcasanov@systemguards.com.ec>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-07T08:52:10Z
Lists: pgsql-hackers

Attachments

On 06.06.21 09:32, Julien Rouhaud wrote:
> On Sat, Jun 05, 2021 at 09:44:18PM -0700, Noah Misch wrote:
>> I get a NULL pointer dereference if the function body has a doubled semicolon:
>>
>>    create function f() returns int language sql begin atomic select 1;; end;
> 
> You don't even need a statements to reproduce the problem, a body containing
> only semi-colon(s) will behave the same.
> 
> Attached patch should fix the problem.

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.

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.

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