Re: Column Filtering in Logical Replication - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Column Filtering in Logical Replication
Date
Msg-id 202109291319.bm65vpzx4vzm@alvherre.pgsql
Whole thread Raw
In response to Re: Column Filtering in Logical Replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Column Filtering in Logical Replication
List pgsql-hackers
On 2021-Sep-28, Amit Kapila wrote:

> But it is not allowed to create schema or table with the name
> CURRENT_SCHEMA, so not sure if we need to do anything special for it.

Oh?  You certainly can.

alvherre=# create schema "CURRENT_SCHEMA";
CREATE SCHEMA
alvherre=# \dn
        Listado de esquemas
     Nombre     |       Dueño       
----------------+-------------------
 CURRENT_SCHEMA | alvherre
 public         | pg_database_owner
 temp           | alvherre
(3 filas)

alvherre=# create table "CURRENT_SCHEMA"."CURRENT_SCHEMA" ("bother amit for a while" int);
CREATE TABLE
alvherre=# \d "CURRENT_SCHEMA".*
                  Tabla «CURRENT_SCHEMA.CURRENT_SCHEMA»
         Columna         |  Tipo   | Ordenamiento | Nulable | Por omisión 
-------------------------+---------+--------------+---------+-------------
 bother amit for a while | integer |              |         | 


> Now, during post-processing, the PUBLICATIONOBJ_CONTINUATION will be
> distinguished as CURRENT_SCHEMA because both rangeVar and name will be
> NULL. Do you have other ideas to deal with it?

That sounds plausible.  There's no need for a name-free object of any other
kind AFAICS, so there should be no conflict.  If we ever do find a
conflict, we can add another struct member to disambiguate.

Thanks

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/
"Doing what he did amounts to sticking his fingers under the hood of the
implementation; if he gets his fingers burnt, it's his problem."  (Tom Lane)



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pgbench bug candidate: negative "initial connection time"
Next
From: Nitin Jadhav
Date:
Subject: Re: when the startup process doesn't (logging startup delays)