On 11/2/21 11:37 AM, Amit Kapila wrote:
> 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.
>
True.
>> 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.
>
+1
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company