| From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(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-11 08:29:44 |
| Message-ID: | 65960f14-77b2-4673-d1d3-699f5b3ba6d2@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/01/17 15:06, Peter Eisentraut wrote:
> 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.
>
Okay, looking into my notes, I originally did this because we did not
allow adding tables without pkeys to publications which effectively
prohibited FOR ALL TABLES publication from working because of
information_schema without this. Since this is no longer the case I
think it's safe to skip the FirstNormalObjectId check.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2017-01-11 08:51:08 | Re: postgres_fdw bug in 9.6 |
| Previous Message | Fabien COELHO | 2017-01-11 08:29:23 | Re: proposal: session server side variables |