Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't have problems sending the output to stderr myself.
That's because you don't run libpq in any contexts where that behavior
is inappropriate ... but there are plenty such contexts. Most GUI
applications will want to trap any and all notices and pu
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is there a TODO here? Tom has added the printf functionality already.
>
> We still have to do something about the fprintf(stderr) call that's in
> PasswordFromFile already. What do you think of my suggestion of a
> delayed notice?
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is there a TODO here? Tom has added the printf functionality already.
We still have to do something about the fprintf(stderr) call that's in
PasswordFromFile already. What do you think of my suggestion of a
delayed notice?
rega
Is there a TODO here? Tom has added the printf functionality already.
---
Tom Lane wrote:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > I maintain that having a security concern in PasswordFromFile() cause
> > the conn
Sean Chittenden <[EMAIL PROTECTED]> writes:
> I maintain that having a security concern in PasswordFromFile() cause
> the connection to abort as the default behavior is a bad idea.
That is a legitimate concern. Doesn't seem like we have any really
clean way to satisfy all the needs here.
One ide
> > Those notices were sent to setderr earlier, they were already
> > broken: at least now there's a ghost of a chance at the app at
> > picking up those errors.
>
> The notice in PasswordFromFile is broken, yes, but it is a recent
> addition; it has not been there long and has no seniority in my
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Those notices were sent to setderr earlier, they were already broken:
> at least now there's a ghost of a chance at the app at picking up
> those errors.
The notice in PasswordFromFile is broken, yes, but it is a recent
addition; it has not been there
Sean Chittenden <[EMAIL PROTECTED]> 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 use
> > 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 b
> 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 fnotice
> > 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.
*sigh* This isn't worth it at this point. Having written several
logging inte
Sean Chittenden <[EMAIL PROTECTED]> 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
> > -typedef void (*PQnoticeProcessor) (void *arg, const char *message);
> > +typedef void (*PQnoticeProcessor) (void *arg, const char *message, ...);
>
> This isn't going to happen. It would break every existing
> application that uses a notice processor, since they are not
> expecting to have t
Sean Chittenden <[EMAIL PROTECTED]> writes:
> -typedef void (*PQnoticeProcessor) (void *arg, const char *message);
> +typedef void (*PQnoticeProcessor) (void *arg, const char *message, ...);
This isn't going to happen. It would break every existing application
that uses a notice processor, since
> > Would you like me to add an interface that'd allow stderr to be
> > redirected in the case of defaultNoticeProcessor()?
>
> No, the application is supposed to set a notice processor if it
> doesn't want stuff going to stderr. I don't think that stuff needs
> to be redesigned.
Ehh... I'd say
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Would you like me to add an interface that'd allow stderr to be
> redirected in the case of defaultNoticeProcessor()?
No, the application is supposed to set a notice processor if it doesn't
want stuff going to stderr. I don't think that stuff needs to
> > stderr is hooked up to the error logs under Apache, which is the
> > normal error reporting mechanism. I thought about adding a test to
> > see if stderr is writable, but given that better than 99% of the time
> > it will be, I didn't see the point, esp since the above case regarding
> > the p
Sean Chittenden <[EMAIL PROTECTED]> writes:
> stderr is hooked up to the error logs under Apache, which is the
> normal error reporting mechanism. I thought about adding a test to
> see if stderr is writable, but given that better than 99% of the time
> it will be, I didn't see the point, esp sinc
> > Howdy. Quick chump patch: if libpq finds a ~/.pgpass but can't stat
> > it, print something to stderr letting the user know. If someone went
> > out of their way to put a .pgpass file in place, if they can't read
> > it, it seems worth while to alert them to the fact that it's not being
> > u
> > Howdy. Quick chump patch: if libpq finds a ~/.pgpass but can't stat
> > it, print something to stderr letting the user know.
>
> Isn't this gonna complain when the file doesn't exist at all?
*blush* Not with the attached patch. -sc
--
Sean Chittenden
Index: fe-connect.c
=
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Howdy. Quick chump patch: if libpq finds a ~/.pgpass but can't stat
> it, print something to stderr letting the user know.
Isn't this gonna complain when the file doesn't exist at all?
regards, tom lane
--
Howdy. Quick chump patch: if libpq finds a ~/.pgpass but can't stat
it, print something to stderr letting the user know. If someone went
out of their way to put a .pgpass file in place, if they can't read
it, it seems worth while to alert them to the fact that it's not being
used (ex: root create
22 matches
Mail list logo
