Re: Column Filtering in Logical Replication

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Column Filtering in Logical Replication
Дата
Msg-id 202109271223.pw2dggvhq2mz@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Column Filtering in Logical Replication  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Column Filtering in Logical Replication  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On 2021-Sep-27, Amit Kapila wrote:

> I am not sure what makes you say that we can't distinguish the above
> cases when there is already a separate rule for CURRENT_SCHEMA? I
> think you can distinguish by tracking the previous objects as we are
> already doing in the patch. But one thing that is not clear to me is
> is the reason to introduce a new type PUBLICATIONOBJ_CURRSCHEMA when
> we use PUBLICATIONOBJ_REL_IN_SCHEMA and PUBLICATIONOBJ_CONTINUATION to
> distinguish all cases of CURRENT_SCHEMA. Alvaro might have something
> in mind for this which is not apparent and that might have caused
> confusion to you as well?

My issue is what happens if you have a schema that is named
CURRENT_SCHEMA.  In the normal case where you do ALL TABLES IN SCHEMA
"CURRENT_SCHEMA" you would end up with a String containing
"CURRENT_SCHEMA", so how do you distinguish that from ALL TABLES IN
SCHEMA CURRENT_SCHEMA, which does not refer to the schema named
"CURRENT_SCHEMA" but in Vignesh's proposal also uses a String containing
"CURRENT_SCHEMA"?

Now you could say "but who would be stupid enough to do that??!", but it
seems easier to dodge the problem entirely.  AFAICS our grammar never
uses String "CURRENT_SCHEMA" to represent CURRENT_SCHEMA, but rather
some special enum value.

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: [PATCH] Cross-reference comments on signal handling logic
Следующее
От: Rahila Syed
Дата:
Сообщение: Re: Column Filtering in Logical Replication