On Mon, Oct 20, 2003 at 10:58:00PM +0200, Peter Eisentraut wrote:
(Note that I say Unicode a lot here because those people do a lot of
research and standardization in this area, which is available for free,
but this does not constrain the result to work only with the Unicode
character set.)
Karel Zak kirjutas T, 21.10.2003 kell 10:50:
On Mon, Oct 20, 2003 at 10:58:00PM +0200, Peter Eisentraut wrote:
(Note that I say Unicode a lot here because those people do a lot of
research and standardization in this area, which is available for free,
but this does not constrain the
Why cannot do PostgreSQL as 100% pure Unicode system? We can do
conversion from/to others encodings as client/server communication
extension, but internaly in BE we can use only pure Unicode data. I
think a lot of things will more simple...
Please don't do that. There's a
Tatsuo Ishii kirjutas T, 21.10.2003 kell 12:07:
Why cannot do PostgreSQL as 100% pure Unicode system? We can do
conversion from/to others encodings as client/server communication
extension, but internaly in BE we can use only pure Unicode data. I
think a lot of things
Tatsuo Ishii kirjutas T, 21.10.2003 kell 12:07:
Why cannot do PostgreSQL as 100% pure Unicode system? We can do
conversion from/to others encodings as client/server communication
extension, but internaly in BE we can use only pure Unicode data. I
think a lot of
On Tue, 2003-10-21 at 00:08, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
It had occurred to me that we could move support for each version of the
backend into a shared lib.
eg. libpsql70.so, libpsql71.so, etc.
Then all we do is load the appropriate lib and call
Rod Taylor wrote:
I'm sure the pgAdmin group likes that idea (they're probably tired of maintaining 4 different versions of
queries for getting a list of tables). Any solution to make psql backward or forward compatible should go an additional step to assist other frontends as well.
While I
On Tue, 2003-10-21 at 09:03, Andreas Pflug wrote:
Rod Taylor wrote:
I'm sure the pgAdmin group likes that idea (they're probably tired of maintaining
4 different versions of
queries for getting a list of tables). Any solution to make psql backward or
forward compatible should go an
On Tue, 2003-10-21 at 09:33, Andreas Pflug wrote:
Rod Taylor wrote:
Of course, psql has the same issue in hiding functionality that doesn't
exist. My biggest beef is the psql help is often misleading if you're
connected to a different backend.
This would need to be a part of a solution
With Pg 7.3.x we initialize database with -E UNICODE option.
I'd like to provide support for automatic conversion to Chinese char-set
by putting client_encoding big5 into postgresql.conf.
But when I try \encoding big5 in psql session I get this:
big5: invalid encoding name or conversion procedure
Michael Brusser [EMAIL PROTECTED] writes:
I looked into table pg_conversion - it's empty.
We've seen that reported before. IIRC, it is possible to have
dynamic-linking problems with loading the pg_conversion support
libraries, and the 7.3 version of initdb has a bad habit of sending
the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
* Allow INET subnet tests using non-constants
This should say Allow ... to be indexed as it's otherwise a nonissue.
Uh, what should be in the TODO? I am confused.
* Allow INET subnet tests using non-constants to
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Mon, 20 Oct 2003, Bruce Momjian wrote:
I guess my question would be how many people are using information
schemas vs. have loaded databases they don't want to reload.
We are still in beta, not RC ... why is this even an
Hi all,
I hope this is the right mailinglist for my question.
I'm using postgresql 7.2.1 and doing some bulk-loads from one table
to another. Due to sometimes there may exist som already loaded rows the
first thing I do is to delete them to reinsert all of them later on.
This sequence is but into
Hi,
I'm developing a native XML database (C++) (which is supposed to become
open source one day) and I'm wondering wheather I could use GiST for it's
indexes. Is GiST still alive?
Also, I'm looking for a database that I could use for my XML database.
Right now, I'm using a custom IO layer. Right
Bruce Momjian [EMAIL PROTECTED] writes:
We try to limit initdb in late betas --- that has always been our
process. I don't have any problem with the initdb, though.
We now have another reason to, which is Chris K-L's point about
unqualified names in the various SQL-language built-in functions.
Tom Lane writes:
We now have another reason to, which is Chris K-L's point about
unqualified names in the various SQL-language built-in functions.
I am about to commit that fix (with another catversion bump for
good measure...)
Oh dear. We really need this function-specific schema path that
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
We now have another reason to, which is Chris K-L's point about
unqualified names in the various SQL-language built-in functions.
I am about to commit that fix (with another catversion bump for
good measure...)
Oh dear. We really
Why 7.2.4 I wonder? And I don't see anything there in the CVS repository. I know they
are not obliged to show us the source code, but doing so would be nice (especially to
see the threading part).
Hi Andrew,
here you have the source code:
In article [EMAIL PROTECTED], Christopher
Browne [EMAIL PROTECTED] writes
How do you know it works? Without the theory and model, you
really do not.
And don't other databases have both theory and model?
It's just that all the academics have been brainwashed into thinking
this is true
-Original Message-
From: Lauri Pietarinen [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 19, 2003 1:50 PM
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Dreaming About Redesigning SQL
Anthony W. Youngman wrote:
Well, as far as we MV'ers are concerned, performance IS a
Anthony W. Youngman kirjutas P, 19.10.2003 kell 21:24:
As soon as a requirement for a database specifies extraction of the
maximum power from the box, it OUGHT to rule out all the current
relational databases. MV flattens it for it for performance. As an MV
programmer, I *KNOW* that I can
There is always the biggest evil of all... Putting SHOW / DESCRIBE /
HELP commands into the backend itself. I'm sure the pgAdmin group likes
that idea (they're probably tired of maintaining 4 different versions of
queries for getting a list of tables). Any solution to make psql
backward or forward
There is always the biggest evil of all... Putting SHOW / DESCRIBE /
HELP commands into the backend itself. I'm sure the pgAdmin group likes
that idea (they're probably tired of maintaining 4 different versions of
queries for getting a list of tables). Any solution to make psql
backward or
We now have another reason to, which is Chris K-L's point about
unqualified names in the various SQL-language built-in functions.
I am about to commit that fix (with another catversion bump for
good measure...)
Oh dear. We really need this function-specific schema path that the SQL
standard
Hi,
Now that DEFAULT 'now' will not work in PostgreSQL 7.4, will DEFAULT
'infinity' and DEFAULT '-infinity' and the like stop working as well?
What is the workaround for those defaults?
Chris
---(end of broadcast)---
TIP 8: explain analyze is
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Now that DEFAULT 'now' will not work in PostgreSQL 7.4, will DEFAULT
'infinity' and DEFAULT '-infinity' and the like stop working as well?
No, because those values don't change over time. The issue here is when
exactly does the default value
Now that DEFAULT 'now' will not work in PostgreSQL 7.4, will DEFAULT
'infinity' and DEFAULT '-infinity' and the like stop working as well?
No, because those values don't change over time. The issue here is when
exactly does the default value get evaluated...
Ah, of course - but what about
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Now that DEFAULT 'now' will not work in PostgreSQL 7.4, will DEFAULT
'infinity' and DEFAULT '-infinity' and the like stop working as well?
No, because those values don't change over time. The issue here is when
exactly does the default
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Now that DEFAULT 'now' will not work in PostgreSQL 7.4, will DEFAULT
'infinity' and DEFAULT '-infinity' and the like stop working as well?
No, because those values don't change over time. The issue here is when
It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.
Personally, I think that's a fairly silly policy! How does it hurt us
to mention it and you just know that someone, somewhere,
On Wed, 2003-10-22 at 00:41, Christopher Kings-Lynne wrote:
It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.
Personally, I think that's a fairly silly policy!
I agree --
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Ah, of course - but what about 'yesterday' and 'tomorrow' - these should
also be mentioned in the release notes.
Good point ... not that I think anyone is actually using such a default
A moment's further thought reveals 'today' as another potentially broken
default value, which seems more likely to be used in practice than
'yesterday' or 'tomorrow'. I'm too beat to go digging for other legal
inputs, but there may be some...
Ah, I didn't mention that one because I thought it
Christopher Kings-Lynne wrote:
It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.
Personally, I think that's a fairly silly policy! How does it hurt us
to mention it
Neil Conway wrote:
On Wed, 2003-10-22 at 00:41, Christopher Kings-Lynne wrote:
It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.
Personally, I think that's a fairly
Christopher Kings-Lynne writes:
Oh dear. We really need this function-specific schema path that the SQL
standard seems to talk about.
What's that? How would it help?
The idea is that you give each function its own schema search path at
creation time, and that path applies to that
37 matches
Mail list logo
