> I agree that we don't want to reinstate that hack on the gram.y side.
> However, it seems to me way past time that we did what needs to be done
> with variable.c --- ie, get rid of it. All these special-cased
> variables should be folded into GUC.
Or in some cases into pg_database? We might want some of this to travel
as database-specific properties adjustable using SQL or SET syntax.
> The code as committed has some problems beyond having broken support
> for search_path with a list:
> regression=# set seed to 1,2;
> server closed the connection unexpectedly
OK. Would be nice to have a regression test covering this. And this is
quite easy to fix of course.
> but really there's no point in worrying about that one case. What we
> need to do is figure out what needs to be done to GUC to let it support
> these variables, and then merge the variable.c code into that structure.
> Should we allow GUC stuff to take a list of A_Const as being the most
> general case, or is that overkill?
Not sure. Peter would like to change the SET DATESTYLE support if I
remember correctly. But I've gotten the impression, perhaps wrongly,
that this extends to changing features in dates and times beyond style
settings. If it is just the two-dimensional nature of the datestyle
parameters (euro vs non-euro, and output format) then I'm sure that some
other reasonable syntax could be arranged. I'm not sure what he would
recommend wrt GUC in just the context of general capabilities for
specifying parameters.
- Thomas