Re: GUC vs variable.c (was Patches applied...)
| От | Thomas Lockhart |
|---|---|
| Тема | Re: GUC vs variable.c (was Patches applied...) |
| Дата | |
| Msg-id | 3CC34D0C.F24DA7E5@fourpalms.org обсуждение исходный текст |
| Ответ на | GUC vs variable.c (was Patches applied...) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: GUC vs variable.c (was Patches applied...)
|
| Список | pgsql-hackers |
Hmm. In looking at SET, why couldn't we develop this as an extendable
capability a la pg_proc? If PostgreSQL knew how to link up the set
keyword with a call to a subroutine, then we could go ahead and call
that routine generically, right? Do the proposals on the table call for
this kind of implementation, or are they all "extra-tabular"?
We could make this extensible by defining a separate table, or by
defining a convention for pg_proc as we do under different circumstances
with type coersion.
The side effects of the calls would still need some protection to be
rolled back on transaction abort.
Comments?
- Thomas
В списке pgsql-hackers по дате отправления: