On 2019-05-09 15:41, Tom Lane wrote:
>> I think we can get rid of the ability to reload the information_schema
>> after initdb. That was interesting in the early phase of its
>> development, but now it just creates complications.
> We've relied on that more than once to allow minor-release updates
On Thu, May 9, 2019 at 9:41 AM Tom Lane wrote:
> > I think we can get rid of the ability to reload the information_schema
> > after initdb. That was interesting in the early phase of its
> > development, but now it just creates complications.
>
> We've relied on that more than once to allow minor
Hi,
On 2019-05-09 09:30:50 +0200, Peter Eisentraut wrote:
> On 2019-05-09 04:37, Tom Lane wrote:
> > I'm of two minds what to do about that. One approach is to just
> > define a "FOR ALL TABLES" publication as including the information_schema
> > tables,
>
> certainly not
Yea, that strikes me a
Petr Jelinek writes:
> I think we need a better way of identifying what's part of system and
> what's user created in general. The FirstNormalObjectId seems somewhat
> okay approximation, but then we have plenty of other ways for checking,
> maybe it's time to consolidate it into some extra column
Peter Eisentraut writes:
> On 2019-05-09 04:37, Tom Lane wrote:
>> But, if what we want is the definition that "information_schema is
>> excluded from publishable tables", I'm not satisfied with this
>> implementation of that rule.
> ... It would also make sense to integrate both of these concept
On 09/05/2019 04:37, Tom Lane wrote:
> I wrote:
>> is_publishable_class has a test "relid >= FirstNormalObjectId",
>> which I think we should drop, for two reasons:
>> ...
>> So what is the motivation for this test? If there's an important
>> reason for it, we need to find a less fragile way to
On 2019-05-09 04:37, Tom Lane wrote:
> I tried removing the FirstNormalObjectId check, and found that the
> reason for it seems to be "the subscription/t/004_sync.pl test
> falls over without it". That's because that test supposes that
> the *only* entry in pg_subscription_rel will be for the test
I wrote:
> is_publishable_class has a test "relid >= FirstNormalObjectId",
> which I think we should drop, for two reasons:
> ...
> So what is the motivation for this test? If there's an important
> reason for it, we need to find a less fragile way to express it.
I tried removing the FirstNormalO
I wrote:
> is_publishable_class has a test "relid >= FirstNormalObjectId",
> which I think we should drop, for two reasons:
> 1. It makes the comment claiming that this function tests the same
> things as check_publication_add_relation a lie.
> 2. The comment about it claims that the purpose is t
is_publishable_class has a test "relid >= FirstNormalObjectId",
which I think we should drop, for two reasons:
1. It makes the comment claiming that this function tests the same
things as check_publication_add_relation a lie.
2. The comment about it claims that the purpose is to reject
informatio
10 matches
Mail list logo
