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
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
"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
> -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
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
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
> 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
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
