DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=NXnEeA+BUpHBWZF8AHBMK86kAYu6OWi4oZKdNPE9NPNsOjwmMn4VLTnCINm64h/LR2WGCUnIRGHdf5gvCCrhM4RpTy4J0tdw68IbPNF07eZuSGvhBmYJtFlaiOueOqUFjWvj8mfNr3+1ZZZGhg6R1trbXd98FP4h2xr0ACs5whE=
Message-ID: <2b5c484b05052009545a310cd7@mail.gmail.com>
Date: Fri, 20 May 2005 17:54:32 +0100
From: Gustavo Lopes <contratempo@gmail.com>
Reply-To: Gustavo Lopes <contratempo@gmail.com>
To: pgsql-interfaces@postgresql.org
Subject: Re: libpq on windows
In-Reply-To: <2b5c484b05052006206c301de@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <2b5c484b05051906526f8bb577@mail.gmail.com>
	<20704.202.47.227.25.1116570741.squirrel@202.47.227.25>
	<2b5c484b05052006206c301de@mail.gmail.com>

Actually it seems the hints are not the problem. I see no pattern now.
For instance, if table "j" doesn't exist, "drop table j" is ok but not
"drop table".

Gustavo Lopes

On 20/05/05, Gustavo Lopes <contratempo@gmail.com> wrote:
> No, I'd say the notice processor/receiver is not the problem since
> I've been able to implement a notice receiver that would display the
> received notices without any complications.
> The problem seems to arise only when a message contains a HINT
> attached (I don't even know whether messages of type NOTICE can
> cointain a hint field, but anyway that doesn't seem relevant to this
> issue).
>=20
> Gustavio Lopes
>=20
> On 20/05/05, jtv@xs4all.nl <jtv@xs4all.nl> wrote:
> > Gustavo Lopes <contratempo@gmail.com> wrote:
> >
> > > The problem seems to occurr only when the server sends a hint or the
> > > dll generates one. This can happen when the connection to the server
> > > cannot be established because the server is not running, a nonexistan=
t
> > > postgres function exist is called, when one attempts to drop an index
> > > upon which a constraint depends, etc. (the program doesn't go beyond
> > > PQconnectdb, PQexec or PQexecparam). Since my debugging skills are
> > > very poor I cannot give any accurate description on what is causing
> > > the exception.
> > > The problem can be very easily reproduced by creating a C program
> > > which calls PQconnectdb with a host parameter that points to a machin=
e
> > > that is not running postgres.
> > > Running the same program under linux (although I used older versions
> > > of the interface and the server) does not cause any problems.
> >
> > It could be the notice processor that crashes.  A "notice processor" is=
 a
> > callback that you can register with libpq that handles error messages.
> > The default is to print them to the console, but I'm not sure you can
> > always do that in a Windows program.  Or since you're apparently using
> > different compilers for libpq and the application, maybe the default
> > notice processor gets linked to a different standard library than it
> > expects and fails because of that.
> >
> > Notice processors are documented here:
> >
> > http://www.postgresql.org/docs/8.0/interactive/libpq-notice-processing.=
html
> >
> > To find out if this is what's wrong, try creating an empty function (wi=
th
> > C-style calling convention, not a regular C++ function) and setting tha=
t
> > as the notice processor:
> >
> >   extern "C" { /* (this line only needed in C++) */
> >   void emptynoticeprocessor(void *, const char *)
> >   {
> >   }
> >   } /* (this line only needed in C++) */
> >
> > Now in your code, just after you opened your connection (call it "c"):
> >
> >   PQsetNoticeProcessor(c,emptynoticeprocessor,NULL);
> >
> > Of course that will mean that error messages are not displayed, so if t=
his
> > solves your crashing problem then your next step is to implement someth=
ing
> > here that displays the given message!
> >
> > Jeroen
> >
> >
>