From: | Sean Chittenden <sean(at)chittenden(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 07:14:47 |
Message-ID: | 20030623071447.GV97131@perrin.int.nxad.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
> 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.
I could make fnoticeProc private if you'd like, but that doesn't seem
smart if the user can override noticeFormat but can't with the
internal bits used by libpq... unless you're envisioning a private
method that constructs a msg for you, calls noticeProc with the buffer
as the arg, then then free()'s the result.
All regression tests pass with this case and no ABI or source
incompatabilities are introduced.
-sc
--
Sean Chittenden
Attachment | Content-Type | Size |
---|---|---|
patch | text/plain | 7.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-06-23 14:11:11 | Re: Patch to be verbose about being unable to read ~/.pgpasss... |
Previous Message | Bruce Momjian | 2003-06-23 06:57:02 | Re: LIKE <subtable> (second attempt) |