OK, I've been spreading rumours about fixing the internationalization
problems, so let me make it a bit more clear. Here are the problems that
need to be fixed:
- Only one locale per process possible.
- Only one gettext-language per process possible.
- lc_collate and lc_ctype need to
On Mon, 24 Nov 2003, Peter Eisentraut wrote:
1. Take out the character set conversion routines from the backend and
make them a library of their own. This could possibly be modelled after
iconv, but not necessarily. Or we might conclude that we can just use
iconv in the first place.
2.
Tatsuo Ishii writes:
3. Implement Unicode collation algorithm and character classification
routines that are aware of 1. Use that in place of system locale
routines.
I don't see a relationship between Unicode and the one you are going
to replace the system locale routines. If you are
Dennis Bjorklund writes:
Force all translations to be in unicode and convert to other client
encodings if needed. There is no need to support translations stored using
different encodings.
Tell that to the Japanese.
Couldn't we use some library that already have this, like glib (or
Have you looked at what is available from
http://oss.software.ibm.com/icu/ ?
Seems they have a compatible license, but use some C++.
Andreas
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
On Tue, 25 Nov 2003, Peter Eisentraut wrote:
Force all translations to be in unicode and convert to other client
encodings if needed. There is no need to support translations stored using
different encodings.
Tell that to the Japanese.
I've always thought unicode was enough to even
On Tue, 25 Nov 2003, Peter Eisentraut wrote:
Force all translations to be in unicode and convert to other client
encodings if needed. There is no need to support translations stored using
different encodings.
Tell that to the Japanese.
I've always thought unicode was enough to
Hans,
I don't understand the statement about missing DECLARE CURSOR ? The
backend supports it?
Dave
On Sun, 2003-11-23 at 12:12, Hans-Jürgen Schönig wrote:
Peter Eisentraut wrote:
I was at the ObjectWeb Conference today; ObjectWeb
(http://www.objectweb.org) being a consortium that has
On Tue, 25 Nov 2003, Tatsuo Ishii wrote:
I'm tired of telling that Unicode is not that perfect. Another gottcha
with Unicode is the UTF-8 encoding (currently we use) consumes 3
bytes for each Kanji character, while other encodings consume only 2
bytes. IMO 3/2 storage ratio could not be
Hans-Jürgen Schönig writes:
Especially the disaster recovery mechanism and things such as adding new
masters need some more work.
Yes, someone is working on automatic recovery (which would extend to
adding new masters by starting recovery from zero). In fact, they're just
across town from you
On Tue, 25 Nov 2003, Tatsuo Ishii wrote:
I'm tired of telling that Unicode is not that perfect. Another gottcha
with Unicode is the UTF-8 encoding (currently we use) consumes 3
bytes for each Kanji character, while other encodings consume only 2
bytes. IMO 3/2 storage ratio could not be
Peter Eisentraut wrote:
Bruce Momjian writes:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
Except that you can't open connections to the outside from
On Monday 24 November 2003 03:34 pm, David Fetter wrote:
I just tried building 0.3PGDG on Redhat 9, and got:
# rpmbuild --rebuild postgresql-7.4-0.3PGDG.src.rpm
[snip]
checking krb5.h usability... no
checking krb5.h presence... no
checking for krb5.h... no
configure: error: header file
Bruce Momjian wrote:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
As Peter pointed out, these machines are firewalled. But presumably one could upload a
Hello,
I've run across a pretty serious problem with pg_autovacuum.
pg_autovacuum looses track of any table that's ever been truncated
(possibly other situations too). When i truncate a table it gets a
new relfilenode in pg_class. This is a problem because pg_autovacuum
assumes
Hello All,
I was looking thr. the source and thought it would be worth to seek opinion on
this proposal.
From what I understood so far, the core shared memory handling is done in
pgsql/src/backend/port/sysv_shmem.c. It is linked by configure as per the
runtime environment.
So I need to write
Peter Eisentraut [EMAIL PROTECTED] writes:
Dennis Bjorklund writes:
Couldn't we use some library that already have this, like glib (or
something else). If it's not up to what we need, than fix that library
instead.
I wasn't aware that glib had this. I'll look.
Of course the trouble with
Peter Eisentraut [EMAIL PROTECTED] writes:
Actually, what will more likely happen is that we'll define a collation as
a collection of one or more support functions, the equivalents of
strxfrm() and possibly a few more. Then it will be up to those functions
to define the collation order. The
Tom Lane [EMAIL PROTECTED] writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
I wasn't aware that glib had this. I'll look.
Of course the trouble with relying on glibc is that we'd have no solution
for platforms that don't use glibc.
glib != glibc. glib is the low-level library used
Dennis Bjorklund kirjutas T, 25.11.2003 kell 14:51:
On Tue, 25 Nov 2003, Tatsuo Ishii wrote:
I'm tired of telling that Unicode is not that perfect.
Of course not, but neither is the current multibyte with only marginal
support for unicode (many people actually need upper()/lower() )
Shridhar Daithankar [EMAIL PROTECTED] writes:
I was looking thr. the source and thought it would be worth to seek
opinion on this proposal.
This has been discussed and rejected before. See the archives.
regards, tom lane
---(end of
Andrew Dunstan wrote:
Bruce Momjian wrote:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
As Peter pointed out, these machines are firewalled. But
Peter Eisentraut [EMAIL PROTECTED] writes:
2. Reimplement gettext to use 1. and allow switching of language and
encoding at run-time.
3. Implement Unicode collation algorithm and character classification
routines that are aware of 1. Use that in place of system locale
routines.
This
Josh, Hans, et. al.
Please take this thread OFF LIST IMMEDIATELY.
Its content is no longer appropriate for the Hackers mailing list, and we get
enough traffic. Flamewars are not a part of our community.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
As Peter pointed out, these
In case of WAL per database, the operations done on a shared catalog from a
backend would need flushing system WAL and database WAL to ensure such
transaction commit. Otherwise only flushing database WAL would do.
I don't think that is a good idea. If you want databases separated you should
On Mon, Nov 24, 2003 at 07:25:56PM +0100, Peter Eisentraut wrote:
Currently, when you specify --with-openssl, then configure automatically
adds -L/usr/local/ssl/lib to LDFLAGS if that directory exists. This would
pick up the wrong directory if you are in 64-bit mode. Analogous behavior
On Tue, Nov 25, 2003 at 08:40:57PM +0900, Tatsuo Ishii wrote:
On Tue, 25 Nov 2003, Peter Eisentraut wrote:
I've always thought unicode was enough to even represent Japanese. Then
the client encoding can be something else that we can convert to. In any
way, the encoding of the message
On Sun, 23 Nov 2003, Tom Lane wrote:
Actually I'd suggest text[], as there is no good reason to pad the
array entries to a fixed length.
I've implemented this part now and it stores the paremeter names in the
pg_proc table as a text[] field.
However, in the parser I use IDENT to get the
Dennis Bjorklund [EMAIL PROTECTED] writes:
However, in the parser I use IDENT to get the parameter names and already
in the lexer the IDENT tokens are truncated to length NAMEDATALEN.
Right. What's the problem?
regards, tom lane
---(end of
Hans, Josh,
Please take this thread OFF LIST IMMEDIATELY.
Sorry. Not enough coffee this AM -- should know better than to send e-mail
when I'm short beans.
Overreacted a bit, there.Apologies.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end
Greg Stark writes:
This sounds like you want to completely reimplement all of the locale handling
provided by the OS? That seems like a dead-end approach to me. There's no way
your handling will ever be as complete or as well optimized as some OS's.
Actually, I'm pretty sure it will be more
On Tue, 25 Nov 2003, Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
However, in the parser I use IDENT to get the parameter names and already
in the lexer the IDENT tokens are truncated to length NAMEDATALEN.
Right. What's the problem?
It's strange to allow identifiers to be
Peter Eisentraut kirjutas T, 25.11.2003 kell 21:13:
Greg Stark writes:
This sounds like you want to completely reimplement all of the locale handling
provided by the OS? That seems like a dead-end approach to me. There's no way
your handling will ever be as complete or as well optimized
Dennis Bjorklund [EMAIL PROTECTED] writes:
and the identifier x (as all identifiers) can not be too long. Still, one
can create the function and update the system table by hand to change x to
a longer name. Doesn't that sound ugly to you?
It has always been, and likely always will be,
Kurt Roeckx [EMAIL PROTECTED] writes:
You can encode unicode in different ways, and UTF-8 is only one
of them. Is there a problem with using UCS-2 (except that it
would require more storage for ASCII)?
UCS-2 is impractical without some *extremely* wide-ranging changes in
the backend. To take
Hi,
Don't know if it's bad, but make check reports a regression failure on
join.
Here's the regression.diffs
*** ./expected/join.out Thu Sep 25 08:58:06 2003
--- ./results/join.out Tue Nov 25 23:46:27 2003
***
*** 1732,1739
| 6 | 6 | six |
| 7 | 7 | seven |
Yurgis Baykshtis [EMAIL PROTECTED] writes:
I just noticed that the rename panic errors like this one:
PANIC: rename from /data/pg_xlog/0003001F to
/data/pg_xlog/0003002C (initialization of log file 3, segment 44)
failed: No such file or directory
come shortly AFTER the
[EMAIL PROTECTED] writes:
Don't know if it's bad, but make check reports a regression failure on
join.
I believe we'd determined that this is an acceptable platform-specific
behavior.
regards, tom lane
---(end of
About storing data in the database, I would expect it to work with any
encoding, just like I would expect pg to be able to store images in any
format.
What's stopping us supporting the other Unicode encodings, eg. UCS-16
which could save Japansese storage space.
Chris
Dennis Bjorklund [EMAIL PROTECTED] writes:
It's strange to allow identifiers to be of any length in the system
table when there is no way to create it using normal syntax.
I agree with Tom -- that doesn't seem strange to me at all.
-Neil
---(end of
On Mon, Nov 24, 2003 at 11:08:44PM -0600, Jim C. Nasby wrote:
Has anyone looked at using replication as a migration method? If
Looked at? Sure. Heck, I've done it. Yes, it works. Is it
painless? Well, that depends on whether you think using erserver is
painless. ;-) It's rather less
On Fri, Nov 21, 2003 at 07:51:17PM -0500, Greg Stark wrote:
The second vacuum waits for the lock to become available. If the
situation got really bad there could end up being a growing queue
of vacuums waiting.
Those of us who have run into this know that the situation got
really bad is
Greg Stark [EMAIL PROTECTED] writes:
The only advantage to adding locales per-column and/or per-index is the
notational simplicity.
Well, actually, the reason we are interested in doing it is the SQL spec
demands it.
regards, tom lane
---(end of
44 matches
Mail list logo
