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 a
What does this in the date/time type docs mean?
zulu, allballs, z time 00:00:00.00 UTC
Cos it has bizarro behaviour:
In 7.3.4:
australia=# select 'zulu'::time;
ERROR: Bad time external representation 'zulu'
australia=# select 'allballs'::time;
time
--
00:00:00
(1 row)
australia=#
Hi guys,
What is the limit on the number of rows in a PostgreSQL table? If it's
more than MAXINT, we have a problem:
phppgadmin# select * from test limit 2147483648;
ERROR: integer out of range
Same problem with OFFSET.
Chris
---(end of
Christopher Kings-Lynne writes:
What in the heck is 'zulu', 'allballs' or 'z'???
'allballs' probably alludes to the visual appearance of '00:00:00'. 'z'
and 'zulu' should be time zones equivalent (or similar?) to UTC or GMT
((US?) military jargon).
--
Peter Eisentraut [EMAIL PROTECTED]
What in the heck is 'zulu', 'allballs' or 'z'???
'allballs' probably alludes to the visual appearance of '00:00:00'. 'z'
and 'zulu' should be time zones equivalent (or similar?) to UTC or GMT
((US?) military jargon).
But they don't work...
Chris
---(end of
'allballs' probably alludes to the visual appearance of '00:00:00'. 'z'
and 'zulu' should be time zones equivalent (or similar?) to UTC or GMT
((US?) military jargon).
Why do we support just 'zulu' and none of the other magic time zone names:
http://wwp.greenwichmeantime.com/info/timezone.htm
On Wednesday 22 October 2003 07:37, Neil Conway wrote:
The second audience is the people who are really interested in exactly
what has changed between the new release of PostgreSQL and the previous
release series. It is important that we make it easy for an admin
planning a PostgreSQL upgrade
On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
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
On Wed, 2003-10-22 at 04:01, Christopher Kings-Lynne wrote:
Hi guys,
What is the limit on the number of rows in a PostgreSQL table? If it's
more than MAXINT, we have a problem:
phppgadmin# select * from test limit 2147483648;
ERROR: integer out of range
Same problem with OFFSET.
I
Richard Huxton [EMAIL PROTECTED] writes:
On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
The idea is that you give each function its own schema search path at
creation time, and that path applies to that function for the rest of its
life. Then that function would be immune to
Rod Taylor [EMAIL PROTECTED] writes:
That said, perhaps the TODO for changing LIMIT / OFFSET to be expression
based should also mention bumping them to int8.
Can't get excited about it ... this would slow down the normal use of
the facility for what seems a completely hypothetical need.
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Why do we support just 'zulu' and none of the other magic time zone names:
http://wwp.greenwichmeantime.com/info/timezone.htm
AFAIK, zulu is the only one of those military designations that has
any currency at all. I don't feel a strong need to
On Wed, 2003-10-22 at 09:28, Tom Lane wrote:
Richard Huxton [EMAIL PROTECTED] writes:
On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
The idea is that you give each function its own schema search path at
creation time, and that path applies to that function for the rest of its
'K, I packaged it up last night so that the ftp mirrors could get up to
date on it ... I'm going to put out an announce to -general and -announce
on this later this evening, but if someone wants to take a quick scan of
the tar ball to make sure that it all looks okay to them, that would be
great
I see you're point, but nobody is going to be interested in the first 2
billion rows of a table without using a cursor and having some other
process do the math in the background.
You have the same problem:
test=# begin;
BEGIN
test=# declare c cursor for select * from a;
DECLARE CURSOR
test=#
On Wed, 22 Oct 2003, Christopher Kings-Lynne wrote:
I see you're point, but nobody is going to be interested in the first 2
billion rows of a table without using a cursor and having some other
process do the math in the background.
You have the same problem:
test=# begin;
BEGIN
test=#
On Wed, 2003-10-22 at 10:22, Christopher Kings-Lynne wrote:
I see you're point, but nobody is going to be interested in the first 2
billion rows of a table without using a cursor and having some other
process do the math in the background.
You have the same problem:
test=# move
On Wed, 2003-10-22 at 11:43, Andreas Joseph Krogh wrote:
So, is an initdb from beta4 required or not?
Yes, it is. This should probably be mentioned in the announcement when
it is sent out.
-Neil
---(end of broadcast)---
TIP 5: Have you checked
On Wed, 22 Oct 2003, Andreas Joseph Krogh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 22 October 2003 16:21, Marc G. Fournier wrote:
'K, I packaged it up last night so that the ftp mirrors could get up to
date on it ... I'm going to put out an announce to -general
On Wed, 22 Oct 2003, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
That said, perhaps the TODO for changing LIMIT / OFFSET to be expression
based should also mention bumping them to int8.
Can't get excited about it ... this would slow down the normal use of
the facility for what
Wol,
I think one MAJOR problem is that most (if not all) MV practitioners are
not formally qualified in computing ...
snip
Relational is all about theory and proving things mathematically
correct. MV is all about engineering and getting the result. And if
that means pinching all the best
Tom Lane wrote:
Richard Huxton [EMAIL PROTECTED] writes:
On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
The idea is that you give each function its own schema search path at
creation time, and that path applies to that function for the rest of its
life. Then that function
Neil Conway wrote:
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
On Wed, 2003-10-22 at 12:08, scott.marlowe wrote:
On Wed, 22 Oct 2003, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
That said, perhaps the TODO for changing LIMIT / OFFSET to be expression
based should also mention bumping them to int8.
Can't get excited about it ... this
Bruce Momjian [EMAIL PROTECTED] writes:
As far as incrementally updating the release notes --- lots of our work
is incremental, meaning we fix X, then add Y, and Z, and the resulting
change is one release note entry (psql \d display improvements, for
example). Documenting them separately just
Rod Taylor [EMAIL PROTECTED] writes:
A cursor pulling small chunks of a multi-billion tuple set is probably
much more common, so we should ensure those work.
This should work ... but I haven't personally had the patience to test
it ...
regards, tom lane
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
As far as incrementally updating the release notes --- lots of our work
is incremental, meaning we fix X, then add Y, and Z, and the resulting
change is one release note entry (psql \d display improvements, for
example). Documenting
We integrate PostgreSQL with our product, which we ship to the end user.
We do read the release notes, they are important to us.
They don't have to be excruciatingly long, they can't be
ridiculously short and cryptic.
You have to find the golden spot in the middle. Just treat us
the way you want
Michael Brusser wrote:
We integrate PostgreSQL with our product, which we ship to the end user.
We do read the release notes, they are important to us.
They don't have to be excruciatingly long, they can't be
ridiculously short and cryptic.
You have to find the golden spot in the middle. Just
On Wed, 2003-10-22 at 13:26, Tom Lane wrote:
We do already have a practice of adding notes about significant changes
to release.sgml as they are made. That's relatively new though, and I
dunno if it's helped Bruce prepare the finished release notes or not.
Right, we also did a pretty bad job
Neil Conway wrote:
On Wed, 2003-10-22 at 13:26, Tom Lane wrote:
We do already have a practice of adding notes about significant changes
to release.sgml as they are made. That's relatively new though, and I
dunno if it's helped Bruce prepare the finished release notes or not.
Right, we
Josh == Josh Berkus [EMAIL PROTECTED] writes:
Relational is all about theory and proving things
mathematically correct. MV is all about engineering and
getting the result. And if that means pinching all the best
ideas we can find from relational, then we're engineers - of
On Wed, 22 Oct 2003, scott.marlowe wrote:
That said, perhaps the TODO for changing LIMIT / OFFSET to be expression
based should also mention bumping them to int8.
Can't get excited about it ... this would slow down the normal use of
the facility for what seems a completely
Gregor,
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?
Don't know, sorry.
Would PostgreSQL fit that requirement? And are you interested in having a
fast,
On Wed, 22 Oct 2003, Tom Lane wrote:
Richard Huxton [EMAIL PROTECTED] writes:
On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
The idea is that you give each function its own schema search path at
creation time, and that path applies to that function for the rest of its
life.
[EMAIL PROTECTED] (Josh Berkus) writes:
Gregor,
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?
Don't know, sorry.
Would PostgreSQL fit that requirement? And
Christopher Browne wrote:
But I think back to the XML generator I wrote for GnuCash; it has the
notion of building up a hierarchy of entities and attributes, each of
which is visible as an identifyable object of some sort. Mapping that
onto a set of PostgreSQL relations wouldn't work terribly
On Wed, 22 Oct 2003, Christopher Browne wrote:
It leaves open the question of what is the appropriate way of
expressing XML entities and attributes and CDATA in database form.
snip
Thanx for your advise, but that's not what I had in mind. The original
idea to have a native xml database was that
On Wed, 22 Oct 2003, Andrew Dunstan wrote:
But why put yourself to such bother? I have never found a good reason to
do this sort of thing.
I think there is a huge potential for XML databases once there are good
ones and people start using them more extensively.
But for having real fast xml
Do this:
1. Create a new type called 'xml', based on text.
2. The xmlin function for that type will validate what you are
enterering is XML
3. Create new functions to implement XPath, SAX, etc. on the xml type.
4. Extend the contrib/ltree gist-based tree indexing scheme to work on
xml and
In the last exciting episode, [EMAIL PROTECTED] (Gregor Zeitlinger) wrote:
On Wed, 22 Oct 2003, Andrew Dunstan wrote:
But why put yourself to such bother? I have never found a good reason to
do this sort of thing.
I think there is a huge potential for XML databases once there are good
ones
Is it worth mentioning this as a compatibility issue?
Prior to PostgreSQL 7.3, serial implied UNIQUE. This is no longer
automatic. If you wish a serial column to be in a unique constraint or a
primary key, it must now be specified, same as with any other data type.
Chris
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is it worth mentioning this as a compatibility issue?
Prior to PostgreSQL 7.3, serial implied UNIQUE. This is no longer
automatic. If you wish a serial column to be in a unique constraint or a
primary key, it must now be specified, same as
Is it worth mentioning this as a compatibility issue?
Prior to PostgreSQL 7.3, serial implied UNIQUE. This is no longer
automatic. If you wish a serial column to be in a unique constraint or a
primary key, it must now be specified, same as with any other data type.
Er, that *was* a
Christopher Kings-Lynne wrote:
Is it worth mentioning this as a compatibility issue?
Prior to PostgreSQL 7.3, serial implied UNIQUE. This is no longer
automatic. If you wish a serial column to be in a unique constraint or a
primary key, it must now be specified, same as with any other data
Gregor,
Thanx for your advise, but that's not what I had in mind. The original
idea to have a native xml database was that I doesn't work too well in a
relational database.
I was just wondering wheater I have to reinvent the wheel of database
technology when it comes to transaction
46 matches
Mail list logo
