Re: Added schema level support for publication.

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: Added schema level support for publication.
Дата
Msg-id 0e5a6568-f7a2-751e-74eb-70bb59c0ed32@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Added schema level support for publication.  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Added schema level support for publication.  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers

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:
>>
>> On 10/28/21 04:41, Amit Kapila wrote:
>>> On Mon, Oct 25, 2021 at 3:09 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>>>
>>>> On Mon, Oct 25, 2021 at 1:11 PM vignesh C <vignesh21@gmail.com> wrote:
>>>>>
>>>>> I have fixed this in the v47 version attached.
>>>>>
>>>>
>>>> Thanks, the first patch in the series "Allow publishing the tables of
>>>> schema." looks good to me. Unless there are more
>>>> comments/bugs/objections, I am planning to commit it in a day or so.
>>>>
>>>
>>> Yesterday, I have pushed the first patch. Feel free to submit the
>>> remaining patches.
>>>
>>
>> I haven't been following this thread recently, but while rebasing the
>> sequence decoding patch I noticed this adds
>>
>>       PUBLICATIONOBJ_TABLE,            /* Table type */
>>       PUBLICATIONOBJ_REL_IN_SCHEMA,    /* Relations in schema type */
>>
>> Shouldn't it be PUBLICATIONOBJ_TABLE_IN_SCHEMA, or why does it use rel
>> instead of table?
>>
> 
> Yeah, it should be PUBLICATIONOBJ_TABLE_IN_SCHEMA considering we have
> to add other objects like sequence.
> 
>> I'm asking because the sequence decoding patch mimics ALTER PUBLICATION
>> options for sequences, including ALL SEQUENCES IN SCHEMA etc. and this
>> seems ambiguous. The same issue applies to PUBLICATIONOBJ_CURRSCHEMA,
>> which does not specify the object type.
>>
> 
> I think we should name it PUBLICATIONOBJ_TABLE_CURRSCHEMA. Does that make sense?
> 
>> 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. But maybe it's not 
that bad, though. We don't expect all that many object types in 
publications, I guess.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Missing include in be-secure-openssl.c?
Следующее
От: Hayk Manukyan
Дата:
Сообщение: Re: Feature request for adoptive indexes