On Wed, Feb 5, 2020 at 10:20 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Good summary. I think that the combination of a magic number to identify
> "this is a memory context struct" and an enum to identify the specific
> type of context should meet all these goals moderately well:
>
> * Third-party context types would have to force the compiler to take
> context-type values that weren't among the known enum values ---
> although they could ask us to reserve a value by adding an otherwise-
> unreferenced-by-core-code enum entry, and I don't really see why
> we shouldn't accept such requests.
>
> * Frontend and backend would have to share the enum, but the list
> is short enough that that shouldn't be a killer maintenance problem.
> (Also, the enum field would be pretty much write-only from the
> code's standpoint, so even if two programs were out of sync on it,
> there would be at worst a debugging hazard.)
>
> * The enum does what I want for debuggability, especially if we
> back-stop it with a name string in the methods struct as you suggested.
>
> * The magic value does what Andres wants for sanity checking.
I'm pretty unimpressed with the enum proposal - I think it's pretty
nasty for an extension author to have to make up a value that's not in
the enum. One, how are they supposed to know that they should do that?
Two, how are they supposed to know that the code doesn't actually
depend on that enum value for anything important? And three, how do
they know that the compiler isn't going to hose them by assuming that
isn't a can't-happen scenario?
I mean, I'd rather get a patch committed here than not, but I have a
hard time understanding why this is a good way to go.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
