Skip site navigation (1) Skip section navigation (2)

Re: Patch to be verbose about being unable to read ~/.pgpasss...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sean Chittenden <sean(at)chittenden(dot)org>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Patch to be verbose about being unable to read ~/.pgpasss...
Date: 2003-06-23 14:11:11
Message-ID: 22895.1056377471@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Sean Chittenden <sean(at)chittenden(dot)org> writes:
> All regression tests pass with this case and no ABI or source
> incompatabilities are introduced.

You're still playing extremely fast and loose with that claim of "no
incompatibilities introduced".  This may not *directly* break an
application that uses PQsetNoticeProcessor, but it breaks the purpose
that the app is using PQsetNoticeProcessor for, namely to intercept
notices.  If it doesn't also override the fnoticeProc then it hasn't
intercepted all the notices.

What I was envisioning was a simple little subroutine that takes a
format string and some args, formats into a work buffer, and then passes
the formatted string to the existing notice hook.  Essentially, moving
the five lines you're unhappy about into a common subroutine.  This
gets the job done without *any* modification of the application API.

A bigger problem with the whole approach is that there's no way for
the application to install a notice processor before PasswordFromFile
is invoked, because that occurs during PQconnectdb.  So any notices
emitted by same will necessarily fall into the lap of the default
notice processor.

I didn't hear any strong objection to the idea of treating the
weak-protection complaint as a hard error (connection failure),
so we can fix the already-existing problem by doing that.  As
for the issue of whether to complain about a file that exists but
isn't readable, Peter exhibited lots of precedent for not doing so.
I'm inclined to think we should drop that part.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2003-06-23 14:24:50
Subject: Re: Small perf fixes/cleanup in src/backend/utils/adt/like.c...
Previous:From: Sean ChittendenDate: 2003-06-23 07:14:47
Subject: Re: Patch to be verbose about being unable to read ~/.pgpasss...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group