On Mon, Nov 1, 2021 at 5:52 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> On 11/1/21 11:18, Amit Kapila wrote:
> > On Mon, Nov 1, 2021 at 2:48 AM Tomas Vondra
> > <tomas.vondra@enterprisedb.com> wrote:
> >> I wonder if it'd be better to just separate the schema and object type
> >> specification, instead of mashing it into a single constant.
> >>
> >
> > Do you mean to say the syntax on the lines of Create Publication For
> > Table t1, t2 Schema s1, s2;? If so, then originally the patch had the
> > syntax on those lines but Tom pointed out that the meaning of such a
> > syntax can change over a period of time and that can break apps [1]. I
> > think the current syntax gives a lot of flexibility to users and we
> > have some precedent for it as well.
> >
>
> No, I'm not talking about the syntax at all - I'm talking about how we
> represent it. PUBLICATIONOBJ_TABLE_CURRSCHEMA mixes the object type and
> schema in the same constant, so I am wondering if we should just split
> that into two pieces - one determining the schema, one determining the
> object type. So PublicationObjSpec would have two fields instead of just
> pubobjtype.
>
> The advantage would be we wouldn't need a whole lot of new constants for
> each object type - adding sequences pretty much means adding
>
> PUBLICATIONOBJ_SEQUENCE
> PUBLICATIONOBJ_SEQUENCE_IN_SCHEMA
> PUBLICATIONOBJ_SEQUENCE_CURRSCHEMA
>
> and after splitting we'd need just the first one.
>
I see your point but OTOH, I think it will lead to additional checks
in post-processing functions like ObjectsInPublicationToOids() as we
have to always check both object type and schema to make decisions.
> But maybe it's not
> that bad, though. We don't expect all that many object types in
> publications, I guess.
>
Yeah, that is also true. So maybe at this, we can just rename the few
types as suggested by you and we can look at it later if we anytime
have more number of objects to add.
--
With Regards,
Amit Kapila.