Re: [BUGS] Breakage with VACUUM ANALYSE + partitions

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Дата
Msg-id alpine.DEB.2.10.1605040727090.27782@sto
обсуждение исходный текст
Ответ на Re: [BUGS] Breakage with VACUUM ANALYSE + partitions  (Andres Freund <andres@anarazel.de>)
Ответы Re: [BUGS] Breakage with VACUUM ANALYSE + partitions  (Andres Freund <andres@anarazel.de>)
Re: [BUGS] Breakage with VACUUM ANALYSE + partitions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hello Andres,

>>> An enum doesn't have a benefit for a bitmask imo - you can't "legally"
>>> use it as a type for functions accepting the bitmask.
>>
>> I do not understand. I suggested to use enum to enumerate the bitmask
>> constants, ISTM that it does not preclude to use it as a bitmask as you do,
>> it is just a replacement of the #define? The type constraint on the enum
>> does not disallow bitmasking values, I checked with both gcc & clang.
>
> There's not really a point in using an enum if you use neither the type 
> (which you shouldn't because if you or the bitmask value you have types 
> outside the range of the enum), nor the autogenerated numbers.

I do not think that there is such a constraint in C, you can use the enum 
bitfield type, so you should. You can say in the type name that it is a 
bitmask to make it clearer:
  typedef enum {    EXTENSION_XXX = ...;  } extension_behavior_bitfield;

> Anyway seems fairly unimportant.

Sure, it is just cosmetic. Now the type is already an enum and you can 
keep it that way, ISTM that it is cleaner to avoid defines, so I think you 
should.

>> Then should it be _OPEN_INACTIVE[TED] or _OPEN_TRUNCATED rather than
>> _OPEN_DELETED, which is contradictory?
>
> Well, TRUNCATED doesn't entirely work, there's I think some cases where
> this currently also applies to deleted relations. I kind of like the
> unintuitive sounding name, because it's really a dangerous options (any
> further mdnblocks will be wrong).

Hmmm.

My issue is with the semantics of the name which implies how it can be 
understand by someone reading the code. The interface deals with files, so 
implicitely DELETED refers to files, and AFAICS no file was deleted. Maybe 
rows in the relation where deleted somehow, or entries in an index, but 
that has no sense at the API level. So I think you should not use DELETED.

I can see why a vaguely oxymoronic name is amusing, but I do not think 
that it conveys any idea of "dangerous" as you suggest.

Now the important think is probably not that the code is the cleanest 
possible one, but that it fixes the issue, so you should probably commit 
something.

-- 
Fabien.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Make PG's "NOT NULL"s and attnotnull ("is_nullable") conform to SQL-2011
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Make PG's "NOT NULL"s and attnotnull ("is_nullable") conform to SQL-2011