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
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
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 <[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."
Chris
---
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
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
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
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
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
[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
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
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, 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
> "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
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
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
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.
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
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
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
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
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
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
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
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
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
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, 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
-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 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, 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
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
'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 .
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
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
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.
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
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
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 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
'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
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)-
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]
-
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)---
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
46 matches
Mail list logo