> On Mar 20, 2015, at 11:10 AM, David G. Johnston <david.g.johns...@gmail.com> > wrote: > > On Fri, Mar 20, 2015 at 9:04 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Mar 20, 2015 at 10:54 AM, David Christensen <da...@endpoint.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. > > Isn't there some other update along this whole error-vs-null choice going > around where a separate name was chosen for the new null-returning function > instead of adding a boolean switch argument?
Well, speaking of the two-arg form vs alternate name, here's a version of the patch which includes the new behavior. (I couldn't think of a good name to expose for an alternate function, but I'm open to suggestions.) Regards, David -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171
0001-Add-two-arg-form-of-current_setting-to-optionally-su.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
