Re: Re: proposal: schema variables - Mailing list pgsql-hackers

From jian he
Subject Re: Re: proposal: schema variables
Date
Msg-id CACJufxEwd5V82CpGykhKD3Pb9LfS_rgw3-dPrxdT0rwqnkvzQQ@mail.gmail.com
Whole thread Raw
In response to Re: proposal: schema variables  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
On Fri, Feb 7, 2025 at 3:25 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>

Hi
The following review is based on v20250117.

pg_dump order seems not right.
CREATE FUNCTION public.test11(text) RETURNS text
    LANGUAGE sql
    AS $$select v4 $$;
CREATE VARIABLE public.v4 AS text;

first dump function then variable. restore would fail.
we should first dump variables then function.
probably placed it right after CREATE DOMAIN/CREATE TYPE


drop table if exists t3;
create variable v4 as text;
let v4 = 'hello';
CREATE TABLE t3 (a timestamp, v4 text);
INSERT INTO t3 SELECT i FROM generate_series('2020-01-01'::timestamp,
                                             '2020-12-31'::timestamp,
                                             '10 minute'::interval) s(i);
ANALYZE t3;
create or replace function test11(text) returns text as $$select v4 $$
language sql;
CREATE STATISTICS s4 (ndistinct) ON test11(v4), test11(v4 || 'h') FROM t3;
this "CREATE STATISTICS s4..." should error out?


any objects built on top of functions that use variables should be
marked as volatile.
and we should also consider the implications of it.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Virtual generated columns
Next
From: Daniel Gustafsson
Date:
Subject: Re: add support for the old naming libs convention on windows (ssleay32.lib and libeay32.lib)