Re: Added schema level support for publication. - Mailing list pgsql-hackers

From vignesh C
Subject Re: Added schema level support for publication.
Date
Msg-id CALDaNm25c8WzsXBbPn-dvB5A2Sjri9vD2Y2O++fkYvHOxDE-dQ@mail.gmail.com
Whole thread Raw
In response to Re: Added schema level support for publication.  (Artur Zakirov <zaartur@gmail.com>)
Responses Re: Added schema level support for publication.
List pgsql-hackers
On Wed, 18 Dec 2024 at 16:34, Artur Zakirov <zaartur@gmail.com> wrote:
>
> On Tue, 17 Dec 2024 at 10:43, vignesh C <vignesh21@gmail.com> wrote:
> > > If I understand your suggestion correctly I think this will break the
> > > "--exclude-schema" option of pg_dump. That change will dump all
> > > mappings between publications and schemas for publications which are
> > > dumped.
> > >
> > > That solves the issue with special schemas, but restore will fail if
> > > some schemas were explicitly excluded. pg_dump will include in the
> > > dump ALTER PUBLICATION <pub> ADD TABLES IN SCHEMA <schema> even for
> > > those schemas which are not created during restore.
> >
> > This is already the case in the existing implementation, so users
> > should not be surprised by the proposed change.
>
> Currently the behavior isn't the same as the proposed change.
>
> Sorry, I might have been not clear when I described what might be
> wrong with this. Here is the example with the proposed patch [1].
>
> Create necessary objects to test:
>
>     create schema nsp;
>     create publication pub for tables in schema nsp;
>
> If you run pg_dump excluding the schema "nsp":
>
>     pg_dump -d postgres -U postgres -f backup --exclude-schema=nsp
>
> In the resulting file "backup" you will have:
>
>     ...
>     ALTER PUBLICATION pub ADD TABLES IN SCHEMA nsp;
>     ...
>
> which you won't have on the current master. And I think this is not
> what users might expect and it can break some of the scenarios because
> during restore they will have an error:
>
>     ERROR:  schema "nsp" does not exist

Yes, this is done intentionally in the proposed patch to keep it
consistent with other scenarios in HEAD.
For example, consider the following case:
-- Create schema and user defined function in schema sch2
create schema sch2;
CREATE FUNCTION sch2.add1(integer, integer)
RETURNS integer
LANGUAGE sql IMMUTABLE STRICT
AS $_$select $1 + $2;$_$;

-- Create a view which references user defined function of a different schema
create schema sch1;
CREATE TABLE sch1.t1 (c1 integer, c2 integer);
CREATE VIEW sch1.v1 AS SELECT c1 FROM sch1.t1 WHERE (sch2.add1(c1, c2) >= 10);

-- Exclude schema sch2 which has the user defined function while dumping
./pg_dump -d postgres -Fc -f dump1 -N sch2

The dump file has the reference to sch2.add1 even though sch2 schema
was excluded, dump will not have the user defined functions defined in
schema sch2:
CREATE VIEW sch1.v1 AS
 SELECT c1
   FROM sch1.t1
  WHERE (sch2.add1(c1, c2) >= 10);

Restore using the above dump that was generated will fail with the below error:
./pg_restore -d test1 dump1
pg_restore: error: could not execute query: ERROR:  schema "sch2" does not exist
LINE 4:   WHERE (sch2.add1(c1, c2) >= 10);
                 ^
Command was: CREATE VIEW sch1.v1 AS
 SELECT c1
   FROM sch1.t1
  WHERE (sch2.add1(c1, c2) >= 10);

The proposed patch is in similar lines.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Regression tests fail on OpenBSD due to low semmns value
Next
From: Jeff Davis
Date:
Subject: Re: Support regular expressions with nondeterministic collations