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

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

Thomas Lockhart <thomas(at)fourpalms(dot)org> writes:
> Hmm. In looking at SET, why couldn't we develop this as an extendable
> capability a la pg_proc?

Well, my thoughts were along the line of providing specialized parsing
subroutines tied to specific GUC variables. There already are
parse_hook and assign_hook concepts in GUC, but possibly they need a
little more generalization to cover what these variables need to do.

If you're suggesting setting up an actual database table, I'm not
sure I see the point. Any system parameter is going to have to be
tied to backend code that knows what to do with the parameter, so
it's not like you can expect to do anything useful purely by adding
table entries. The C-code tables existing inside guc.c seem like
enough flexibility to me.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2002-04-21 23:57:05 Re: GUC vs variable.c (was Patches applied...)
Previous Message Thomas Lockhart 2002-04-21 23:36:44 Re: GUC vs variable.c (was Patches applied...)

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-04-21 23:57:05 Re: GUC vs variable.c (was Patches applied...)
Previous Message Thomas Lockhart 2002-04-21 23:36:44 Re: GUC vs variable.c (was Patches applied...)