Re: tablecmds.c/MergeAttributes() cleanup

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: tablecmds.c/MergeAttributes() cleanup
Дата
Msg-id 60beec03-f14c-ea46-8e5f-f68773ce83f9@eisentraut.org
обсуждение исходный текст
Ответ на Re: tablecmds.c/MergeAttributes() cleanup  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: tablecmds.c/MergeAttributes() cleanup  (Peter Eisentraut <peter@eisentraut.org>)
Список pgsql-hackers
On 29.08.23 13:20, Alvaro Herrera wrote:
> On 2023-Aug-29, Peter Eisentraut wrote:
>> @@ -3278,13 +3261,16 @@ MergeAttributes(List *schema, List *supers, char relpersistence,
>>    *
>>    * constraints is a list of CookedConstraint structs for previous constraints.
>>    *
>> - * Returns true if merged (constraint is a duplicate), or false if it's
>> - * got a so-far-unique name, or throws error if conflict.
>> + * If the constraint is a duplicate, then the existing constraint's
>> + * inheritance count is updated.  If the constraint doesn't match or conflict
>> + * with an existing one, a new constraint is appended to the list.  If there
>> + * is a conflict (same name but different expression), throw an error.
> 
> This wording confused me:
> 
> "If the constraint doesn't match or conflict with an existing one, a new
> constraint is appended to the list."
> 
> I first read it as "doesn't match or conflicts with ..." (i.e., the
> negation only applied to the first verb, not both) which would have been
> surprising (== broken) behavior.
> 
> I think it's clearer if you say "doesn't match nor conflict", but I'm
> not sure if this is grammatically correct.

Here is an updated version of this patch set.  I resolved some conflicts 
and addressed this comment of yours.  I also dropped the one patch with 
some catalog header edits that people didn't seem to particularly like.

The patches that are now 0001 through 0004 were previously reviewed and 
just held for the not-null constraint patches, I think, so I'll commit 
them in a few days if there are no objections.

Patches 0005 through 0007 are also ready in my opinion, but they haven't 
really been reviewed, so this would be something for reviewers to focus 
on.  (0005 and 0007 are trivial, but they go to together with 0006.)

The remaining 0008 and 0009 were still under discussion and contemplation.
Вложения

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: remaining sql/json patches
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: Improving btree performance through specializing by key shape, take 2