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=# s
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 broadcast)---
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 broadcast)-
'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
C
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 upgra
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 o
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 OFF
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
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 ne
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 res
'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=# move
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;
> BEG
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
-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 and -announce
> on this later this evening, but if someo
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 -g
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 f
Wol,
> I think one MAJOR problem is that most (if not all) MV practitioners are
> not formally qualified in computing ...
> "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 bes
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 tha
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_
>
> O
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 abou
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
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). D
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 to
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.
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 jo
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.
>
> Rig
> "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'r
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 it
[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 require
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 wel
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.
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
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 data
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 hen
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
> o
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, sam
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 compatibi
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
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 proce
46 matches
Mail list logo
