Custom variables and flags, again

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Subject: Custom variables and flags, again
Date: 2008-11-16 21:15:06
Message-ID: 12680.1226870106@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The auto-explain patch needs a way to set the GUC "flags" for a custom
GUC variable; a capability that was unaccountably left out of the
original DefineCustomXXXVariable APIs. The original version of the patch
dealt with this by changing those APIs, which I complained about here:
http://archives.postgresql.org/pgsql-hackers/2008-09/msg00168.php

The new version gets around this by leaving those functions alone and
exporting a new function
void DefineCustomVariable(enum config_type type, const void *variable);
to which you are supposed to pass an entire struct config_whatever.

I can't say that I find this an improvement. Yeah, it avoids breaking
existing code, but the idea that add-on modules should hard-code the
exact contents of the GUC structs fills me with horror. What happens
when we add some field or other to those structs? I'll tell you what
happens: those modules break, nastily and probably silently, because
no C compiler I know of is very picky about the contents of a struct
initializer. So I think this is just trading short-term pain for a
larger amount of long-term pain.

On the whole, I think we'd be better off to just add more arguments
to the DefineCustomXXXVariable functions, as in the original patch
(and while we're at it, fix the problem of where the boot_val comes
from, as suggested in the above-referenced message). At least that will
result in obvious and easily-fixable breakage in add-on modules that use
these functions.

Comments?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-11-16 22:18:28 Re: auto_explain contrib moudle
Previous Message Oleg Serov 2008-11-16 20:20:30 Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;