RE: Skipping schema changes in publication - Mailing list pgsql-hackers

From osumi.takamichi@fujitsu.com
Subject RE: Skipping schema changes in publication
Date
Msg-id TYWPR01MB836287A8EC85F88973056F85EDD09@TYWPR01MB8362.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Skipping schema changes in publication  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Thursday, May 19, 2022 2:45 AM vignesh C <vignesh21@gmail.com> wrote:
> On Mon, May 16, 2022 at 8:32 AM osumi.takamichi@fujitsu.com
> <osumi.takamichi@fujitsu.com> wrote:
> > (3) src/test/regress/expected/publication.out
> >
> > +-- Verify that only superuser can reset a publication ALTER
> > +PUBLICATION testpub_reset OWNER TO regress_publication_user2; SET
> > +ROLE regress_publication_user2; ALTER PUBLICATION testpub_reset
> > +RESET; -- fail
> >
> >
> > We have "-- fail" for one case in this patch.
> > On the other hand, isn't better to add "-- ok" (or "-- success") for
> > other successful statements, when we consider the entire tests
> > description consistency ?
> 
> We generally do not mention success comments for all the success cases as
> that might be an overkill. I felt it is better to keep it as it is.
> Thoughts?
Thank you for updating the patches !

In terms of this point,
I meant to say we add "-- ok" for each successful
"ALTER PUBLICATION testpub_reset RESET;" statement.
That means, we'll have just three places to add "--ok"
and I thought this was not an overkill.

*But*, I'm also OK with your idea.
Please don't change the comments
and keep them as it is like v6.


Best Regards,
    Takamichi Osumi


pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Add --{no-,}bypassrls flags to createuser
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: create_help.pl treats as replaceable