John DeSoi <[EMAIL PROTECTED]> writes:
> I was wondering if there is some way I'm missing to get the table and
> column information from a cursor. If I fetch from a cursor, the table
> OID and column number values are 0 in the row description. If I execute
> the same query directly without a cur
> Oliver Jowett <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> OK, thats what I hoped you'd say. With a prepared query all of the
> >> statements execute the same plan, so you don't need to know the exact
> >> parameters.
>
> > This isn't true in 8.0 if you are using the unnamed statement
Christopher Kings-Lynne wrote:
> Hey guys,
>
> The 'Unicode characters above 0x1' issue keeps rearing its ugly head
> in the IRC channel. I propose that it be fixed, even backported...
>
> This is John Hansen's most recent patch to fix it:
>
> http://archives.postgresql.org/pgsql-patches/2
On 2005-04-09, Bruce Momjian wrote:
> Uh, I thought we fixed this another way, buy not using Unicode-aware
> functions for upper/lower/initcap when the locale is "C" or "POSIX".
> That is backpatched to 8.0.X. Does that not fix the problem reported?
Unicode values over 0x are simply not acc
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> Sent: Sunday, April 10, 2005 8:18 AM
> To: Christopher Kings-Lynne
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Unicode problems on IRC
>
> Christopher Kings-Lynne wro
"John Hansen" <[EMAIL PROTECTED]> writes:
>> That is backpatched to 8.0.X. Does that not fix the problem reported?
> No, as andrew said, what this patch does, is allow values > 0x and
> at the same time validates the input to make sure it's valid utf8.
The impression I get is that most of th
Tom Lane wrote:
> "John Hansen" <[EMAIL PROTECTED]> writes:
> >> That is backpatched to 8.0.X. Does that not fix the problem reported?
>
> > No, as andrew said, what this patch does, is allow values > 0x and
> > at the same time validates the input to make sure it's valid utf8.
>
> The impre
Simon Riggs wrote:
> I've got a patch to submit that logs the EXEC phase, so you get just the
> SQL, not the parameters. [...]
I assume this replaces the current logging on Parse to avoid duplicate
logging?
What happens on syntax errors? It's useful to log the statement that
failed, but you will