| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: plpgsql GUC variable: custom or built-in? |
| Date: | 2010-04-20 02:29:09 |
| Message-ID: | 16525.1271730549@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Apr 19, 2010 at 9:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The problem is that making a "custom" variable SUSET doesn't really
>> work: the system will not accept a value that's assigned before the
>> loadable module is loaded, even if it was assigned by a superuser.
>> I suggested a fix in the referenced thread, but it's not exactly an
>> ideal fix.
> Well, at this point the issue is deciding whether we're going to try
> to do anything about this before beta.
The reason it seems of concern for 9.0 is that now we have a custom
SUSET variable in plpgsql. If we don't fix this then we need to think
hard about the alternative of forcing the variable into the core code
to avoid the gotchas.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-04-20 02:47:06 | Re: plpgsql GUC variable: custom or built-in? |
| Previous Message | Tom Lane | 2010-04-20 02:07:57 | Re: row estimation off the mark when generate_series calls are involved |