Re: Patch to be verbose about being unable to read ~/.pgpasss... - Mailing list pgsql-patches

From Tom Lane
Subject Re: Patch to be verbose about being unable to read ~/.pgpasss...
Date
Msg-id 27266.1056310355@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch to be verbose about being unable to read ~/.pgpasss...  (Sean Chittenden <sean@chittenden.org>)
Responses Re: Patch to be verbose about being unable to read ~/.pgpasss...  (Sean Chittenden <sean@chittenden.org>)
Re: Patch to be verbose about being unable to read ~/.pgpasss...  (Sean Chittenden <sean@chittenden.org>)
List pgsql-patches
Sean Chittenden <sean@chittenden.org> writes:
> Um, I said it would change the ABI and I said as much in my previous
> post.

The ABI is only the smaller part of the problem; you'd be forcing people
to change their source code, in a rather nonobvious way.

> it is code compatible provided people aren't using any %
> escape strings in their error messages (if there aren't any format
> strings, there won't be any need to modify the program),

And if there aren't any format strings, then we don't need to change the
interface.  I don't see your point at all.  You cannot make use of the
added functionality without breaking client applications.

I could envision a helper procedure, known only within libpq, that has
a signature like formatNotice(PGconn* conn, const char *fmtstring, ...)
and encapsulates the work needed to handle a format string.  But I see
no reason to push that work out to client applications.

            regards, tom lane

pgsql-patches by date:

Previous
From: Sean Chittenden
Date:
Subject: Re: Patch to be verbose about being unable to read ~/.pgpasss...
Next
From: Sean Chittenden
Date:
Subject: Re: Patch to be verbose about being unable to read ~/.pgpasss...