From: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
---|---|
To: | John Naylor <jcnaylor(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: a way forward on bootstrap data |
Date: | 2018-05-06 20:25:34 |
Message-ID: | A5B52DA7-26D8-41E8-82AA-1DC98462E499@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On May 6, 2018, at 12:08 PM, John Naylor <jcnaylor(at)gmail(dot)com> wrote:
>
> On 5/7/18, Mark Dilger <hornschnorter(at)gmail(dot)com> wrote:
>> Hackers,
>>
>> Have you already considered and rejected the idea of having
>> genbki.pl/Catalog.pm define constants that can be used in
>> the catalog .dat files? I'm mostly curious if people think
>> the resulting .dat files are better or worse using constants
>> of this sort. For example:
> ...
>> + # pg_cast constants for castcontext
>> + use constant IMPLICIT => 'i';
>> + use constant ASSIGNMENT => 'a';
>> + use constant EXPLICIT => 'e';
>
> The comment refers to pg_cast, but these constants apply globally.
> It's also not the right place from a maintainability perspective, and
> if it was, now these values have different macros defined in two
> places. This is not good.
>
>> - castcontext => 'a', castmethod => 'f' },
>> + castcontext => ASSIGNMENT, castmethod => FUNCTION },
>
> For one, this breaks convention that the values are always
> single-quoted. If you had a use case for something like this, I would
> instead use the existing lookup infrastructure and teach genbki.pl to
> parse the enums (or #defines as the case might be) in the relevant
> header file. You'd need some improvement in readability to justify
> that additional code, though. I don't think this example quite passes
> (it's pretty obvious locally what the letters refer to), but others
> may feel differently.
John, Tom, thanks for the feedback. I share your concerns about my
straw-man proposal. But....
In the catalogs, 'f' usually means 'false', not 'function'. A person
reading pg_cast.dat could see:
castmethod => 'f'
and think that meant a binary conversion, since castmethod is false.
That's almost exactly wrong. Hence my desire to write
castmethod => FUNCTION
I don't have any better proposal, though.
mark
From | Date | Subject | |
---|---|---|---|
Next Message | Charles Cui | 2018-05-06 21:16:01 | Re: GSoC 2018: thrift encoding format |
Previous Message | Dmitry Dolgov | 2018-05-06 19:36:56 | Re: [HACKERS] advanced partition matching algorithm for partition-wise join |