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
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 ea
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 downt
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 broadcast)--
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
-
[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 broadcast)-
"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
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 |
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
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, po
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 opti
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 identifie
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
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
---(en
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 b
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 par
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
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
> e
> 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 shou
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 machin
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
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.
T
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 fi
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 broadcast
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() )
> A
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 libr
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.
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 troubl
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
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 pg_cla
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 snaps
here's a patch that joins on pg_class.oid instead of
pg_class.relfilenode, also i have renamed the table structure from
relfilenode to relid.
patch
Description: Binary data
---(end of broadcast)---
TIP 9: the planner will ignore your desire to
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 out
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 fi
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 ne
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 yo
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 ne
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, 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 unicod
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 ev
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
subscr
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
> som
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 yo
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.
>
>
> 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
45 matches
Mail list logo
