On Wed, 2003-10-22 at 01:08, Bruce Momjian wrote:
> Do you think I include every user-visible change in the release notes?
> It would be 2-3x longer, and probably not more useful.
> Part of the reason the release notes are read is
> because they are _readable_
On the contrary, I think we could do
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 fu
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 tha
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 men
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 wa
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 usin
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 a
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, i
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
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 t
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 'y
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 va
On Tue, 2003-10-21 at 21:24, Christopher Kings-Lynne wrote:
> > 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 f
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 yo
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 seem
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 forward
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 c
> -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
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 thinkin
>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:
http://forge.novell.com/modules/xfmod/project/showfi
Anthony W. Youngman wrote:
Well, as far as we MV'ers are concerned, performance IS a problem with
the relational approach. The attitude (as far as I can tell) with
relational is to hide the actual DB implementation from the programmers.
So it is a design "flaw" that it is extremely easy for a prog
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.
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 t
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 functio
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
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 thi
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 us
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 resul
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
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut - PostgreSQL wrote:
> >> Cleanup on --help-config: Now called --describe-config, no further options,
> >> machine readable, without headers, not sorted.
>
> > Don't we need to document this? I don't see any SGML comm
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 proced
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 o
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 if we're going to get
anything out of it.
No problem, let'
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 g
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 can
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
> 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
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
> 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'
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 th
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.
42 matches
Mail list logo
