Andres Freund writes:
> On 2020-03-02 17:52:17 -0500, Tom Lane wrote:
>> While looking at Tomas' ALTER TYPE patch, I got annoyed by the fact
>> that all of the backend writes constants of type alignment and type
>> storage values as literal characters, such as 'i' and 'x'. This is
>> not our
Hi,
On 2020-03-02 17:52:17 -0500, Tom Lane wrote:
> While looking at Tomas' ALTER TYPE patch, I got annoyed by the fact
> that all of the backend writes constants of type alignment and type
> storage values as literal characters, such as 'i' and 'x'. This is
> not our style for most other "poor
Michael Paquier writes:
> On Tue, Mar 03, 2020 at 04:45:51PM -0500, Tom Lane wrote:
>> Yeah, that works out very nicely: there's now only one place besides
>> tupmacs.h that needs a new #include.
>> I did a little more polishing, and consider the attached committable,
>> unless anyone has
On Tue, Mar 03, 2020 at 04:45:51PM -0500, Tom Lane wrote:
> Yeah, that works out very nicely: there's now only one place besides
> tupmacs.h that needs a new #include.
>
> I did a little more polishing, and consider the attached committable,
> unless anyone has objections.
Nice. I have looked
I wrote:
> Alvaro Herrera writes:
>> On 2020-Mar-03, Tom Lane wrote:
>>> I realized that a possible compromise position is to have tupmacs.h
>>> include pg_type_d.h, not the whole pg_type.h header, thus dodging the
>>> indirect inclusions. That still brings in the type-OID macros, but
>>> it's a
Alvaro Herrera writes:
> On 2020-Mar-03, Tom Lane wrote:
>> I realized that a possible compromise position is to have tupmacs.h
>> include pg_type_d.h, not the whole pg_type.h header, thus dodging the
>> indirect inclusions. That still brings in the type-OID macros, but
>> it's a lot less header
On 2020-Mar-03, Tom Lane wrote:
> I realized that a possible compromise position is to have tupmacs.h
> include pg_type_d.h, not the whole pg_type.h header, thus dodging the
> indirect inclusions. That still brings in the type-OID macros, but
> it's a lot less header scope creep than I was first
I wrote:
> Alvaro Herrera writes:
>> On 2020-Mar-02, Tom Lane wrote:
>>> One thing that I'm not totally happy about, as this stands, is that
>>> we have to #include "catalog/pg_type.h" in various places we did
>>> not need to before (although only a fraction of the files I touched
>>> need that).
Alvaro Herrera writes:
> On 2020-Mar-02, Tom Lane wrote:
>> One thing that I'm not totally happy about, as this stands, is that
>> we have to #include "catalog/pg_type.h" in various places we did
>> not need to before (although only a fraction of the files I touched
>> need that).
> If we think
On 2020-Mar-02, Tom Lane wrote:
> While looking at Tomas' ALTER TYPE patch, I got annoyed by the fact
> that all of the backend writes constants of type alignment and type
> storage values as literal characters, such as 'i' and 'x'. This is
> not our style for most other "poor man's enum"
While looking at Tomas' ALTER TYPE patch, I got annoyed by the fact
that all of the backend writes constants of type alignment and type
storage values as literal characters, such as 'i' and 'x'. This is
not our style for most other "poor man's enum" catalog columns, and
it makes it really hard to
11 matches
Mail list logo
