Hi,
I just run into this bug
(http://archives.postgresql.org/pgsql-bugs/2008-02/msg00010.php). In my
case, Roundup (Python bug tracker) is trying to CREATE DATABASE WITH
ENCODING='UNICODE' in an 8.3.4 cluster created with LATIN1 encoding, and
it gets the error:
encoding UTF8 does not match
Joe <[EMAIL PROTECTED]> writes:
> I can understand that creating a LATIN2, EUC_CN or some other encoding
> in a LATIN1 cluster may cause problems, but don't quite see how UTF-8
> can be a problem since in essence it includes the others. Perhaps
> someone can provide further explanation?
The lo
Hi Tom,
Tom Lane wrote:
Why does it have to be LATIN1? If your answer is "my client code deals
in LATIN1", just set client_encoding = LATIN1. You could do that with
ALTER DATABASE SET or possibly ALTER USER SET so that it's transparent
to the clients.
The client code is primarily encoding
Joe <[EMAIL PROTECTED]> writes:
> Going back to my options, are you saying that if I re-initdb the 8.3
> cluster to UTF8, restore the LATIN1 db as UTF8, and then do "set
> client_encoding = LATIN1" in the application code, then everything will
> work fine, even if the machine locale remains en_U
[EMAIL PROTECTED] napsal(a):
The following bug has been logged online:
Bug reference: 4496
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: Latest cvs
Operating system: Error in source code
Description:Memory leak in pg_dump.c?
Details:
In file sr
Harvey, Allan AC napsal(a):
Zdenek,
Hmm, It does not look good. Your OS does not return proper
information about
codeset. Following code is broken:
setlocale(LC_CTYPE, ctype);
sys = nl_langinfo(CODESET);
sys = strdup(sys);
See
http://www.opengroup.org/onlinepubs/0096
On Oct 25, 2008, at 05:35, Tom Lane wrote:
Seems to be fixed in HEAD:
regression=# SELECT '{foo}'::name[] <> '{bar}'::name[];
ERROR: operator is only a shell: name[] <> name[]
LINE 1: SELECT '{foo}'::name[] <> '{bar}'::name[];
Great. Is it something that could be backported, or is it not wor
--- Zdenek Kotala <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] napsal(a):
> > The following bug has been logged online:
> >
> > Bug reference: 4496
> > Logged by:
> > Email address: [EMAIL PROTECTED]
> > PostgreSQL version: Latest cvs
> > Operating system: Error in source
Aggro wrote:
>
> --- Zdenek Kotala <[EMAIL PROTECTED]> wrote:
>
> > I think all information is collected and they are
> > used for all pg_dump run. It
> > does not make sense to free them. See line 725.
>
> But is the memory freed at some point? E.g. when
> program shuts down? If it is not fre
Aggro <[EMAIL PROTECTED]> writes:
> But is the memory freed at some point? E.g. when
> program shuts down? If it is not freed ever, then it
> is a memory leak.
Program-local memory is *always* freed at process termination. Any
operating system that failed to handle this would be broken beyond
usa
> A pg_dump run is comparatively short-lived, so if Zdenek is right then
> there's no important leak here -- we're counting on program exit to
> release the memory. There's probably little point in releasing things
> earlier than that.
Well, I'd tend to consider any logical part of a program that
Tom Lane wrote:
Plan B would be to set the database locale to C, which is
encoding-agnostic and hence allows different databases to have different
encodings. Do you actually need en_US sort order?
I wasn't aware of the difference in sort orders until about two months
ago when i had to comp
Tomáš Szépe wrote:
A pg_dump run is comparatively short-lived, so if Zdenek is right then
there's no important leak here -- we're counting on program exit to
release the memory. There's probably little point in releasing things
earlier than that.
Well, I'd tend to consider any logical part of
13 matches
Mail list logo
