GUC vs variable.c (was Patches applied...)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: GUC vs variable.c (was Patches applied...)
Date: 2002-04-21 21:52:18
Message-ID: 27276.1019425938@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

thomas(at)postgresql(dot)org (Thomas Lockhart) writes:
> Log message:
> Remove the definition for set_name_needs_quotes() on the assumption that
> it is now obsolete. Need some regression test cases to prove otherwise...

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.

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

(crash is due to assert failure)

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?

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Thomas Lockhart 2002-04-21 21:53:23 pgsql/src/backend/parser gram.y
Previous Message Thomas Lockhart 2002-04-21 21:37:03 pgsql/src/backend commands/variable.c parser/g ...

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-04-21 21:53:31 Re: Patches applied; initdb time!
Previous Message Joe Conway 2002-04-21 21:50:29 Re: Patches applied; initdb time!