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
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
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".
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
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)
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 sett
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:
> > > 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-insensiti
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?
http://www.postgres
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
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 posting/readi
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
se
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 ~ operat
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: pgsql-hac
> 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 broadcast)
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 smal
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 consi
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 ro
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
>
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:
> &g
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 ('1:2:3:4
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 datab
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: "
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)
>
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 loc
> 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
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
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.or
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
>
>
&g
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
messag
Tom Lane [mailto:[EMAIL PROTECTED] wrote:
> "John Hansen" <[EMAIL PROTECTED]> writes:
> > Given the following snippet:
> > HeapTupleHeader tuple;
> > Datum temp;
> > bool isnull;
>
> >
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 func
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 looku
ginal 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 lib
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 t
, 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:
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
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 val
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.
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
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: T
> -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
&g
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 conversio
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 PROT
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
> 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 fin
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:
> > > Se
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:
> > > S
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 +10
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
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
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:
> > >
> > > T
> 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
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 f
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
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 buil
> 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
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
> -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
>
>
> 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
> -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örda
> -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örda
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
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]
> --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
idn't work. That excessive status
> checking is
> > hardly be necessary once the stuff is better tested.
> >
> > I think the string copying and heap/palloc choices stands
> for most of
> > the code bloat, together with the excessive status checking
> and logging.
>
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
>
>
> 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
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
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
-
> 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
-
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
> 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
1 AM
> To: John Hansen
> Cc: Bruce Momjian; Tatsuo Ishii; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
>
> "John Hansen" <[EMAIL PROTECTED]> writes:
> > Look at t
PM
> To: John Hansen
> Cc: Tatsuo Ishii; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
>
> John Hansen wrote:
> > Look at the upper/lower I sent to the list, the
Look at the upper/lower I sent to the list, they should be able to
replace upper/lower for the utf8 encoding (and works independent of
locale)..
... John
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> Sent: Sunday, April 24, 20
> I appreciate getting corrected by people I know in a limited
> forum. I would not expect it when I do a mistakes here. Can't
> say it ever has happend although there's often good grounds
> for it so I have nothing to complain about. :-)
I think you meant to say 'I Can't say it ever has happen
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
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 wrote:
>> Andrew - Supernews
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
>>> catch essentially all cases of non-utf-8 input mislabelled as utf-8
>>> while all
> -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 wro
with exit code 139
initdb: 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;
> -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
> --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
> &g
> -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 Jo
> --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
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:
> 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 charac
> > 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
> 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('æøå&#
> 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 serv
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 colu
> 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
> ... 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
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] Schem
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
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 YourEmailAddressH
regards, tom lane
>
> ---(end of broadcast)---
> TIP 7: don't forget to increase your free space map settings
--
John Hansen <[EMAIL PROTECTED]>
GeekNET
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
1 - 100 of 170 matches
Mail list logo
