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
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Should we add an Assert() to make it clear the current code is OK?
A comment maybe, but not an assert.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase yo
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Andrew Dunstan wrote:
> And here it is.
>
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
What should be done with this patch?
---
Dennis Björklund wrote:
> The mbvalidate() function was called on the PGresult strings, and it
> changes the strings (removes unknown characters).
>
> I've change the validation fun
Should we add an Assert() to make it clear the current code is OK?
---
Tom Lane wrote:
> "J.R. Nield" <[EMAIL PROTECTED]> writes:
> > The attached patches against 7.3 and 7.4 fix a subtraction carry bug in
> > xlog.c.
>
> T
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
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Andrew Dunstan wrote:
> Here's a small pa
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Rod Taylor wrote:
-- Start of PGP signed
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Rod Taylor wrote:
-- Start of PGP signed
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Shridhar Daithankar wrote:
Content-Descri
Can someone remind me why "-L../ecpglib -lecpg" is required for cygwin
but not for other platforms?
---
deststar wrote:
> *** src/interfaces/ecpg/compatlib/Makefile.orig Thu May 22 18:20:44 2003
> --- src/interfaces/ec
Patch applied to fix this. Thanks.
---
Karl Waclawek wrote:
>
> > I just applied the following patch which should fix this on your
> > platform. Thanks.
> >
>
> I got the following error from VC++:
>
> getaddrinfo.c
>
Here is the patch, to the patches list.
---
Kurt Roeckx wrote:
> On Tue, Jun 17, 2003 at 11:01:27PM -0500, Bruno Wolff III wrote:
> >
> > My system does have its own sockaddr_storage definition. I think
> > it uses __ss_ as
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> This one bugged me so much, I made a patch for it. It enforces
> consistent interpretation of date input:
This cannot be right can it? The code used to check EuroDates and now
it doesn't. ISTM you must have broken either Euro or US format.
Al
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
This one bugged me so much, I made a patch for it. It enforces
consistent interpretation of date input:
Valid: -MM-DD 2003-06-23
Invalid: -DD-MM 2003-23-06
Valid: DD-MM- 2
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
> > While doing some review of the LIKE function, I noticed some useless
> > bits left over from the pre-MB and converting-MB world.
>
> Isn't this patch going to destroy performance in single-byte
> encodings? I don't think the present state of the LIKE code is an
> intermediate state --- it's e
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
Sean Chittenden <[EMAIL PROTECTED]> writes:
> While doing some review of the LIKE function, I noticed some useless
> bits left over from the pre-MB and converting-MB world.
Isn't this patch going to destroy performance in single-byte encodings?
I don't think the present state of the LIKE code is a
> 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
25 matches
Mail list logo
