| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, Steve Singer <steve(at)ssinger(dot)info>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org |
| Subject: | Re: Logical Replication WIP |
| Date: | 2017-01-10 14:06:28 |
| Message-ID: | cedfd465-d7ae-503e-a9aa-b02b457e1f3d@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1/3/17 5:23 PM, Petr Jelinek wrote:
> I got this remark about IsCatalogClass() from Andres offline as well,
> but it's not true, it only checks for FirstNormalObjectId for objects in
> pg_catalog and toast schemas, not anywhere else.
I see your statement is correct, but I'm not sure the overall behavior
is sensible. Either we consider the information_schema tables to be
catalog tables, and then IsCatalogClass() should be changed, or we
consider then non-catalog tables, and then we should let them be in
publications. I don't think having a third category of
sometimes-catalog tables is desirable.
Currently, they clearly behave like non-catalog tables, since you can
just drop and recreate them freely, so I would choose the second option.
It might be worth changing that, but it doesn't have to be the job of
this patch set.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2017-01-10 14:46:00 | Re: pg_dump / copy bugs with "big lines" ? |
| Previous Message | Amit Kapila | 2017-01-10 13:58:12 | Re: UNDO and in-place update |