> On Sep 22, 2022, at 8:02 AM, Alvaro Herrera wrote:
>
> FWIW I put this to CI:
> https://cirrus-ci.com/build/5823276948652032 (master)
>
> and everything appears to be OK. If anybody has reservations about this
> grammar change, please speak up soon, as there's not much time before RC1.
>
FWIW I put this to CI:
https://cirrus-ci.com/build/5823276948652032 (master)
and everything appears to be OK. If anybody has reservations about this
grammar change, please speak up soon, as there's not much time before RC1.
The one for 15 just started running:
https://cirrus-ci.com/build/4735322
On Wed, Sep 21, 2022 at 1:15 AM Jonathan S. Katz wrote:
>
> (RMT hat on, unless otherwise noted)
>
> On 9/20/22 9:42 AM, Robert Haas wrote:
> > On Mon, Sep 19, 2022 at 11:03 PM Jonathan S. Katz
> > wrote:
> >> For #1 (allowing calls that have schema/table overlap...), there appears
> >> to be bo
On Wed, Sep 21, 2022 at 8:24 PM Jonathan S. Katz wrote:
>
> On 9/21/22 10:24 AM, Alvaro Herrera wrote:
> > On 2022-Sep-20, Robert Haas wrote:
> >
> >>> I don't think we should change this behavior that's already in logical
> >>> replication. While I understand the reasons why "GRANT ... ALL TABLES
On 9/21/22 10:24 AM, Alvaro Herrera wrote:
On 2022-Sep-20, Robert Haas wrote:
I don't think we should change this behavior that's already in logical
replication. While I understand the reasons why "GRANT ... ALL TABLES IN
SCHEMA" has a different behavior (i.e. it's not applied to future
objects
On 2022-Sep-20, Robert Haas wrote:
> > I don't think we should change this behavior that's already in logical
> > replication. While I understand the reasons why "GRANT ... ALL TABLES IN
> > SCHEMA" has a different behavior (i.e. it's not applied to future
> > objects) and do not advocate to chang
On Wednesday, September 21, 2022 4:06 AM Mark Dilger
wrote:
> > On Sep 20, 2022, at 12:36 PM, Jonathan S. Katz
> wrote:
> >
> > This behavior exists "FOR ALL TABLES" without the "IN SCHEMA" qualifier.
> This was discussed multiple times on the original thread[1].
>
> Yes, nobody is debating tha
[personal views, not RMT]
On 9/20/22 4:06 PM, Mark Dilger wrote:
I don't complain that it is buidling on the existing behavior. I'm *only*
concerned about the keywords we're using for this. Consider the following:
-- AS ADMIN
CREATE USER bob NOSUPERUSER;
GRANT ALL PRIVILEGES ON
> On Sep 20, 2022, at 12:36 PM, Jonathan S. Katz wrote:
>
> This behavior exists "FOR ALL TABLES" without the "IN SCHEMA" qualifier. This
> was discussed multiple times on the original thread[1].
Yes, nobody is debating that as far as I can see. And I do take your point
that this stuff was
(RMT hat on, unless otherwise noted)
On 9/20/22 9:42 AM, Robert Haas wrote:
On Mon, Sep 19, 2022 at 11:03 PM Jonathan S. Katz wrote:
For #1 (allowing calls that have schema/table overlap...), there appears
to be both a patch that allows this (reversing[8]), and a suggestion for
dealing with a
On 9/20/22 10:55 AM, Mark Dilger wrote:
On Sep 19, 2022, at 8:03 PM, Jonathan S. Katz wrote:
"When a partitioned table is added to a publication, all of its existing and future
partitions are implicitly considered to be part of the publication."[10]
Additionally, this is the behavior that
> On Sep 19, 2022, at 8:03 PM, Jonathan S. Katz wrote:
>
> "When a partitioned table is added to a publication, all of its existing and
> future partitions are implicitly considered to be part of the
> publication."[10]
>
> Additionally, this is the behavior that is already present in "FOR
On 2022-Sep-13, Kyotaro Horiguchi wrote:
> At Mon, 12 Sep 2022 04:26:48 +, "houzj.f...@fujitsu.com"
> wrote in
> > I feel we'd better compare the syntax with the existing publication command:
> > FOR ALL TABLES. If you create a publication FOR ALL TABLES, it means
> > publishing
> > all t
On Mon, Sep 19, 2022 at 11:03 PM Jonathan S. Katz wrote:
> For #1 (allowing calls that have schema/table overlap...), there appears
> to be both a patch that allows this (reversing[8]), and a suggestion for
> dealing with a corner-case that is reasonable, i.e. disallowing adding
> schemas to a pub
On Tue, Sep 20, 2022 at 2:57 PM Alvaro Herrera wrote:
>
> On 2022-Sep-20, Amit Kapila wrote:
>
> > On Mon, Sep 19, 2022 at 8:46 PM Alvaro Herrera
> > wrote:
>
> > > This seems a pretty arbitrary restriction. It feels like you're adding
> > > this restriction precisely so that you don't have to
On 2022-Sep-20, Amit Kapila wrote:
> On Mon, Sep 19, 2022 at 8:46 PM Alvaro Herrera
> wrote:
> > This seems a pretty arbitrary restriction. It feels like you're adding
> > this restriction precisely so that you don't have to write the code to
> > reject the ALTER .. SET SCHEMA if an incompatib
On 9/19/22 4:52 PM, Jonathan S. Katz wrote:
On 9/19/22 11:16 AM, Alvaro Herrera wrote:
This seems a pretty arbitrary restriction. It feels like you're adding
this restriction precisely so that you don't have to write the code to
reject the ALTER .. SET SCHEMA if an incompatible configuration
On Mon, Sep 19, 2022 at 8:46 PM Alvaro Herrera wrote:
>
> > diff --git a/doc/src/sgml/logical-replication.sgml
> > b/doc/src/sgml/logical-replication.sgml
> > index 1ae3287..0ab768d 100644
> > --- a/doc/src/sgml/logical-replication.sgml
> > +++ b/doc/src/sgml/logical-replication.sgml
> > @@ -1120
On 9/19/22 11:16 AM, Alvaro Herrera wrote:
diff --git a/doc/src/sgml/logical-replication.sgml
b/doc/src/sgml/logical-replication.sgml
index 1ae3287..0ab768d 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -1120,6 +1120,11 @@ test_sub=# SELECT *
> diff --git a/doc/src/sgml/logical-replication.sgml
> b/doc/src/sgml/logical-replication.sgml
> index 1ae3287..0ab768d 100644
> --- a/doc/src/sgml/logical-replication.sgml
> +++ b/doc/src/sgml/logical-replication.sgml
> @@ -1120,6 +1120,11 @@ test_sub=# SELECT * FROM child ORDER BY a;
>
>
On Saturday, September 17, 2022 11:22 AM Amit Kapila
wrote:
>
> On Fri, Sep 16, 2022 at 1:09 PM houzj.f...@fujitsu.com
>
> wrote:
> >
> > Attach the new version patch which addressed above comments and ran
> pgident.
> > I also improved some codes and documents based on some comments given
> >
On Fri, Sep 16, 2022 at 1:09 PM houzj.f...@fujitsu.com
wrote:
>
> Attach the new version patch which addressed above comments and ran pgident.
> I also improved some codes and documents based on some comments
> given by Vignesh and Peter offlist.
>
Thanks, the patch looks mostly good to me. I hav
On Friday, September 16, 2022 1:42 PM Amit Kapila
wrote:
>
> On Thu, Sep 15, 2022 at 6:27 PM houzj.f...@fujitsu.com
> wrote:
> >
> > Attach the new version patch which added suggested restriction for
> > column list and merged Vignesh's patch.
> >
>
> Few comments:
>
> 1.
> stati
On Thu, Sep 15, 2022 at 6:27 PM houzj.f...@fujitsu.com
wrote:
>
> Attach the new version patch which added suggested restriction for column list
> and merged Vignesh's patch.
>
Few comments:
1.
static void
-CheckPubRelationColumnList(List *tables, const char *queryString,
+CheckPubR
On Thu, Sep 15, 2022 at 8:18 AM houzj.f...@fujitsu.com
wrote:
>
> On Thursday, September 15, 2022 3:37 AM Peter Eisentraut
> wrote:
> > > Another option could be just ingore the column list if table's schema
> > > is also part of publication. But it seems slightly inconsistent with
> > > the rul
On Thu, Sep 15, 2022 at 10:57 PM houzj.f...@fujitsu.com
wrote:
>
...
> Attach the new version patch which added suggested restriction for column list
> and merged Vignesh's patch.
>
> Some other document might need to be updated. I will update them soon.
>
> Best regards,
> Hou zj
Hi Hou-san.
FY
On Thursday, September 15, 2022 10:48 AM houzj.f...@fujitsu.com wrote:
>
> On Thursday, September 15, 2022 3:37 AM Peter Eisentraut
> wrote:
>
> Hi,
>
> >
> > On 14.09.22 07:10, houzj.f...@fujitsu.com wrote:
> > > After applying the patch, we support adding a table with column list
> > > along
On Thursday, September 15, 2022 3:37 AM Peter Eisentraut
wrote:
Hi,
>
> On 14.09.22 07:10, houzj.f...@fujitsu.com wrote:
> > After applying the patch, we support adding a table with column list
> > along with the table's schema[1], and it will directly apply the
> > column list in the logical
On 14.09.22 07:10, houzj.f...@fujitsu.com wrote:
After applying the patch, we support adding a table with column list along with
the table's schema[1], and it will directly apply the column list in the
logical replication after applying the patch.
[1]--
CREATE PUBLICATION pub FOR TABLE public.te
On Monday, September 12, 2022 10:14 PM vignesh C wrote:
> On Sat, 10 Sept 2022 at 07:32, Amit Kapila wrote:
> >
> > On Fri, Sep 9, 2022 at 8:48 PM Robert Haas
> wrote:
> > >
> > > On Fri, Sep 9, 2022 at 10:29 AM houzj.f...@fujitsu.com
> > > wrote:
> > > > IIRC, the feature currently works almos
On Tuesday, September 13, 2022 12:40 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 12 Sep 2022 04:26:48 +, "houzj.f...@fujitsu.com"
> wrote in
> > On Monday, September 12, 2022 1:08 AM Mark Dilger
> > wrote:
> > > > > On Sep 10, 2022, at 4:17 PM, Robert Haas
> > > > > wrote:
> > > >
> > > >>>
At Mon, 12 Sep 2022 04:26:48 +, "houzj.f...@fujitsu.com"
wrote in
> On Monday, September 12, 2022 1:08 AM Mark Dilger
> wrote:
> > > > On Sep 10, 2022, at 4:17 PM, Robert Haas wrote:
> > >
> > >>> I don't understand why we
> > >>> used this ALL TABLES IN SCHEMA language.
> > >>
> > >> The
On Sat, 10 Sept 2022 at 07:32, Amit Kapila wrote:
>
> On Fri, Sep 9, 2022 at 8:48 PM Robert Haas wrote:
> >
> > On Fri, Sep 9, 2022 at 10:29 AM houzj.f...@fujitsu.com
> > wrote:
> > > IIRC, the feature currently works almost the same as you described. It
> > > doesn't
> > > create entry for tab
On Monday, September 12, 2022 1:08 AM Mark Dilger
wrote:
> > > On Sep 10, 2022, at 4:17 PM, Robert Haas wrote:
> >
> >>> I don't understand why we
> >>> used this ALL TABLES IN SCHEMA language.
> >>
> >> The conversation, as I recall, was that "ADD SCHEMA foo" would only mean
> all tables in foo
> On Sep 10, 2022, at 4:17 PM, Robert Haas wrote:
>
>>> I don't understand why we
>>> used this ALL TABLES IN SCHEMA language.
>>
>> The conversation, as I recall, was that "ADD SCHEMA foo" would only mean all
>> tables in foo, until publication of other object types became supported, at
>>
On Sat, 10 Sept 2022 at 19:18, Robert Haas wrote:
If I encountered this syntax in a vacuum, that's not what I would
> think. I would think that ADD ALL TABLES IN SCHEMA meant add all the
> tables in the schema to the publication one by one as individual
> objects, i.e. add the tables that are cur
On Fri, Sep 9, 2022 at 2:17 PM Mark Dilger wrote:
> > On Sep 9, 2022, at 8:18 AM, Robert Haas wrote:
> > Things might be clearer if we'd made the syntax "ALTER PUBLICATION p1
> > { ADD | DROP } { TABLE | SCHEMA } name". I don't understand why we
> > used this ALL TABLES IN SCHEMA language.
>
> Th
On Fri, Sep 9, 2022 at 8:48 PM Robert Haas wrote:
>
> On Fri, Sep 9, 2022 at 10:29 AM houzj.f...@fujitsu.com
> wrote:
> > IIRC, the feature currently works almost the same as you described. It
> > doesn't
> > create entry for tables that are published via its schema level, it only
> > record
>
> On Sep 9, 2022, at 8:18 AM, Robert Haas wrote:
>
> Things might be clearer if we'd made the syntax "ALTER PUBLICATION p1
> { ADD | DROP } { TABLE | SCHEMA } name". I don't understand why we
> used this ALL TABLES IN SCHEMA language.
The conversation, as I recall, was that "ADD SCHEMA foo" w
On Fri, Sep 9, 2022 at 10:29 AM houzj.f...@fujitsu.com
wrote:
> IIRC, the feature currently works almost the same as you described. It doesn't
> create entry for tables that are published via its schema level, it only
> record
> the published schema and check which tables are part of it.
Oh, wel
On Friday, September 9, 2022 9:57 PM Robert Haas wrote:
>
> On Fri, Sep 9, 2022 at 5:21 AM Amit Kapila wrote:
> > So, why shouldn't a "FOR ALL TABLES IN SCHEMA" publication follow a
> > similar behavior?
Hi
>
> It feels like a mistake to me that there's any catalog representation at all
> for
On Fri, Sep 9, 2022 at 5:21 AM Amit Kapila wrote:
> So, why shouldn't a "FOR ALL TABLES IN SCHEMA" publication follow a
> similar behavior?
Surely that is not the same case at all. If you're publishing
everything, there's no point in also having a specific list of things
that you want published,
On Fri, Sep 9, 2022 at 11:44 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > To avoid these confusions, we have disallowed adding a table if its
> > schema is already part of the publication and vice-versa.
>
> Really?
>
> Is there logic in ALTER TABLE SET SCHEMA that rejects the command
> depende
Amit Kapila writes:
> To avoid these confusions, we have disallowed adding a table if its
> schema is already part of the publication and vice-versa.
Really?
Is there logic in ALTER TABLE SET SCHEMA that rejects the command
dependent on the contents of the publication tables? If so, are
there l
On Thu, Sep 8, 2022 at 5:06 PM Peter Eisentraut
wrote:
>
> Apparently, you can't add a table to a publication if its schema is
> already part of the publication (and vice versa), e.g.,
>
> =# alter publication p1 add table s1.t1;
> ERROR: 22023: cannot add relation "s1.t1" to publication
> DETAIL
Apparently, you can't add a table to a publication if its schema is
already part of the publication (and vice versa), e.g.,
=# alter publication p1 add table s1.t1;
ERROR: 22023: cannot add relation "s1.t1" to publication
DETAIL: Table's schema "s1" is already part of the publication or part
46 matches
Mail list logo
