invalid search_path complaints - Mailing list pgsql-hackers

From Robert Haas
Subject invalid search_path complaints
Date
Msg-id CA+TgmoaMx5Pa5kRv_1=A9smDUxewn5j3iXqsvJbB8Q00WNejkg@mail.gmail.com
Whole thread Raw
Responses Re: invalid search_path complaints  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
If you use ALTER ROLE/DATABASE SET to configure an invalid
search_path, PostgreSQL 9.1 issues a complaint about the invalid
setting on each new connection.  This is a behavior change relatively
to previous releases, which did not.  git bisect blames this commit:

2594cf0e8c04406ffff19b1651c5a406d376657c is the first bad commit
commit 2594cf0e8c04406ffff19b1651c5a406d376657c
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Thu Apr 7 00:11:01 2011 -0400
  Revise the API for GUC variable assign hooks.
  The previous functions of assign hooks are now split between check hooks  and assign hooks, where the former can fail
butthe latter shouldn't.  Aside from being conceptually clearer, this approach exposes the  "canonicalized" form of the
variablevalue to guc.c without having to do  an actual assignment.  And that lets us fix the problem recently noted by
BerndHelmle that the auto-tune patch for wal_buffers resulted in bogus  log messages about "parameter "wal_buffers"
cannotbe changed without  restarting the server".  There may be some speed advantage too, because  this design lets
hookfunctions avoid re-parsing variable values when  restoring a previous state after a rollback (they can store a
pre-parsed representation of the value instead).  This patch also resolves a  longstanding annoyance about custom error
messagesfrom variable assign  hooks: they should modify, not appear separately from, guc.c's own message  about
"invalidparameter value".
 

Is this an intentional change?  And is it desirable?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: patch for parallel pg_dump
Next
From: Tom Lane
Date:
Subject: Re: Speed dblink using alternate libpq tuple storage