Mark Dilger <hornschnorter@gmail.com> writes:
> 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:
Hm, I don't think it's been debated in exactly these terms; but I find
myself a bit skeptical of the proposal as-is. At least going by your
examples, it'd make the .dat files a good bit more verbose, which doesn't
seem like what we want. Also it creates a bigger impedance mismatch
between what you see in the .dat files and what you see in the actual
catalogs, inviting confusion.
Also, with the particular implementation technique you suggest here,
there'd be a single namespace for the constants across all catalogs,
which creates a lot of possibilities for conflicts and mistakes.
We could fix that by instituting some sort of unique-ifying naming
convention, say CAST_IMPLICIT not just IMPLICIT, but that makes the
verbosity problem worse.
I think if we wanted to have something along this line, my preferred
approach would be to continue to write the entries as string literals:
castcontext => 'ASSIGNMENT', castmethod => 'FUNCTION' },
and make it the responsibility of genbki.pl to convert to the values
recognized by the backend. That way the conversion could happen on
a per-column basis, eliminating the conflict issue. But I'm not
really convinced that this'd be an improvement over where we are now.
regards, tom lane