Horton

Re: SQL-standard function body

Jaime Casanova <jcasanov@systemguards.com.ec>

View thread View on postgr.es
From: Jaime Casanova <jcasanov@systemguards.com.ec>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-15T06:05:11Z
Lists: pgsql-hackers 
On Tue, Mar 9, 2021 at 7:27 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
>
> I see.  The problem is that we don't have serialization and
> deserialization support for most utility statements.  I think I'll need
> to add that eventually.  For now, I have added code to prevent utility
> statements.  I think it's still useful that way for now.
>

Great! thanks!

I found another problem when using CASE expressions:

CREATE OR REPLACE FUNCTION foo_case()
RETURNS boolean
LANGUAGE SQL
BEGIN ATOMIC
    select case when random() > 0.5 then true else false end;
END;

apparently the END in the CASE expression is interpreted as the END of
the function

-- 
Jaime Casanova
Director de Servicios Profesionales
SYSTEMGUARDS - Consultores de PostgreSQL

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