From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Christensen <david(at)endpoint(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] two-arg current_setting() with fallback |
Date: | 2015-03-20 16:04:04 |
Message-ID: | CA+TgmoaZqxEhQ2xx7N5+LMdoKSTp3NHScFZButqd-Q5Rd8oCgg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 20, 2015 at 10:54 AM, David Christensen <david(at)endpoint(dot)com> wrote:
> In that case, the other thought I had here is that we change the function signature of current_setting() to be a two-arg form where the second argument is a boolean "throw_error", with a default argument of true to preserve existing semantics, and returning NULL if that argument is false. However, I'm not sure if there are some issues with changing the signature of an existing function (e.g., with pg_upgrade, etc.).
>
> My *impression* is that since pg_upgrade rebuilds the system tables for a new install it shouldn't be an issue, but not sure if having the same pg_proc OID with different values or an alternate pg_proc OID would cause issues down the line; anyone know if this is a dead-end?
I think if the second argument is defaulted it would be OK. However
it might make sense to instead add a new two-argument function and
leave the existing one-argument function alone, because setting
default arguments for functions defined in pg_proc.h is kind of a
chore.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2015-03-20 16:10:11 | Re: [PATCH] two-arg current_setting() with fallback |
Previous Message | David G. Johnston | 2015-03-20 15:54:24 | Re: proposal: doc: simplify examples of dynamic SQL |