> On May 6, 2018, at 12:08 PM, John Naylor <jcnay...@gmail.com> wrote: > > On 5/7/18, Mark Dilger <hornschnor...@gmail.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
