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
-Neil
---(end of
On Sat, 7 May 2005, Markus Bertheau wrote:
See FC3 broken with HEAD.
I have Slackware 10.1
, 06/05/2005 23:54 +0400, Oleg Bartunov :
Just got this problem.
Regards,
Oleg
_
Oleg Bartunov, sci.researcher,
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]
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 IETF
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 builtin
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 by
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 no place to
--On fredag, maj 06, 2005 23.31.20 -0400 Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
--On fredag, maj 06, 2005 22.57.59 -0400 Bruce Momjian
pgman@candle.pha.pa.us 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
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
unsubscribe
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
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 in many
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 for
--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
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.
Also, apparently,
--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 questions:
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
--On lördag, maj 07, 2005 08.37.05 -0400 Bruce Momjian
pgman@candle.pha.pa.us 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
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 we
--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
-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 John
--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 on
-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 John
--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
--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
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
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
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 what I mean.
There
-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:
Here is the
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 consider
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]
Don't we use
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 locale
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 would seem like
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?
--On lördag, maj 07, 2005 09.52.59 -0400 Bruce Momjian
pgman@candle.pha.pa.us 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
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 or not. This
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
making pg _depend_
--On lördag, maj 07, 2005 10.06.43 -0400 Bruce Momjian
pgman@candle.pha.pa.us 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
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 some
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
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 ...
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 all
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
Huh,
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
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, tom
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
---(end
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 structures
--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 license
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
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 -
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
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 fundamentally
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
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
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 out
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
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
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
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 documentation
Josh Berkus josh@agliodbs.com 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
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 you
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
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 case.
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 unicode,
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 would
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 I
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()
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
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 threads
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
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
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
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
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
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 the
licensing
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 too
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 --- first,
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 PostgreSQL
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 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 (or one
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 isn't
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 want an
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:
Tatsuo
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
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
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:
86 matches
Mail list logo
