On 23/12/2005 03:59, Tatsuo Ishii wrote:
BTW, the example code sequence (ISO-8859-8) Sagi posted seems to have
wrong one.
select '';
WARNING: ignoring unconvertible ISO_8859_8 character 0x00d7
:
:
0x00d7(\327) is not listed in our ISO-8858-8/UTF-8 conversion map. Is
this OK or do we ne
daveg wrote:
> On Fri, Dec 30, 2005 at 05:55:23PM -0500, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Neil Conway <[EMAIL PROTECTED]> writes:
> > > > One minor irritation is that the query string of prepared statements
> > > > created via SQL has "PREPARE ... AS" prefixed to it, whereas statement
On Fri, Dec 30, 2005 at 05:55:23PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > One minor irritation is that the query string of prepared statements
> > > created via SQL has "PREPARE ... AS" prefixed to it, whereas statements
> > > prepared via th
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > One minor irritation is that the query string of prepared statements
> > created via SQL has "PREPARE ... AS" prefixed to it, whereas statements
> > prepared via the FE-BE protocol do not. This should probably be fixed,
>
> That's debat
I have applied your patch with only minor comment additions. Let us
know if additional changes are required. Thanks.
Are these flags required to be supplied to configure, or just the ASM
file?
-Xa -xtarget=opteron -xarch=amd64
I am thinking the port isn't 100% fool-proof yet, but it
I've just realized an exception in the sending data while using
PQsendCopyData(). Function's blocking behaviour is not guaranteed,
therefore a
if (PQisnonblocking())
PQsetnonblocking(conn, 0)
kind of phrase required before using PQsendCopyData(). But after a
small investig