Re: [HACKERS] Can we get patents?

On Sun, 8 May 2005, Alvaro Herrera wrote: Hackers, I was reading LWN.net and noticed an article about Eben Moglen's keynote at linux.conf.au. Apparently he advises free software projects to get patents on their best ideas. Eben encouraged free software developers to record their novel

Re: [HACKERS] Patch for collation using ICU

> Alvaro Herrera wrote: > > Sent: Sunday, May 08, 2005 2:49 PM > > To: John Hansen > > Cc: Tatsuo Ishii; pgman@candle.pha.pa.us; > > [EMAIL PROTECTED]; pgsql-hackers@postgresql.org > > Subject: Re: [HACKERS] Patch for collation using ICU > > > > On Sun, May 08, 2005 at 02:07:29PM +1000, John Hans

Re: [HACKERS] [GENERAL] Invalid unicode in COPY problem

> Tatsuo Ishii wrote: > > Sent: Sunday, May 08, 2005 12:01 PM > > To: [EMAIL PROTECTED] > > Cc: pgsql-general@postgresql.org; pgsql-hackers@postgresql.org > > Subject: Re: [HACKERS] [GENERAL] Invalid unicode in COPY problem > > > > We have developed patches which relaxes the character > > validat

[HACKERS] Can we get patents?

Hackers, I was reading LWN.net and noticed an article about Eben Moglen's keynote at linux.conf.au. Apparently he advises free software projects to get patents on their best ideas. Eben encouraged free software developers to record their novel inventions and to obtain patents on

Re: [HACKERS] Patch for collation using ICU

Alvaro Herrera wrote: > Sent: Sunday, May 08, 2005 2:49 PM > To: John Hansen > Cc: Tatsuo Ishii; pgman@candle.pha.pa.us; > [EMAIL PROTECTED]; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Patch for collation using ICU > > On Sun, May 08, 2005 at 02:07:29PM +1000, John Hansen wrote: > > Ta

Re: [HACKERS] [GENERAL] Invalid unicode in COPY problem

"John Hansen" <[EMAIL PROTECTED]> writes: > Tatsuo Ishii wrote: >> We have developed patches which relaxes the character >> validation so that PostgreSQL accepts invalid characters. > That is just plain 100% wrong!! That was my first reaction too. Why would this be a good idea? If someone does

Re: [HACKERS] Patch for collation using ICU

On Sun, May 08, 2005 at 02:07:29PM +1000, John Hansen wrote: > Tatsuo Ishii wrote: > > So Japanese(including ASCII)/UNICODE behavior is perfectly > > correct at this moment. > > Right, so you _never_ use accented ascii characters in Japanese? > (like è for example, whose uppercase is È) That

Re: [HACKERS] [GENERAL] Invalid unicode in COPY problem

Madison Kelly wrote: >Under most circumstances I would agree with you completely. In my > case though I have to decide between risking a loss of a > user's data or > attempt to store the file name in some manner that would > return the same > name used by the file system. > >The user

Re: [HACKERS] rendezvous

On Sat, May 07, 2005 at 10:43:46AM +0200, Jochem van Dieten wrote: > On 5/7/05, Alvaro Herrera wrote: > > On Fri, May 06, 2005 at 03:30:10PM -0700, Joshua D. Drake wrote: > >> > >> Rendezvous is the Apple network discovery protocol yes? That was renamed > >> Bonjour by apple due to a Trademark pr

Re: [HACKERS] [GENERAL] Invalid unicode in COPY problem

Tatsuo Ishii wrote: > Sent: Sunday, May 08, 2005 12:01 PM > To: [EMAIL PROTECTED] > Cc: pgsql-general@postgresql.org; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] [GENERAL] Invalid unicode in COPY problem > > We have developed patches which relaxes the character > validation so that Post

Re: [HACKERS] Patch for collation using ICU

Tatsuo Ishii wrote: > Sent: Sunday, May 08, 2005 10:09 AM > To: John Hansen > Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED]; > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Patch for collation using ICU > > > Bruce Momjian wrote: > > > > > > There are two reasons for that optimization --

Re: [HACKERS] Patch for collation using ICU

> I don't buy it. If current conversion tables does the right > thing, why we need to replace. Or if conversion tables are > not correct, why don't you fix it? I think the rule of > character conversion will not change frequently, especially > for LATIN languages. Thus maintaining cost is not t

Re: [HACKERS] Patch for collation using ICU

Tom Lane wrote: > "John Hansen" <[EMAIL PROTECTED]> writes: > > Btw, I had been planning to propose replacing every single > one of the > > built in charset conversion functions with calls to ICU > (thus making > > pg _depend_ on ICU), > > I find that fairly unacceptable ... especially given t

Re: [HACKERS] pl/pgsql enabled by default

Mike Mascari wrote: Correct, as the vulnerability exists within the 'SQL' language as well. The only difference is that enabling plpgsql by default changes it from a leak to a full blown flood. How does it make any difference at all? -Neil ---(end of broadcast)

Re: [HACKERS] pl/pgsql enabled by default

Andrew Dunstan wrote: Mike Mascari wrote: but the side effect function will only run (unless you set it with security definer) with the privileges of the caller - it won't grant visibility to things that user can't otherwise see. If the visibility is determined by view definitions, such as usi

Re: [HACKERS] pl/pgsql enabled by default

Mike Mascari wrote: Neil Conway wrote: Mike Mascari wrote: People who use views to achieve row security, which is a rather common paradigm, cannot allow users to create functions with side effects. Can you elaborate? I'm not sure I follow you. (I'll note anyway that (1) SQL functions can have s

Re: [HACKERS] Race conditions, race conditions!

Tatsuo Ishii wrote: > Are we going to put the fixes into 8.0.3 and so on? Or will it be > included in 8.0.4? We have removed 8.0.3 from the FTP servers and plan to re-release 8.0.3 and previous 7.X releases. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.

Re: [HACKERS] Race conditions, race conditions!

Are we going to put the fixes into 8.0.3 and so on? Or will it be included in 8.0.4? -- Tatsuo Ishii > I promised an analysis of the problems Jan Wieck uncovered yesterday, > so here it is. > > Jan had developed a testbed (which I hope he will post) that essentially > has a bunch of client thread

Re: [HACKERS] pl/pgsql enabled by default

Neil Conway wrote: Mike Mascari wrote: People who use views to achieve row security, which is a rather common paradigm, cannot allow users to create functions with side effects. Can you elaborate? I'm not sure I follow you. (I'll note anyway that (1) SQL functions can have side effects: CREATE F

Re: [HACKERS] pl/pgsql enabled by default

Mike Mascari wrote: People who use views to achieve row security, which is a rather common paradigm, cannot allow users to create functions with side effects. Can you elaborate? I'm not sure I follow you. (I'll note anyway that (1) SQL functions can have side effects: CREATE FUNCTION foo() RETURN

Re: [HACKERS] [GENERAL] Invalid unicode in COPY problem

We have developed patches which relaxes the character validation so that PostgreSQL accepts invalid characters. It works like this: 1) new postgresql.conf item "mbstr_check" added. 2) if mbstr_check = 0 then invalid characters are not accepted (same as current PostgreSQL behavior). This is the

Re: [HACKERS] pl/pgsql enabled by default

Neil Conway wrote: Andrew Sullivan wrote: This is not really analogous, because those are already on Security (in the limited sense of "disabling features by default") is not free; there is a tradeoff between security and convenience, security and administrative simplicity, and so on. Given that

Re: [HACKERS] Patch for collation using ICU

> Palle Girgensohn wrote: > > > > --On l?rdag, maj 07, 2005 23.15.29 +1000 John Hansen <[EMAIL PROTECTED]> > > wrote: > > > > > Btw, I had been planning to propose replacing every single one of the > > > built in charset conversion functions with calls to ICU (thus making pg > > > _depend_ on IC

Re: [HACKERS] Patch for collation using ICU

> Bruce Momjian wrote: (B> > (B> > There are two reasons for that optimization --- first, some (B> > locale support is broken and Unicode encoding with a C locale (B> > crashes (not an issue for ICU), and second, it is an (B> > optimization for languages like Japanese that want to use (B

[HACKERS] Fix PID file location?

Hey, folks, I've noticed a problem with alternate PGDATA locations. Here's how to reproduce: On 8.0.2 on RHAS4: 1) Initdb a directory (on my system, /pgdata/pgdata) 2) Move the .conf files to an alternate location ( /etc/pgsql/) 3) Set $PGDATA to the alternate location ( /etc/pgsql ) 4) Edit p

Re: [HACKERS] Patch for collation using ICU

"John Hansen" <[EMAIL PROTECTED]> writes: > Btw, I had been planning to propose replacing every single one of the > built in charset conversion functions with calls to ICU (thus making > pg _depend_ on ICU), I find that fairly unacceptable ... especially given the licensing questions, but in any c

Re: [HACKERS] pl/pgsql enabled by default

Andrew Sullivan wrote: This is not really analogous, because those are already on Which is my point: you're suggesting we retrofit a security policy onto PG that does not apply to the vast majority of the base system -- and that if applied would require fundamental changes. Indeed. But that doe

Re: [HACKERS] Race conditions, race conditions!

Greg Stark <[EMAIL PROTECTED]> writes: > I wonder if there's an argument for building assertion-enabled builds with > code that randomly yields the processor some percentage of time before and > after taking a lock. It wouldn't catch every case but it might help. Seems like that would mainly help

Re: [HACKERS] pl/pgsql enabled by default

Josh Berkus writes: > Before we get into more minutia regarding potential security risk of plpgsql, > are there any reasons *other* than security to not enable it? Several potential issues have already been mentioned in this thread, eg, what about shared library dependency vs linking plpgsql stat

Re: [HACKERS] Patch for collation using ICU

Tom Lane wrote: > "John Hansen" <[EMAIL PROTECTED]> writes: > > Where'd you get the licence from? > > It was the first thing I came across in their docs: > > http://icu.sourceforge.net/userguide/intro.html > > Looking more closely, it may be that this license is only > intended to apply to the

Re: [HACKERS] pgFoundry

On Saturday 07 May 2005 15:31, Josh Berkus wrote: > 2) Tracking bugs that were fixed (and features that were added) in > particular releases so that users know when they need to upgrade. one idea that has been quasi floated before would be something equivalent to Simon Riggs developer summaries

Re: [HACKERS] [PATCHES] Cleaning up unreferenced table files

Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Maybe we should take a different approach to the problem: > 1. Create new file with an extension to mark that it's not > yet committed (eg. 1234.notcommitted) This is pushing the problem into the wrong place, viz the lowest-level file access rou

Re: [HACKERS] pgFoundry

What does it mean to "track" the status of something? How would the status change except by discussion? What would be the point of announcing the status of something without allowing people to comment? No one said anything about not letting people comment or discuss. What I am suggesting is a bet

Re: [HACKERS] pgFoundry

Greg, > I'm rather surprised Postgres doesn't have a good bug tracking system. > That's something most projects find pretty essential. Strangely enough the > reason seems to be that Postgres really doesn't have many bugs... Unlike > web browsers or GUIs or most of the other free software projects

Re: [HACKERS] Race conditions, race conditions!

Tom Lane <[EMAIL PROTECTED]> writes: > The trick is to run this under astronomical load; 100 or so client > threads on a garden-variety PC is about right. I wonder if there's an argument for building assertion-enabled builds with code that randomly yields the processor some percentage of time be

Re: [HACKERS] pl/pgsql enabled by default

People: Before we get into more minutia regarding potential security risk of plpgsql, are there any reasons *other* than security to not enable it? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: Have you che

Re: [HACKERS] pl/pgsql enabled by default

On 2005-05-07, Tom Lane <[EMAIL PROTECTED]> wrote: > Neil Conway <[EMAIL PROTECTED]> writes: >> Users can already define SQL functions by default, which certainly >> provides "programmable features". I'm not quite sure what you mean by >> "user exits." > >> I guess I'm missing how pl/pgsql is a f

Re: [HACKERS] FC3 broken with HEAD

I think this has more to do with poor architectural decisions made in bugzilla. Things like storing the entire ticket history in one big record instead of normalizing it. This means you can't do anything to a ticket without munging through 10s of k of data. This also creates problems when multipl

Re: [HACKERS] [PATCHES] Cleaning up unreferenced table files

Maybe we should take a different approach to the problem: 1. Create new file with an extension to mark that it's not yet committed (eg. 1234.notcommitted) 2. ... 3. Take CheckpointStartLock 4. Write commit record to WAL, with list of created files. 5. rename created file (1234.notcommitted -> 12

Re: [HACKERS] [PATCHES] Patch for database locale settings

Description added to TODO: * Allow locale to be set at database creation Currently locale can only be set during initdb. No global tables have locale-aware columns. However, the database template used during database creation might have loc

Re: [HACKERS] Patch for collation using ICU

--On lördag, maj 07, 2005 10.58.09 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: "John Hansen" <[EMAIL PROTECTED]> writes: Where'd you get the licence from? It was the first thing I came across in their docs: http://icu.sourceforge.net/userguide/intro.html Looking more closely, it may be that this lice

Re: [HACKERS] pl/pgsql enabled by default

Neil Conway <[EMAIL PROTECTED]> writes: > Users can already define SQL functions by default, which certainly > provides "programmable features". I'm not quite sure what you mean by > "user exits." > I guess I'm missing how pl/pgsql is a fundamentally greater security risk. plpgsql has control s

Re: [HACKERS] to_char(interval) issues

Bruce, > * Prevent to_char() on interval from returning meaningless values > * Allow to_char() on interval values to accumulate the highest unit >   requested Sounds like it would cover my use cases. Others? -- Josh Berkus Aglio Database Solutions San Francisco ---(e

Re: [HACKERS] FC3 broken with HEAD

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Huh, RH's bugzilla is really slow. Are they using the > PostgreSQL-powered bugzilla? They are, but I think it's a fairly old version (7.3 IIRC). I'm still trying to get them to move some internal systems off 7.1 :-( regards, to

[HACKERS] Race conditions, race conditions!

I promised an analysis of the problems Jan Wieck uncovered yesterday, so here it is. Jan had developed a testbed (which I hope he will post) that essentially has a bunch of client threads all doing instances of the same transaction in READ COMMITTED mode. The intended database invariant is that t

Re: [HACKERS] FC3 broken with HEAD

On Sat, May 07, 2005 at 04:27:04PM +1000, Neil Conway wrote: > Tom Lane wrote: > >Yeah, we will. Please file a bugzilla entry for this though --- I > >concur that it is a linker bug. > > Okay, patch reverted. The RH bug is here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157126

Re: [HACKERS] pl/pgsql enabled by default

On Sat, May 07, 2005 at 02:52:57PM +1000, Neil Conway wrote: > > So would you have us disable all the non-essential builtin functions? > (Many of which have has security problems in the past.) What about the > builtin encoding conversions, non-btree indexes, or a myriad of features > that not a

Re: [HACKERS] Patch for collation using ICU

"John Hansen" <[EMAIL PROTECTED]> writes: > Where'd you get the licence from? It was the first thing I came across in their docs: http://icu.sourceforge.net/userguide/intro.html Looking more closely, it may be that this license is only intended to apply to the documentation and not the code ...

Re: [HACKERS] Patch for collation using ICU

John Hansen wrote: > Bruce Momjian wrote: > > > > There are two reasons for that optimization --- first, some > > locale support is broken and Unicode encoding with a C locale > > crashes (not an issue for ICU), and second, it is an > > optimization for languages like Japanese that want to use

Re: [HACKERS] pgFoundry

On Sat, 7 May 2005, Greg Stark wrote: But "tracking the status" of sub-projects is just not the kind of thing free software people do. They send emails when they have something to say. in defence of Joshua's idea, there are some "large projects" within our development that would be nice to see s

Re: [HACKERS] Patch for collation using ICU

--On lördag, maj 07, 2005 10.06.43 -0400 Bruce Momjian wrote: Palle Girgensohn wrote: --On l?rdag, maj 07, 2005 23.15.29 +1000 John Hansen <[EMAIL PROTECTED]> wrote: > Btw, I had been planning to propose replacing every single one of the > built in charset conversion functions with calls to IC

Re: [HACKERS] Patch for collation using ICU

Bruce Momjian wrote: > Palle Girgensohn wrote: > > > > --On l?rdag, maj 07, 2005 23.15.29 +1000 John Hansen > > <[EMAIL PROTECTED]> > > wrote: > > > > > Btw, I had been planning to propose replacing every single one of > > > the built in charset conversion functions with calls to ICU (thus > >

Re: [HACKERS] Patch for collation using ICU

Palle Girgensohn wrote: > >> This is because in the standard postgres implementation, upper/lower is > >> done one character at the time. A proper upper/lower cannot do it that > >> way. Other known example is in Turkish, where an ? (?) should look > >> different whether it is an initial letter o

Re: [HACKERS] Patch for collation using ICU

--On lördag, maj 07, 2005 09.52.59 -0400 Bruce Momjian wrote: Palle Girgensohn wrote: >> Also, apparently, ICU is installed by default in many linux >> distributions, and usually it is version 2.8. Some linux users have >> asked me if there are plans for a patch that works with ICU 2.8. >> Th

Re: [HACKERS] Patch for collation using ICU

> It seems 3.2 has much more support and bug fixes, I'm not > sure if we should really consider 2.8? As I said, probably not worth the effort. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.post

Re: [HACKERS] Patch for collation using ICU

Palle Girgensohn wrote: > > --On l?rdag, maj 07, 2005 23.15.29 +1000 John Hansen <[EMAIL PROTECTED]> > wrote: > > > Btw, I had been planning to propose replacing every single one of the > > built in charset conversion functions with calls to ICU (thus making pg > > _depend_ on ICU), as this woul

Re: [HACKERS] Patch for collation using ICU

Bruce Momjian wrote: > > There are two reasons for that optimization --- first, some > locale support is broken and Unicode encoding with a C locale > crashes (not an issue for ICU), and second, it is an > optimization for languages like Japanese that want to use > unicode, but don't need a lo

Re: [HACKERS] Patch for collation using ICU

Andrew Dunstan wrote: > > > John Hansen wrote: > > >Here is the list of encoding names and aliases the ICU accepts as of > >3.2: > >(it's a bit long...) > > > >UTF-8 ibm-1208 ibm-1209 ibm-5304 ibm-5305 windows-65001 cp1208 > >UTF-16 ISO-10646-UCS-2 unicode csUnicode ucs-2 > > > > > > > [snip]

Re: [HACKERS] Patch for collation using ICU

Palle Girgensohn wrote: > >> Also, apparently, ICU is installed by default in many linux > >> distributions, and usually it is version 2.8. Some linux users have > >> asked me if there are plans for a patch that works with ICU 2.8. That's > >> probably a good idea. IBM and the ICU folks seem to

Re: [HACKERS] Patch for collation using ICU

> -Original Message- > From: Andrew Dunstan [mailto:[EMAIL PROTECTED] > Sent: Saturday, May 07, 2005 11:39 PM > To: John Hansen > Cc: Palle Girgensohn; Bruce Momjian; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Patch for collation using ICU > > > > John Hansen wrote: > > >

Re: [HACKERS] Patch for collation using ICU

John Hansen wrote: > > --On l?rdag, maj 07, 2005 22.53.46 +1000 John Hansen > > <[EMAIL PROTECTED]> > > wrote: > > > > > Errm,... initdb --encoding UNICODE --locale C > > > > You mean that ICU *shall* be used even for the C locale, and > > not as Bruce suggested here: > > Yes, that's exactly w

Re: [HACKERS] Patch for collation using ICU

> Did you try the latest patch? Maybe it will help, and if not, it will > (hopefully) give a lot more informative error messages. No, and I got rid of my debian boxes @ home. The patch required a certain amount of modifications too, to even compile with 2.8. So I guess it's a valid question to as

Re: [HACKERS] Patch for collation using ICU

John Hansen wrote: Here is the list of encoding names and aliases the ICU accepts as of 3.2: (it's a bit long...) UTF-8 ibm-1208 ibm-1209 ibm-5304 ibm-5305 windows-65001 cp1208 UTF-16 ISO-10646-UCS-2 unicode csUnicode ucs-2 [snip] Don't we use "unicode" as an alias for UTF-8 ? cheers andrew ---

Re: [HACKERS] Patch for collation using ICU

--On lördag, maj 07, 2005 23.33.31 +1000 John Hansen <[EMAIL PROTECTED]> wrote: -Original Message- From: Palle Girgensohn [mailto:[EMAIL PROTECTED] Sent: Saturday, May 07, 2005 11:33 PM To: John Hansen; Bruce Momjian Cc: pgsql-hackers@postgresql.org Subject: RE: [HACKERS] Patch for coll

Re: [HACKERS] Patch for collation using ICU

--On lördag, maj 07, 2005 23.15.29 +1000 John Hansen <[EMAIL PROTECTED]> wrote: Btw, I had been planning to propose replacing every single one of the built in charset conversion functions with calls to ICU (thus making pg _depend_ on ICU), as this would seem like a cleaner solution than for us to

Re: [HACKERS] Patch for collation using ICU

> -Original Message- > From: Palle Girgensohn [mailto:[EMAIL PROTECTED] > Sent: Saturday, May 07, 2005 11:33 PM > To: John Hansen; Bruce Momjian > Cc: pgsql-hackers@postgresql.org > Subject: RE: [HACKERS] Patch for collation using ICU > > > > --On lördag, maj 07, 2005 22.22.52 +1000

Re: [HACKERS] Patch for collation using ICU

--On lördag, maj 07, 2005 22.22.52 +1000 John Hansen <[EMAIL PROTECTED]> wrote: I use this patch in production on one FreeBSD 4.10 server at the moment. With the latest version, I've had no problems. Logging is swithed on for now, and it shows no signs of ICU complaining. I'd like more reports o

Re: [HACKERS] Patch for collation using ICU

> -Original Message- > From: Palle Girgensohn [mailto:[EMAIL PROTECTED] > Sent: Saturday, May 07, 2005 11:30 PM > To: John Hansen; Bruce Momjian > Cc: pgsql-hackers@postgresql.org > Subject: RE: [HACKERS] Patch for collation using ICU > > > > --On lördag, maj 07, 2005 23.25.15 +1000

Re: [HACKERS] Patch for collation using ICU

--On lördag, maj 07, 2005 23.25.15 +1000 John Hansen <[EMAIL PROTECTED]> wrote: Palle Girgensohn wrote: I'm aware of that. It might help for unicode, but there are a bunch of other encodings. IANA has decided that utf-8 has *no* aliases, hence only utf-8 (with dash, but case insensitve) is accep

Re: [HACKERS] Patch for collation using ICU

Palle Girgensohn wrote: > I'm aware of that. It might help for unicode, but there are a > bunch of > other encodings. IANA has decided that utf-8 has *no* > aliases, hence only > utf-8 (with dash, but case insensitve) is accepted. Perhaps ICU is > fogiving, I don't remember/know, but I think w

Re: [HACKERS] Patch for collation using ICU

--On lördag, maj 07, 2005 08.37.05 -0400 Bruce Momjian wrote: Palle Girgensohn wrote: > > Is this patch ready for application? I don't think so, not quite. I have not had any positive reports from linux users, this is only tested in a FreeBSD environment. I'd say it needs some more testing. O

Re: [HACKERS] Patch for collation using ICU

Btw, I had been planning to propose replacing every single one of the built in charset conversion functions with calls to ICU (thus making pg _depend_ on ICU), as this would seem like a cleaner solution than for us to maintain our own conversion tables. ICU also has a fair few conversions that

Re: [HACKERS] Patch for collation using ICU

> --On lördag, maj 07, 2005 22.53.46 +1000 John Hansen > <[EMAIL PROTECTED]> > wrote: > > > Errm,... initdb --encoding UNICODE --locale C > > You mean that ICU *shall* be used even for the C locale, and > not as Bruce suggested here: Yes, that's exactly what I mean. > > >> I do have a few qu

Re: [HACKERS] Patch for collation using ICU

Bruce Momjian wrote: > Palle Girgensohn wrote: > > > > > > Is this patch ready for application? > > > > I don't think so, not quite. I have not had any positive > reports from > > linux users, this is only tested in a FreeBSD environment. > I'd say it > > needs some more testing. > > OK. > >

Re: [HACKERS] Patch for collation using ICU

--On lördag, maj 07, 2005 22.53.46 +1000 John Hansen <[EMAIL PROTECTED]> wrote: Errm,... initdb --encoding UNICODE --locale C You mean that ICU *shall* be used even for the C locale, and not as Bruce suggested here: I do have a few questions: Why don't you use the lc_ctype_is_c() part of this t

Re: [HACKERS] Patch for collation using ICU

Errm,... initdb --encoding UNICODE --locale C > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Hansen > Sent: Saturday, May 07, 2005 10:23 PM > To: Palle Girgensohn; Bruce Momjian > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Patch

Re: [HACKERS] Patch for collation using ICU

Palle Girgensohn wrote: > > > > Is this patch ready for application? > > I don't think so, not quite. I have not had any positive reports from linux > users, this is only tested in a FreeBSD environment. I'd say it needs some > more testing. OK. > Also, apparently, ICU is installed by default

[HACKERS]

unsubscribe ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Patch for collation using ICU

> > I use this patch in production on one FreeBSD 4.10 server at > the moment. > With the latest version, I've had no problems. Logging is > swithed on for > now, and it shows no signs of ICU complaining. I'd like more > reports on > Linux, though. I currently use this on gentoo with ICU3.2

Re: [HACKERS] Patch for collation using ICU

--On fredag, maj 06, 2005 22.57.59 -0400 Bruce Momjian wrote: Is this patch ready for application? http://people.freebsd.org/~girgen/postgresql-icu/pg-802-icu-2005-05-06.d iff.gz The web site is: http://people.freebsd.org/~girgen/postgresql-icu/readme.html I don't think so, not quite.

Re: [HACKERS] Patch for collation using ICU

--On fredag, maj 06, 2005 23.31.20 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Bruce Momjian writes: Is this patch ready for application? Not until ICU is released under a BSD license ... It's not GPL anyway. Seems pretty much like the BSD license, at least more BSD-ish than GPL-ish.

Re: [HACKERS] pgFoundry

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > >>No that is public presentation of the project not project development. > > I don't see that people are going to be able to participate in development > > if they don't use the mailing lists. > > I am not arguing that but public mailing lists are

Re: [HACKERS] pl/pgsql enabled by default

Simon Riggs wrote: I support Andrew's comment, though might reword it to "Don't enable anything that gives users programmable features or user exits by default". Users can already define SQL functions by default, which certainly provides "programmable features". I'm not quite sure what you mean b

Re: [HACKERS] pl/pgsql enabled by default

On Sat, 2005-05-07 at 14:52 +1000, Neil Conway wrote: > Andrew Sullivan wrote: > > Sure it is. "Don't enable anything you don't need," is the first > > security rule. Everything is turned off by default. If you want it, > > enable it. > > So would you have us disable all the non-essential built

Re: [HACKERS] rendezvous

On 5/7/05, Alvaro Herrera wrote: > On Fri, May 06, 2005 at 03:30:10PM -0700, Joshua D. Drake wrote: >> >> Rendezvous is the Apple network discovery protocol yes? That was renamed >> Bonjour by apple due to a Trademark problem. > > Maybe we should name it Zeroconf. Is the implemented protocol IE

Re: [HACKERS] Patch for collation using ICU

Where'd you get the licence from? None of that is in the licence I'm reading! (http://www-306.ibm.com/software/globalization/icu/index.jsp) (http://www-306.ibm.com/software/globalization/icu/license.jsp) ... John > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED