On a fresh installation of postgrsql 8.1if you drop the
'postgres' database,
psql, createdb, etc. no longer works.
psql -l; ignores -dtemplate1, and createdb doesn't have such an option.
Maybe it should fallback to template1 if the postgres database doesn't
exist?
... John
Jaime Casanova Wrote:
But MERGE isn't REPLACE...
REPLACE will delete old records to insert new ones; MERGE try
to insert and if the record exists then can UPDATE just a few
values, maybe incrementing them with a value (all the
calculation are doing by the MERGE)
That sounds like
I Wrote:
From the mysql manual:
'REPLACE works exactly like INSERT, except that if an old
record in the table has the same value as a new record for a
PRIMARY KEY or a UNIQUE index, the old record is deleted
before the new record is inserted. See Section 13.2.4,
INSERT Syntax.'
It
Tom Lane Wrote:
Surely they require a unique constraint --- else the behavior
isn't even well defined, is it?
From the mysql manual:
'REPLACE works exactly like INSERT, except that if an old record in the
table has the same value as a new record for a PRIMARY KEY or a UNIQUE
index, the old
Good people,
Just had a thought!
Might it be worth while protecting the postmaster from an OOM Kill on
Linux by setting /proc/{pid}/oom_adj to -17 ?
(Described vaguely in mm/oom_kill.c)
Kind Regards,
John Hansen
---(end of broadcast)---
TIP 1
Martijn van Oosterhout Wrote:
Has it actually happened to you? PostgreSQL is pretty good
about its memory usage. Besides, seems to me it should be an
system admisitrator descision.
No, Just came across this by chance, and thought it might be a good
idea.
Perhaps as a postgresql.conf
Tom Lane Wrote:
(a) wouldn't that require root privilege? (b) how would we
determine whether we are on a system to which this applies?
(c) is it actually documented in a way that makes you think
it'll be a permanently supported feature (ie, somewhere
outside the source code)?
(a) No,
Martijn van Oosterhout Wrote:
All we lose is the ability to say USING [arbitrary op]. Does
anybody
use this. Would people object to requiring the operator after
USING
to be part of an operator class?
Hmmm ... would this prevent the hackish workaround for
case-insensitive sort?
Good on ya, Dave!
... John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gavin M. Roy
Sent: Friday, August 26, 2005 1:51 PM
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [ANNOUNCE] Welcome Core Team member Dave Page
Congrats Dave!
Merlin Moncure Wrote:
... Be sure to mix in a request for
better Unicode support at the same time, Dave loves that.
As do I... :)
... John
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
Kevin McArthur Wrote:
Should the postgresql project also be looking at CLDR for
cross-platform unicode support?
Afaict, from the ICU website, ICU too uses CLDR.
Why reinvent the wheel?
... John
---(end of broadcast)---
TIP 1: if
Tom Lane [mailto:[EMAIL PROTECTED] Wrote:
There's no HOWTO for rtree either. Again, my point is not
that one couldn't be written; it's that we would probably be
better off spending the effort on a HOWTO for gist.
No, but the _current_ implementation of the rtree operators are ver much
self
Tom Lane Wrote:
... but rtree has always
been marginal, and it's very hard to see where it can win over gist.
Simplicity!
Implementing rtree operators and support functions is FAR simpler than
implementing the GiST equivalents.
For example, suppose all you want to implement is the ~
I'd vote that these functions should follow the semantics of the , and
operators.
(NULL x) is NULL;
... John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Friday, June 24, 2005 11:21 PM
To: Pavel Stehule
Cc:
I'll look at problem after GiST concurrency. Fixing
rtree_gist is bug a fix, not a new feature, so I'm not
limited by 1 July.
Wont fixing rtree(_gist) require initdb, since the behaviour of the
operators will change?
... John
---(end of
Bruno Wolff III [mailto:[EMAIL PROTECTED] Wrote
I think the real problem is that check constraints on tables
aren't used by the optimizer. Given that, what you have below
is expected.
There has been talk about that in the past, but I haven't
heard anything recently about someone
Bruno Wolff III [mailto:[EMAIL PROTECTED] Wrote:
You only want to use partial indexes when they don't cover
the whole table. They make sense to enforce uniqueness of a
column under some condition and when you can save significant
space (becuase the condition is only satisfied for a small
Someone Wrote:
Should not check constraint act as the first filter? The index should
ideally be scanned only when the check constraint is passed by the
search
criteria but surprisingly it did not happen. The explain analyze
showed
cost for index scans of subtables that cannot contain rows
Hi all,
CREATE TYPE my_type AS (
a int,
b int,
c int,
d int,
e int
);
CREATE FUNCTION text_to_my_type(text)
RETURNS my_type
AS 'my_lib.so'
LANGUAGE 'C' IMMUTABLE STRICT;
CREATE CAST (text AS my_type) WITH FUNCTION text_to_my_type (text);
SELECT
Michael Fuhr [mailto:[EMAIL PROTECTED] Wrote:
Sent: Saturday, June 18, 2005 9:56 PM
To: John Hansen
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Returning Composite Types from C functions
On Sat, Jun 18, 2005 at 09:18:34PM +1000, John Hansen wrote:
SELECT ('1:2:3:4:5'::text
Yes, it worked for me,...
But my point is the workaround shouldn't be nescessary
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 18, 2005 11:36 PM
To: John Hansen
Cc: Michael Fuhr; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Returning
Josh,
Both of these would be fine as add-ins to be distributed *separately*
through
pgFoundry or even the mirrors if they prove popular.
Bundling them in unified distribution binaries with PostgreSQL would
be a
significant problem.
You see this in other projects all the time:
INFO: analyzing pg_catalog.pg_depend
INFO: pg_depend: 27 pages, 3866 rows sampled, 3866 estimated total
rows
INFO: free space map: 423 relations, 88475 pages stored; 431200 total
pages needed
DETAIL: Allocated FSM size: 4000 relations + 8 pages = 705 kB
shared memory.
This, on a database
Given the following snippet:
HeapTupleHeader tuple;
Datum temp;
bool isnull;
tuple = PG_GETARG_HEAPTUPLEHEADER(0);
temp = GetAttributeByName(tuple, data, isnull);
When using this for a btree operator
Tom Lane [mailto:[EMAIL PROTECTED] wrote:
John Hansen [EMAIL PROTECTED] writes:
Given the following snippet:
HeapTupleHeader tuple;
Datum temp;
bool isnull;
tuple = PG_GETARG_HEAPTUPLEHEADER(0);
temp
Is there any reason why we would not be able to use LGPL code in PG?
... John
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
What about GPL ?
I assume that's out of the question!
-Original Message-
From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 15, 2005 11:59 AM
To: John Hansen
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] LGPL
We already do ... libreadline
Ooooh
I got the impression that using GPL libraries was a Bad Thing(tm)
... John
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 15, 2005 12:15 PM
To: Marc G. Fournier
Cc: John Hansen; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS
So, what's the story with readline?
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 15, 2005 12:11 PM
To: John Hansen
Cc: Marc G. Fournier; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] LGPL
John Hansen wrote:
What about GPL ?
I
Agreed.
With libreadline, we are not taking their code or
distributing it, but merely linking to it if it exists. Now,
some say that is enough to make us GPL, but many don't agree
with that interpretation.
Right,. That's actually exactly what I meant: using GPL/LGPL libraries
by
Tom Lane [mailto:[EMAIL PROTECTED] Wrote:
John Hansen [EMAIL PROTECTED] writes:
Is there any reason why we would not be able to use LGPL code in PG?
Another point of view on this: it's OK to use LGPL code if
it's available on the local platform, so long as we don't
*require
Tom Lane [mailto:[EMAIL PROTECTED] Wrote:
John Hansen [EMAIL PROTECTED] writes:
Right,... Let me be more specific then,
What are your thoughts on using the glib
(http://developer.gnome.org/doc/API/2.2/glib/index.html)
library for
some functionality in pg?
Right offhand
Yes,
Thank you! :)
.. John
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 07, 2005 10:07 AM
To: John Hansen
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] unicode upper/lower functions
I think we have decided to use the ICU
-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 07, 2005 10:07 AM
To: John Hansen
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] unicode upper/lower functions
I think we have decided to use the ICU library to implement
multiple locales
Bruce Momjian wrote:
John Hansen wrote:
... Except,.. It was never decided if the 'C' locale
optimisations was
going to be removed if/when implementing ICU.
Uh, why would we remove it? Oh, meaning if the locale is C
we bypass locale lookups? I think we will have to see what
, please let me know, and correct it).
... John
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 05, 2005 11:23 AM
To: pgman@candle.pha.pa.us
Cc: John Hansen; pgsql-hackers@postgresql.org; PostgreSQL-patches
Subject: Re: [PATCHES] Unicode characters
Look at peter eisentraut's procedural language PL/sh
It's on pgfoundry.
... John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Saturday, June 04, 2005 5:16 AM
To: Gevik babakhani
Cc: pgsql-hackers@postgresql.org
Subject: Re:
Ahemm,...
UNICODE DB:
create table t (a char(10));
set client_encoding = iso88591;
insert into t VALUES ('æøå');
select a, octet_length(a),length(a) from t;
a | octet_length | length
+--+
æøå| 13 | 3
(1 row)
This is with 8.0.2.
Ahhh...
-Original Message-
From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 9:26 AM
To: John Hansen
Cc: [EMAIL PROTECTED]; pgsql-patches@postgresql.org;
pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] character type value is not padded with spaces
Tom, Juan,
Wouldn't this simple SQL do the trick?
CREATE OR REPLACE FUNCTION pk_column(text) RETURNS SETOF text
AS '
SELECT attname::text
FROM pg_class, pg_constraint, pg_attribute
WHERE pg_class.oid = conrelid
AND contype=''p''
AND attrelid = pg_class.oid
Personally, I'd like UTF8 to be the default encoding :) This
is the 21st century :D
I concur.
... John
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Tatsuo Ishii wrote:
Sent: Tuesday, May 10, 2005 5:45 PM
To: John Hansen
Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
Tatsuo Ishii wrote:
Sent: Tuesday, May 10, 2005 12:32 AM
To: John Hansen
Cc
Tatsuo Ishii wrote:
Sent: Tuesday, May 10, 2005 12:32 AM
To: John Hansen
Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
-Original Message-
From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
Sent
Tatsuo Ishii
Sent: Sunday, May 08, 2005 3:41 PM
To: John Hansen
Cc: [EMAIL PROTECTED]; pgman@candle.pha.pa.us;
[EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
Alvaro Herrera wrote:
Sent: Sunday, May 08, 2005 2:49 PM
To: John
Tatsuo Ishii wrote:
Sent: Sunday, May 08, 2005 3:31 PM
To: John Hansen
Cc: [EMAIL PROTECTED]; pgsql-general@postgresql.org;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [GENERAL] Invalid unicode in COPY problem
Tatsuo Ishii wrote:
Sent: Sunday, May 08, 2005 12:01 PM
The source for ICU 3.2 is 9.8Mb in .tar.gz. PostgreSQL 8.0.2 is 13.2.
That means the size of the distribution would almost *double*
if we bundled ICU.
Ermm,. Don't forget to remove the current charset conversions and locale
support before making your size estimation.
It's probably fine
Tatsuo Ishii wrote:
Sent: Sunday, May 08, 2005 11:19 PM
To: John Hansen
Cc: [EMAIL PROTECTED]; 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
Tom Lane wrote:
Sent: Monday, May 09, 2005 2:47 AM
To: Palle Girgensohn
Cc: Tatsuo Ishii; John Hansen; [EMAIL PROTECTED];
pgman@candle.pha.pa.us; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
Palle Girgensohn [EMAIL PROTECTED] writes:
I'm confused. I
Tatsuo Ishii wrote:
Sent: Sunday, May 08, 2005 11:08 PM
To: John Hansen
Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
I don't buy it. If current conversion tables does the
right thing,
why we need
-Original Message-
From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 08, 2005 11:08 PM
To: John Hansen
Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
I don't buy it. If current
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]
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
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
that into some common functions and I think it will
be better.
Why do you need to add a mapping of encoding names from
iana to our
names?
This was already answered by John Hansen... There's an old
thread here
about the choice of the name UNICODE to describe an
encoding, which
--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
that we do not have at present.
Any thoughts?
... John
-Original Message-
From: John Hansen
Sent: Saturday, May 07, 2005 11:09 PM
To: 'Palle Girgensohn'; 'Bruce Momjian'
Cc: 'pgsql-hackers@postgresql.org'
Subject: RE: [HACKERS] Patch for collation using ICU
--On lördag, maj 07
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
-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
-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
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
-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
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
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?
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_
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
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
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
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
Why do you need to add a mapping of encoding names from iana
to our names?
The pg encoding names are not recognized by ICU, hence the mappings
Install ICU 3.2 on your system, and run uconv -l, that will give you a
list of valid ICU encoding names.
... John
Btw,
Does it feel right to have pg depend on the bleeding edge version of
ICU?
On many distro's, even gentoo (known for being bleeding edge) 2.8 is
still the default.
2.8 and 3.2 are however incompatible, and supporting both, would bloat
the source somewhat.
... John
Are there any encodings we care about that require embedded zero
bytes?
UTF-8 does!
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Errm.. UTF-16/32
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Hansen
Sent: Wednesday, May 04, 2005 1:22 PM
To: Tom Lane; Tatsuo Ishii
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] A proper fix for the
conversion-function
Use the DirecFunctionCall1, DirecFunctionCall2, etc. functions.
... John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Monday, April 18, 2005 10:40 PM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Call to build-in
Consider the following:
create table foo ( id serial primary key, path text);
alter table foo add ref foo;
Table public.foo
Column | Type | Modifiers
+-+-
id | integer |
On 2005-04-10, Tom Lane tgl ( at ) sss ( dot ) pgh ( dot ) pa ( dot )
us wrote:
Andrew - Supernews andrew+nonews ( at ) supernews ( dot ) com
writes:
I think you will find that this impression is actually false. Or
that at
the very least, _correct_ verification of UTF-8 sequences will still
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
Sent: Sunday, April 10, 2005 8:18 AM
To: Christopher Kings-Lynne
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Unicode problems on IRC
Christopher Kings-Lynne wrote:
--On fredag, mars 25, 2005 16.34.41 +1100 John Hansen
[EMAIL PROTECTED]
wrote:
Useful if it's going to support earlier releases of ICU
Not all os's come with ICU3.2, debian for example,
currently has 2.1
in testing, and 2.6 in unstable.
Oh, OK. FreeBSD has only the 3.2
-Original Message-
From: John Hansen
Sent: Friday, March 25, 2005 10:27 PM
To: 'Palle Girgensohn'; 'pgsql-hackers@postgresql.org'
Subject: RE: [HACKERS] Patch for collation using ICU
--On fredag, mars 25, 2005 16.34.41 +1100 John Hansen
[EMAIL PROTECTED]
wrote:
Useful
--On fredag, mars 25, 2005 23.39.33 +1100 John Hansen
[EMAIL PROTECTED]
wrote:
Ok,.. tested on debian sarge with ICU 3.2 UNICODE Database,
C locale.
upper() and lower() returns an empty string for any input,
including
7bit ascii, regardless of client_encoding, so something
-Original Message-
From: Palle Girgensohn [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 26, 2005 1:10 PM
To: pgsql-hackers@postgresql.org
Cc: John Hansen; Andrew Dunstan
Subject: Re: [HACKERS] Patch for collation using ICU
--On fredag, mars 25, 2005 00.40.04 +0100 Palle
: removing contents of data directory /var/lib/postgres/data
... John
-Original Message-
From: Palle Girgensohn [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 26, 2005 1:10 PM
To: pgsql-hackers@postgresql.org
Cc: John Hansen; Andrew Dunstan
Subject: Re: [HACKERS] Patch for collation
Useful if it's going to support earlier releases of ICU
Not all os's come with ICU3.2, debian for example, currently has 2.1 in
testing, and 2.6 in unstable.
... John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Palle Girgensohn
Sent:
John Hansen wrote:
currently, upper/lower does not work with 2+ byte unicode
characters,
on any OS under the C locale.
Sure it does. It's just that the defined behavior of the C
locale is often useless in practice.
select upper('æøå');
ERROR: invalid multibyte character for locale
select upper('æøå');
ERROR: invalid multibyte character for locale
HINT: The server's LC_CTYPE locale is probably
incompatible with the database encoding.
Consequently it seems that is does not work.
It fails on my machine should not be read as it doesn't
work for anyone.
It
On HPUX 10.20, mbstowcs seems to treat all byte values as
single-byte characters in C locale, so my sample-of-one says
that it works everywhere ;-).
Right, so for the sample SQL I sent earlier, the result would be the same as
the input?
That's hardly a working upper/lower
If a
To fix UTF8, the data needs to be converted to
UTF16 and then
the Win32 wcscoll() can be used, and perhaps other functions
like towupper(). However, UTF8 already works with normal
locales but provides no ordering.
Right,. So if that's fixed, then
K, let me rephrase:
currently, upper/lower does not work with 2+ byte unicode characters, on any OS
under the C locale.
... John
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining
currently, upper/lower does not work with 2+ byte unicode
characters, on any OS under the C locale.
Btw,...
There are only 15 cases in the utf8 repertoire that depends on locale, these
are the only cases where pg should report:
ERROR: invalid multibyte character for locale
HINT: The
... c) would be very bad since it
doesn't give me any chance to release the resources that
where used in order to produce the rows.
You are supposed to free resources used to produce the rows before
srf_return_next();
The actual rows are pfree()'d by pg. (an dso are any other palloc()'d
Just got reminded...
Is there a way for a C function to determine the name of the schema in which is
was created?
... John
---(end of broadcast)---
TIP 8: explain analyze is your friend
Beautiful, just what I was looking for.
Thnx,
John
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 15, 2005 6:31 AM
To: Michael Fuhr
Cc: John Hansen; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Schema name of function
Michael Fuhr
Hi list,
Attached for your perusal, unicode versions of upper/lower, that work
independent of locale except for the following languages:
Turkish, Azeri, and Lithuanian.
There are 15 locale specific cases in total not covered.
--
John Hansen [EMAIL PROTECTED]
GeekNET
collate.tar.gz
could easily
figure out the OID of said tuple and return that if it's present for
PQExec() (for backwards compatibility just as it does today,) and add a
separate PQExecSelect() that instead returns the tuple(s) as if they had
been SELECTed.
--
John Hansen [EMAIL PROTECTED]
GeekNET
#include
unconvinced that it's worth fixing
considering that this whole behavior (SRFs in the targetlist) is
deprecated.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
--
John
uhmm,...
Forgot to change the copyright.
Please accept this under the same terms as postgresql itself.
... John
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister
Since OID's are now deprecated, and will eventually disappear,
wouldn't it be a good idea, to have INSERT and UPDATE
return a copy of
the tuple that was inserted/updated?
How about the TID?
Yea, that'd work. As long as you can get an arbitrary column back out, 'as it
was at the time
No one has stated that they will disappear.
Ohh,... just the impression I've been getting when speaking with people.
... John
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
1 - 100 of 164 matches
Mail list logo
