Re: Column Filtering in Logical Replication
От | Alvaro Herrera |
---|---|
Тема | Re: Column Filtering in Logical Replication |
Дата | |
Msg-id | 202109291319.bm65vpzx4vzm@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Column Filtering in Logical Replication (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Column Filtering in Logical Replication
|
Список | 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 по дате отправления: