Help with pl/pgsql, triggers, and foreign keys

At 11:22 PM 1/28/00 -0500, Roland Roberts wrote:

-----BEGIN PGP SIGNED MESSAGE-----

The Postgres guide says that foreign keys can be partially emulated
via triggers. Just how "partial" is this. I can't seem to get the
following to work. Would it work if I wrote it in C? Would I need to
open a second connection to the database? Would it work if my second
key was really in another table?

Given that foreign keys are implemented in the current sources and
coming out for real in v7.0 beta in two weeks, how much effort do
you really want to put into emulation???

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Jan 29 01:02:13 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA66588
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 01:01:49 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id RAA31815;
Sat, 29 Jan 2000 17:00:02 +1100
Message-Id: <3.0.5.32.20000129170141.00cf5e40@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 29 Jan 2000 17:01:41 +1100
To: Bruce Momjian <pgman@candle.pha.pa.us>
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Copyright
Cc: The Hermit Hacker <scrappy@hub.org>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <200001290542.AAA09066@candle.pha.pa.us>
References: <3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 00:42 29/01/00 -0500, Bruce Momjian wrote:

What matters is that it remains open, free, and modifiable by anyone, for
any purpose.

This does bring up the larger question of what happened to the original
copyrights? Is this covered in Bruce's upcoming book?

...etc...

This all started because I asked about copyright issues around Christmas
(as someone reminded me), and we agreed to copyright the code via
PostgreSQL Inc. Now that we have done that, it seems we may have a
little more to do.

It's probably a little more than just putting the notices in the code. In
Australia, copyright rests with the writer unless it is explicitly granted
in writing to another entity by the author, or unless a singed contract of
service exists which grants copyright of works performed directly in the
course of performing those service.

If the US & Canada are similar, the upshot of this is that you'll need to
get the contributors (and Berkely) to sign their copyrights over to
PosgreSQL, Inc, before you can lawfully place those copyright notices in
the code. I would *guess* that there would be some resistance to this.

It's a hell of a lot simpler to leave the copyright with the authors, who
then grant usage under a GPL/LGPL or whatever. Or, set up an arms-length
entity designed to promote free distribution of PostgreSQL that authorsd
may feel happy about assigning their copyrights to.

Again, just my 0.02c, but copyright is a very thorny issue designed to
protect authors - it's a pity to take that away from them. I am very happy
that the copyright of the code I have contributed to, eg, the GD graphics
library remains with me, but that it can be freely used & distributed in
GD. I would not want to sign my rights to that code away, then be told by
the person that buys GD from Tom Boutell that I am no longer permitted to
use the code I wrote.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

From bouncefilter Sat Jan 29 01:18:13 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA72323
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 01:18:05 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id WAA13266;
Fri, 28 Jan 2000 22:16:42 -0800 (PST)
Message-Id: <3.0.1.32.20000128221438.00ed25b0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 28 Jan 2000 22:14:38 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>, Philip Warner <pjw@rhyme.com.au>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Copyright
Cc: The Hermit Hacker <scrappy@hub.org>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <200001290542.AAA09066@candle.pha.pa.us>
References: <3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:42 AM 1/29/00 -0500, Bruce Momjian wrote:

In fact, there can be an argument that we were never open since 1996
because we didn't have any copyright covering years after 1996, and
there is an implied copyright to all works, even if not stated.

Licenses compliment copyright, pure and simple. In other words, as
a photographer (http://donb.photo.net) I defend my copyright, yet
I give permission (license) students and a wide variety of other
people to make free use of my work. Yet I still charge other
entities for this right.

When I license my work for use, I in no way diminish my copyright.
This is true even if I release it into the public domain, i.e. if
my license says "you can use this for whatever you want!". I still
don't waive my copyright (though I've shot my foot in terms of
getting damages for use, because if you say folks can use your
photos for free you can't expect to get paid when they accept your
license terms for free use!)

License...copyright...not the same.

Now, I don't mean to suggest that this was intended, but the more I
think about it, the more I wonder. We have never enforced the
copyright, so there may be no legal basis for it, but I believe there is
some muddy water here.

Last time I looked (which I admit was like 15 years ago) enforcement of
copyright wasn't actually an issue. What's an issue is getting
compensation for unapproved use. This is where a registered copyright
comes in (you can collect punitive as well as actual damages and the
standard of proof of ownership is far, far lower where you've registered
the copyrighted entity - if you don't register, you can only collect
actual damages. Since punitive damages can be 3x actual in the US,
you can see why lawyers are more interested in taking a case regarding
a registered copyright on contingency than one regarding an unregistered
copyright - plus the standard of proof of ownership is less).

Of course, it's hard to prove damages or even 3x punitive damages
when you GIVE YOUR STUFF AWAY FOR FREE! :)

So...you probably haven't given up any rights to sue someone for
"using my stuff without permission that I give away for free" but
your compensation for these extra copies that would be free anyway?

Not enough to cover your legal costs...

The above ignores licensing, the PG license makes it clear we don't
have to ask permission to use this stuff. In essence, the PG
license is stating that the copyright holders and otherwise code
owners are granting lots and lots of freedom to the recipient.

You can't legally win saying "I gave it away for free with no
restriction, but I still own the copyright and have changed my
mind, and now these folks have to pay!".

[you could for FUTURE distribution, but not past]

Despite all the above, things get cloudly when (say) the PG
core gets together in Fiji for a big bash and coding party
and a Tsunami wipes everyone out at once and PG, Inc is left
without owners, only heirs of owners...

Worth worrying about? I don't think so...as long as the latest
release was still out there with the current license, other
folks around the world could pick it up and any greedy PG, Inc
heirs would be left without a leg to stand on.

Not because of copyright, because of the license agreement under
which we are granted the use of the copyrighed material.

This all started because I asked about copyright issues around Christmas
(as someone reminded me), and we agreed to copyright the code via
PostgreSQL Inc. Now that we have done that, it seems we may have a
little more to do.

Well...you can't just copyright someone's work without their permission.
When (say, Peter) makes a contribution you can't just say "OK, now it
is copyright PG, Inc" if Peter didn't agree to this arrangement. Because
he has copyright in his code. Of course, his code isn't worth much without
the rest of the 250,000 lines of PG but that's not the point.

I think the idea of looking at the Apache Foundation's sound, because
it is possible they've looked more deeply into this and have found
solutions.

I suspect that everyone here has the same general impression of what is
wanted, but getting the *bleeping* legal structure organized to recognize
it is difficult especially given the inheritance issue (with the original
UC license).

Face it, the legal framework in the US isn't really set up to cater
to those who work hard and give their work freely to others...PG, Inc
etc needs to be creative.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Jan 29 01:36:13 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA77582
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 01:35:24 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id WAA17607;
Fri, 28 Jan 2000 22:34:52 -0800 (PST)
Message-Id: <3.0.1.32.20000128222128.00ed0b70@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 28 Jan 2000 22:21:28 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, bruc@acm.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Copyright
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <13638.949125136@sss.pgh.pa.us>
References: <200001290245.VAA15243@stone.congenomics.com>
<200001290245.VAA15243@stone.congenomics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:52 AM 1/29/00 -0500, Tom Lane wrote:

As long as those terms don't change, adding PostgreSQL Inc (or
PostgreSQL Nonprofit Copyright Holding Corporation, or anything else)
to the copyright notices doesn't really change anything, except for
adding one more line to the boilerplate notice that people aren't
supposed to strip out of their copies.

I think this is the concern (not mine, raised by others) - what
guarantee is there that PG, Inc couldn't change the terms if
(say) a new disease cropped up that killed all believers in Open
Source? :) (yes intentionally silly).

In reality, only CHANGES could fall under more restrictive licensing,
but these changes might become intertwined in a way that made the
original distribution terms moot.

This could be really simple to fix in legal terms. With a not
for profit, distribution and development of a free and unencumbered
system could probably be incorporated into the bylaws and this may
be why the Apache Foundation was formed. It's harder with companies,
which by definition are formed to be profitable and indeed in the
eyes of the IRS are supposed to strive for that goal (though there
is no need to succeed).

So...maybe "Inc" isn't the right long-term shape of the entity?

Personally, I don't think anyone should be terribly concerned about
this. But I can see how some, especially folks who aren't US
citizens and perhaps don't know much about the realities of all this
in US law, could become concerned.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Jan 29 01:25:15 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA73065
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 01:24:14 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id RAA32017;
Sat, 29 Jan 2000 17:22:42 +1100
Message-Id: <3.0.5.32.20000129172421.00cf1e60@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 29 Jan 2000 17:24:21 +1100
To: Tom Lane <tgl@sss.pgh.pa.us>, bruc@acm.org
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Re: Copyright
Cc: pgsql-hackers@postgresql.org
In-Reply-To: <13638.949125136@sss.pgh.pa.us>
References: <200001290245.VAA15243@stone.congenomics.com>
<200001290245.VAA15243@stone.congenomics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 00:52 29/01/00 -0500, Tom Lane wrote:

bruc@stone.congenomics.com (Robert E. Bruccoleri) writes:

However, the real issue with PostgreSQL is not the copyright, but
rather the permissions granted to everyone. As long as all the
contributors are happy with the permission notice, then all is OK.

I think that's an excellent point that bears underlining. All the
original code bore a UC Berkeley copyright --- but that didn't make
anyone unhappy, or stop any of us from doing what we wanted to do
with the code, because Berkeley's license terms are loose enough
not to pose any problems.

The license terms are not going to change. Someone suggested switching
to GPL or LGPL terms, but we cannot do that without (a) violating the
Berkeley terms, which we are still bound by, and (b) losing many
contributors who work in commercial settings and would not find a
GPL'd database usable for their purposes. (Berkeley terms are not
a problem for someone who wants to use code as a component of a
larger proprietary system --- but GPL terms are.)

LGPL allows some commercial use, but I agree, they are both inappropriate
agreements, especially if you want to allow people to write a commercial DB
based on PostgreSQL, which is a very good thing to allow.

When you refer to the license terms, do you mean the 'COPYRIGHT' file in
the root directory, or is there something more?

As long as those terms don't change, adding PostgreSQL Inc (or
PostgreSQL Nonprofit Copyright Holding Corporation, or anything else)
to the copyright notices doesn't really change anything, except for
adding one more line to the boilerplate notice that people aren't
supposed to strip out of their copies. PostgreSQL Inc can't sell the
rights to Postgres, because it hasn't got any rights that anyone else
hasn't got.

Now I'm confused. I thought there was a notice stating that PostgreSQL, Inc
had copy right? If that is the case, then they *can* sell it, and the buyer
could revise the license terms. This is a sort of inverse-Unisys trick:

1. Start with a free open source product
2. Shift the copyright of new code to yourself. The old code remains as it
was.
3. Sponsor and encourage some very nice changes to optimizers, OO support
and RI (naturally shifting copyright of the new stuff your organization)
4. When it's all stable, get taken over by someone who enforces the
copyright on the recent changes, and prevents further distribution.
5. Open source PosgreSQL development falls back to 3 year old sources, with
possible further copyright arguments.

I agree that this is *very* unlikely, but if such a scenario can be
prevented by some simple changes (like a non-prfit organization that has a
clear charter), then it may be worth doing.

*Anyone* could take the code and start developing it
independently, just as the current set of developers did with Berkeley's
code. And if PostgreSQL Inc did something that any significant number
of developers were unhappy with, that's exactly what those developers
would do.

So, while I don't have anything against forming a nonprofit organization
to hold the copyright on behalf of the development team, I really doubt
that it makes any difference. The thing to keep your eye on and guard
jealously is the license/terms-of-distribution. If anyone proposes
mucking with those, THAT is the time to start hollering.

As I said above, I'd like to know where they are, if you mean something
more than the COPYRIGHT file. The big advantage of a separate entity is
that it has a clear charter and no conflict of interest. Disadvantage is
that, I presume, it costs $$$.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

From bouncefilter Sat Jan 29 01:36:14 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA77751
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 01:35:43 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id WAA17632;
Fri, 28 Jan 2000 22:34:57 -0800 (PST)
Message-Id: <3.0.1.32.20000128223248.00ed3e10@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 28 Jan 2000 22:32:48 -0800
To: Philip Warner <pjw@rhyme.com.au>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Copyright
Cc: The Hermit Hacker <scrappy@hub.org>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <3.0.5.32.20000129170141.00cf5e40@mail.rhyme.com.au>
References: <200001290542.AAA09066@candle.pha.pa.us>
<3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 05:01 PM 1/29/00 +1100, Philip Warner wrote:

It's probably a little more than just putting the notices in the code. In
Australia, copyright rests with the writer unless it is explicitly granted
in writing to another entity by the author, or unless a singed contract of
service exists which grants copyright of works performed directly in the
course of performing those service.

This could probably be argued here, too, though the weight of oral
and implied conditions weigh heavily here. It would be hard for a
significant contributor, who by definition would spend a lot of
time working with the code and being social with "the group", to claim
they were unaware that their code would be distributed.

And what would be the remedy? The code contribution's worthless without
the database. If there's a novel or patentable idea in the code snippet
you could still patent it and be nice and grant the PG distribution the
right to use it royalty free. How does modern (screwed-up, IMO) software
patenting possibilities impact possible contributions, oh my, another
can of worms!

Anyway, anyone who contributes code to the repository is doing so with
the intent of its being distributed. I don't think good lawyers would
have much trouble with defending that part of the arrangement.

If the US & Canada are similar, the upshot of this is that you'll need to
get the contributors (and Berkely) to sign their copyrights over to
PosgreSQL, Inc, before you can lawfully place those copyright notices in
the code. I would *guess* that there would be some resistance to this.

So, what, you sign every "XXX" comment with a copyright?

I don't think so.

Things are muddied by the fact that there's no legal relationship between
PG, Inc and the individuals (as opposed to your working and being paid
by a company, which sets up a relationship with implicit rules).

It's a hell of a lot simpler to leave the copyright with the authors, who
then grant usage under a GPL/LGPL or whatever. Or, set up an arms-length
entity designed to promote free distribution of PostgreSQL that authorsd
may feel happy about assigning their copyrights to.

Which again is probably like the Apache Foundation or whatever it is
called.

Again, just my 0.02c, but copyright is a very thorny issue designed to
protect authors - it's a pity to take that away from them.

Do you have newspapers in Australia? I seem to recall you do from my
one visit there :)

Do these newspapers have a "letters to the editor" column? If so, do
the newspapers make each and every contributor sign over their rights
before publishing such letters?

I know in the US they don't.

There's an explicit permission to publish when you mail in your letter
to the editor. If you were to sue, the court would have a couple of
questions:

1. Did you send your letter in so it WOULDN'T be published? When you
read the little blurb in the paper that said "write your opinion
letters for consideration of publishment to xyz box" that they
would never publish it?

and importantly:

2. What was the financial harm done you by their publishing it.

(non-registered copyrights are strictly a civil affair here)

I am very happy
that the copyright of the code I have contributed to, eg, the GD graphics
library remains with me, but that it can be freely used & distributed in
GD. I would not want to sign my rights to that code away, then be told by
the person that buys GD from Tom Boutell that I am no longer permitted to
use the code I wrote.

Yes, of course.

The legend, though, says "portions copyright 1996-2000 by PG, Inc."

It doesn't identify which portions. Nor does the original statement
by UC. The reality is that no one could necessarily claim that any
contribution you make is part of the "portions".

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Jan 29 01:52:14 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA80728
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 01:51:52 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id RAA32255;
Sat, 29 Jan 2000 17:49:08 +1100
Message-Id: <3.0.5.32.20000129175046.009cca30@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 29 Jan 2000 17:50:46 +1100
To: Don Baccus <dhogaza@pacifier.com>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Copyright
Cc: The Hermit Hacker <scrappy@hub.org>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <3.0.1.32.20000128223248.00ed3e10@mail.pacifier.com>
References: <3.0.5.32.20000129170141.00cf5e40@mail.rhyme.com.au>
<200001290542.AAA09066@candle.pha.pa.us>
<3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 22:32 28/01/00 -0800, Don Baccus wrote:

At 05:01 PM 1/29/00 +1100, Philip Warner wrote:

It's probably a little more than just putting the notices in the code. In
Australia, copyright rests with the writer unless it is explicitly granted
in writing to another entity by the author, or unless a singed contract of
service exists which grants copyright of works performed directly in the
course of performing those service.

This could probably be argued here, too, though the weight of oral
and implied conditions weigh heavily here. It would be hard for a
significant contributor, who by definition would spend a lot of
time working with the code and being social with "the group", to claim
they were unaware that their code would be distributed.

And what would be the remedy? The code contribution's worthless without
the database. If there's a novel or patentable idea in the code snippet
you could still patent it and be nice and grant the PG distribution the
right to use it royalty free. How does modern (screwed-up, IMO) software
patenting possibilities impact possible contributions, oh my, another
can of worms!

Anyway, anyone who contributes code to the repository is doing so with
the intent of its being distributed. I don't think good lawyers would
have much trouble with defending that part of the arrangement.

As you say, there is an implied license to distribute. Similarly, if they
remove theire code, there is an implied revocation of the license. As you
said earlier, this is nothing to do with copyright. Copyright is the thing
that gives you the ability to write your own license.

If the US & Canada are similar, the upshot of this is that you'll need to
get the contributors (and Berkely) to sign their copyrights over to
PosgreSQL, Inc, before you can lawfully place those copyright notices in
the code. I would *guess* that there would be some resistance to this.

So, what, you sign every "XXX" comment with a copyright?

I don't think so.

Well, somone told me that the GNU developers have to do just that - they
sign a piece of paper up front waiving copyright. I've only heard this from
one source, though.

Things are muddied by the fact that there's no legal relationship between
PG, Inc and the individuals (as opposed to your working and being paid
by a company, which sets up a relationship with implicit rules).

It's a hell of a lot simpler to leave the copyright with the authors, who
then grant usage under a GPL/LGPL or whatever. Or, set up an arms-length
entity designed to promote free distribution of PostgreSQL that authorsd
may feel happy about assigning their copyrights to.

Which again is probably like the Apache Foundation or whatever it is
called.

Yes, I assume so. I hope they get back to me...

Again, just my 0.02c, but copyright is a very thorny issue designed to
protect authors - it's a pity to take that away from them.

Do you have newspapers in Australia? I seem to recall you do from my
one visit there :)

Do these newspapers have a "letters to the editor" column? If so, do
the newspapers make each and every contributor sign over their rights
before publishing such letters?

I know in the US they don't.

There's an explicit permission to publish when you mail in your letter
to the editor. If you were to sue, the court would have a couple of
questions:

Again, there is an implied license for a one-off usage, but no loss of
copyright. They could not publish my collected letters in a book without
obtaining further permission.

I am very happy
that the copyright of the code I have contributed to, eg, the GD graphics
library remains with me, but that it can be freely used & distributed in
GD. I would not want to sign my rights to that code away, then be told by
the person that buys GD from Tom Boutell that I am no longer permitted to
use the code I wrote.

Yes, of course.

The legend, though, says "portions copyright 1996-2000 by PG, Inc."

It doesn't identify which portions. Nor does the original statement
by UC. The reality is that no one could necessarily claim that any
contribution you make is part of the "portions".

As you said earlier, we all agree that they are doing this in the best
interests on PostgreSQL. The question is, what are they trying to achieve,
and can we achieve a better result another way?

As the law stands here, the only portions the company would own would be
the portions written by their employees while working at the company's
direction (assuming of course their work agreement assigns copyright to
their employer).

I'm not trying to offend anyone - as you say, I think we all want the same
result.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

From bouncefilter Sat Jan 29 01:55:14 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA81038
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 01:54:38 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA28811;
Sat, 29 Jan 2000 07:02:30 GMT
Sender: lockhart@hub.org
Message-ID: <38929086.8B961E91@alumni.caltech.edu>
Date: Sat, 29 Jan 2000 07:02:30 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Philip Warner <pjw@rhyme.com.au>
CC: The Hermit Hacker <scrappy@hub.org>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Copyright
References: <20000128170743.A12694@rice.edu>
<3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This depends on the definition of open source; I think Netscape is
OpenSource these days, but I doubt if anyone would be allowed to take the
sources and create "Petscape: The Dog's Browser". But, as far as I know, I
could go away tomorrow with the PostgreSQL sources and create "Mostgress",
so long as I did not try to sell it. AFAIK, I might even get away with
selling it, but it's not really the point.

Yes you could. The original Postgres developers (or at least some of
them) did just that in founding Illustra. They sold the company a
couple of years later for $50M US to Informix.

What matters is that it remains open, free, and modifyable by anyone, for
any purpose.

The original sources, and the modified sources *that we know about*
(someone could have and probably has taken the source code, modified
it, and not contributed back the changes) are always fair game to be
taken out of open source status. That is an artifact or benefit or
downside of the BSD license, depending on your PoV.

This does bring up the larger question of what happened to the original
copyrights? Is this covered in Bruce's upcoming book?

The original copyrights are still valid and travel with the code.
However, afaict they are designed to release UC Berkeley from
liability and to preserve some credit for the original work, not to
allow Berkeley to assert ownership control over derivative sources
(into which category I think the current PostgreSQL tree falls, so to
speak).

I think Marc is concerned that there be someone or something able to
represent the current code tree, and to prevent hijacking of the
PostgreSQL (and perhaps Postgres) names from this open source group.
He has been consistantly adamant about preserving the BSD copyright,
which leave the maximum flexibility for the use of the code tree
basically for any purpose by anyone. That isn't quite the same goal of
GPL, but check the archives for threads which cover these topics
exhaustively.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sat Jan 29 01:58:14 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA81461
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 01:57:42 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA28821;
Sat, 29 Jan 2000 07:06:00 GMT
Sender: lockhart@hub.org
Message-ID: <38929158.F84EAB80@alumni.caltech.edu>
Date: Sat, 29 Jan 2000 07:06:00 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Adriaan Joubert <a.joubert@albourne.com>
CC: Postgresql <pgsql-hackers@postgreSQL.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Bit strings
References: <3891D54C.E0004C05@albourne.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I wrote routines for the postgres backend to implement the SQL types
BIT and BIT VARYING. Unfortunately I do not
know postgres well enough yet to integrate the types into the backend
myself. Bruce Momjian has kindly offered to do
this, provided that people agree that having BIT and BIT VARYING is
desirable. I will do some regression tests once the
code has been integrated with postgres.

Yes it is desirable. I'll help too, and Bruce and I will need to
coordinate to keep him from stomping all over my patches while I'm
doing some upcoming date/time changes (that's a hint Bruce! :)

The code is currently in the contrib/bit directory of the snapshots, so
you can look at it there. If it passes muster or if there
are any recommendations to improve the code please let me know. If there
is more I can do to help with the integration,
please let me know as well.

If the code works or can be made workable we should integrate it imho.
There is not likely to be any good excuse to keep out an
SQL92-compliant type.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sat Jan 29 02:11:15 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA87434
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 02:10:52 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA14007;
Sat, 29 Jan 2000 02:10:22 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: bruc@acm.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Copyright
In-reply-to: <3.0.1.32.20000128222128.00ed0b70@mail.pacifier.com>
References: <200001290245.VAA15243@stone.congenomics.com>
<200001290245.VAA15243@stone.congenomics.com>
<3.0.1.32.20000128222128.00ed0b70@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Fri, 28 Jan 2000 22:21:28 -0800"
Date: Sat, 29 Jan 2000 02:10:22 -0500
Message-ID: <14004.949129822@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Don Baccus <dhogaza@pacifier.com> writes:

I think this is the concern (not mine, raised by others) - what
guarantee is there that PG, Inc couldn't change the terms if
(say) a new disease cropped up that killed all believers in Open
Source? :) (yes intentionally silly).

Well, the critical point here is that neither PG, Inc nor anyone
else can *retroactively* change the terms of distribution. The
copies that are out there are out there, with the terms of
distribution stated right in them. Anyone can pick one up and
start doing their own thing with the code. Neither UC Berkeley nor
any PostgreSQL contributor would have a leg to stand on to stop them;
you think the courts will look kindly on "oh, we didn't mean what we
said in the terms of distribution"?

The worst-case possible scenario is that Marc goes around the bend
and, five minutes before the release of version 7.42, announces that
7.42 will be distributed under new terms that everyone else thinks are
too tight. Everyone else just flips him the bird, goes back to 7.41
and continues on with life. (Furthermore, if anyone felt like suing,
such a last-minute switcheroo would never hold up in court. Anyone
who had contributed code to 7.42 under the reasonable expectation that
it would be licensed just like 7.41 would have plenty of grounds to
say "wait a minute, where do you think you're going with my code?")

Same scenario applies if Marc gets run over by a truck and the new
owners of PG Inc try to do something unreasonable. The fact is that
as long as the terms of distribution stay the same, PG Inc doesn't
have any real ability to hurt anyone.

If anyone wants to look into Apache and see how it's set up, I've got no
problem with taking a look. I think it's real easy to make a mountain
out of a molehill in this area, however. Look at FSF --- they actually
require signed paperwork (hard copy, not email) from any potential
contributor before they will accept code contributions. Do we want to
get that anal-retentive? I hope not.

regards, tom lane

From bouncefilter Sat Jan 29 02:31:14 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA90289
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 02:30:28 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA14037;
Sat, 29 Jan 2000 02:30:05 -0500 (EST)
To: Philip Warner <pjw@rhyme.com.au>
cc: bruc@acm.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: Copyright
In-reply-to: <3.0.5.32.20000129172421.00cf1e60@mail.rhyme.com.au>
References: <200001290245.VAA15243@stone.congenomics.com>
<200001290245.VAA15243@stone.congenomics.com>
<3.0.5.32.20000129172421.00cf1e60@mail.rhyme.com.au>
Comments: In-reply-to Philip Warner <pjw@rhyme.com.au>
message dated "Sat, 29 Jan 2000 17:24:21 +1100"
Date: Sat, 29 Jan 2000 02:30:05 -0500
Message-ID: <14034.949131005@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Philip Warner <pjw@rhyme.com.au> writes:

When you refer to the license terms, do you mean the 'COPYRIGHT' file in
the root directory, or is there something more?

Yeah. I have seen more extensive statements of the standard UC Berkeley
license terms (didn't BSD come with a different statement?) but that's
the one we are working with.

Now I'm confused. I thought there was a notice stating that PostgreSQL, Inc
had copy right? If that is the case, then they *can* sell it, and the buyer
could revise the license terms.

Not retroactively. Someone could try to do *new* development under
more restrictive terms, or just plain do some traditional proprietary
development using Postgres as a base. They've got just as much right
to use the code in that way as you or I do to use it as we want to.
But I doubt many of the current contributors would help.

The big advantage of a separate entity is that it has a clear charter
and no conflict of interest.

Only to the extent that the people sitting on its board of directors
have no conflict of interest --- otherwise they could easily vote to
make the separate entity do something unhappy-making. AFAICS these
would be more or less the same people who control PostgreSQL Inc;
namely the core developers. If you don't trust them when they're
wearing one hat, why trust them when wearing another?

regards, tom lane

From bouncefilter Sat Jan 29 02:33:14 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA93397
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 02:32:30 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA28873;
Sat, 29 Jan 2000 07:31:04 GMT
Sender: lockhart@hub.org
Message-ID: <38929737.24F8DA7B@alumni.caltech.edu>
Date: Sat, 29 Jan 2000 07:31:03 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Philip Warner <pjw@rhyme.com.au>, The Hermit Hacker <scrappy@hub.org>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Copyright
References: <200001290542.AAA09066@candle.pha.pa.us>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id CAA93434

What is quite confusing to me is that though we have copyrighted the
code now, we don't have a statement saying what that copyright allows
people to do with the code. And with no statement, we are basically
doing an "all rights reserved" thing, I think, which is certainly not
what is intended.

Here is what we have now:

PostgreSQL is Copyright ��� 1996-9 by the PostgreSQL Global Development
Group, and is distributed under the terms of the Berkeley license.

Postgres95 is Copyright ��� 1994-5 by the Regents of the University of
California. Permission to use, copy, modify, and distribute this
software and its documentation for any purpose,
without fee, and without a written agreement is hereby granted,
provided that the above copyright notice and this paragraph and the
following two paragraphs appear in all copies.

In no event shall the University of California be liable to any party
for direct, indirect, special, incidental, or consequential damages,
including lost profits, arising out of the use of this
software and its documentation, even if the University of California
has been advised of the possibility of such damage.

The University of California specifically disclaims any warranties,
including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. The software
provided hereunder is on an "as-is" basis, and the University of
California has no obligations to provide maintainance, support,
updates, enhancements, or modifications.

What we may need to do is be more explicit; perhaps we should restate
the text of the Berkeley copyright but substitute another group as the
current copyright holder, asking that credit be given to the group
when using or distributing the software.

afaict that is a perfectly reasonable request to make of users of the
code, and it gives all of us open-source contributors a way to see
where our work is being used in the future. That's part of what makes
this fun...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sat Jan 29 02:56:14 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA95895
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 02:56:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA14078;
Sat, 29 Jan 2000 02:55:57 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Philip Warner <pjw@rhyme.com.au>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Copyright
In-reply-to: <38929086.8B961E91@alumni.caltech.edu>
References: <20000128170743.A12694@rice.edu>
<3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>
<38929086.8B961E91@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Sat, 29 Jan 2000 07:02:30 +0000"
Date: Sat, 29 Jan 2000 02:55:56 -0500
Message-ID: <14075.949132556@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

The original sources, and the modified sources *that we know about*
(someone could have and probably has taken the source code, modified
it, and not contributed back the changes) are always fair game to be
taken out of open source status.

The above could easily be misinterpreted. I believe the point Thomas
meant to make is that anyone is free to make a derivative version that
they choose not to release as open source. It does *not* mean that
someone can take away your right to use existing code that was already
released with a Berkeley-style license.

The original copyrights are still valid and travel with the code.
However, afaict they are designed to release UC Berkeley from
liability and to preserve some credit for the original work, not to
allow Berkeley to assert ownership control over derivative sources
(into which category I think the current PostgreSQL tree falls, so to
speak).

Right, and I think that it's past time that the Postgres group (in
the person of PG Inc, or some other entity if that's what a majority
want) explicitly make the same statements that UC Berkeley has made.
Anyone here want to be on the hook for liability when some big
company's database crashes? Not me...

I think Marc is concerned that there be someone or something able to
represent the current code tree, and to prevent hijacking of the
PostgreSQL (and perhaps Postgres) names from this open source group.

That's actually quite a separate issue. Trademarking the name
"PostgreSQL" might be a good idea to prevent some random bozo from
claiming ownership of it. (In reality, I think any attempt by
someone else to register that name as a database trademark at this
point could easily be shot down, but it would be far cheaper to
register the mark pre-emptively than to file suit against someone's
predatory registration.) Yet ... on the other hand, if it were a
trademark then someone *could* buy it off PG Inc. If that happened,
we (the community) would still have the rights to use the Postgres code,
but we'd have to find another name for it ;-).

regards, tom lane

Roland Roberts wrote:

The Postgres guide says that foreign keys can be partially emulated
via triggers. Just how "partial" is this. I can't seem to get the
following to work. Would it work if I wrote it in C? Would I need to
open a second connection to the database? Would it work if my second
key was really in another table?

project=> CREATE FUNCTION check_task_pid () RETURNS OPAQUE AS '
project'> BEGIN
project'> IF NEW.task_pid IS NOT NULL THEN
project'> SELECT task_id FROM task WHERE task_id = NEW.task_pid;
project'> IF NOT FOUND THEN
project'> RAISE EXCEPTION ''FOREIGN KEY constraint task_pid not found'';
project'> END IF;
project'> END IF;
project'> RETURN NEW;
project'> END;
project'> ' LANGUAGE 'plpgsql';
CREATE
project=> CREATE TRIGGER iu_btrig_check_task_pid BEFORE INSERT OR UPDATE ON task
project-> FOR EACH ROW EXECUTE PROCEDURE check_task_pid();

At least in 6.5.2, you can definitely implement referential integrity
(RI) via pl/pgsql. As someone noted earlier, RI is to be released in
7.0, but I suspect it will take a subsequent release or two to
stabilize before it's fit for consumption by the more conservative
reliability-focused users among us...

As for your failing SELECT query, the following tweak to your function
makes it work as expected:

CREATE FUNCTION check_task_pid () RETURNS OPAQUE AS '
DECLARE
tmp RECORD;
BEGIN
IF NEW.task_pid IS NOT NULL THEN
SELECT INTO tmp task_id FROM task WHERE task_id =
NEW.task_pid;
IF NOT FOUND THEN
RAISE EXCEPTION ''FOREIGN KEY constraint task_pid not
found'';
END IF;
END IF;
RETURN NEW;
END;
' LANGUAGE 'plpgsql';

Cheers,
Ed Loehr

From bouncefilter Sat Jan 29 04:45:15 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id EAA45964
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 04:45:11 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 18298 invoked from network); 29 Jan 2000 09:45:07 -0000
Received: from h-62.96.161.89.host.de.colt.net (62.96.161.89)
by pille.addcom.de with SMTP; 29 Jan 2000 09:45:07 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id KAA01974
for pgsql-hackers@postgresql.org; Sat, 29 Jan 2000 10:36:55 +0100
Date: Sat, 29 Jan 2000 10:36:55 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Copyright
Message-ID: <20000129103655.A1966@fam-meskes.de>
Mail-Followup-To: PostgreSQL Development <pgsql-hackers@postgresql.org>
References: <200001281837.NAA00971@candle.pha.pa.us>
<12581.949099222@sss.pgh.pa.us> <20000128170743.A12694@rice.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <20000128170743.A12694@rice.edu>;
from reedstrm@wallace.ece.rice.edu on Fri, Jan 28, 2000 at
05:07:43PM -0600

On Fri, Jan 28, 2000 at 05:07:43PM -0600, Ross J. Reedstrom wrote:

Ah, corporate assets? What if someone bought out PostgreSQL, Inc., for
a huge sum of money. They'd get control of anything PostgreSQL, Inc.
has control over. One can't buy out a non-profit organization.

Which brings up the question whether PostgreSQL Inc. is a profit or a
non-profit organizationn.

AFARC that's the way Debian solved this problem, by forming a non-profit
organization name Software in the Public Interest (SPI) Inc.

Michael--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Sat Jan 29 04:40:15 2000
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA42450
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 04:39:45 -0500 (EST) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id MAA16849
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 12:39:43 +0300 (GMT)
Date: Sat, 29 Jan 2000 12:39:42 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgreSQL.org
Subject: select count(*) from hits group by count;
Message-ID: <Pine.GSO.3.96.SK.1000129123357.18405o-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi there,

I have a table hits:
discovery=> \d hits
Table    = hits
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| msg_id                           | int4 not null                    |     4 |
| count                            | int4 not null                    |     4 |
| first_access                     | datetime default now ( )         |     8 |
| last_access                      | datetime                         |     8 |
+----------------------------------+----------------------------------+-------+
Index:    hits_pkey

and query:
discovery=> select count(*) from hits group by count;
ERROR: Aggregates not allowed in GROUP BY clause

There's easy workaround :
discovery=> select count(*) as qq from hits group by count;
but I'm curious is this a valid query ?
Last snapshot also behave like 6.5.3

Another question:
discovery=> select count(*) as qqq,* from hits group by last_access;
produces error:
ERROR: Illegal use of aggregates or non-group column in target list

Do I really need to have all fields in GROUP clause ?
Mysql seems allows this ?

Regards,

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Sat Jan 29 04:45:16 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id EAA45966
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 04:45:13 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 18241 invoked from network); 29 Jan 2000 09:44:59 -0000
Received: from h-62.96.161.89.host.de.colt.net (62.96.161.89)
by pille.addcom.de with SMTP; 29 Jan 2000 09:44:59 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id KAA01987
for pgsql-hackers@postgresql.org; Sat, 29 Jan 2000 10:42:17 +0100
Date: Sat, 29 Jan 2000 10:42:17 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Copyright
Message-ID: <20000129104217.B1966@fam-meskes.de>
Mail-Followup-To: PostgreSQL Development <pgsql-hackers@postgresql.org>
References: <20000128170743.A12694@rice.edu>
<Pine.BSF.4.21.0001290101540.555-100000@thelab.hub.org>
<3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>;
from pjw@rhyme.com.au on Sat, Jan 29, 2000 at 04:31:55PM +1100

On Sat, Jan 29, 2000 at 04:31:55PM +1100, Philip Warner wrote:

This depends on the definition of open source; I think Netscape is
OpenSource these days, but I doubt if anyone would be allowed to take the

The new version 5 code yes. The old version 4 is just given away for free.

sources and create "Petscape: The Dog's Browser". But, as far as I know, I
could go away tomorrow with the PostgreSQL sources and create "Mostgress",
so long as I did not try to sell it. AFAIK, I might even get away with
selling it, but it's not really the point.

Yes, you can sell Mostgress. That's one of the problems with a BSD type
license. That's why may use GPL for there open source projects.

What matters is that it remains open, free, and modifyable by anyone, for
any purpose.

The source as it is now will remain open, free and modifyable. If someone
forsk its own version that's a different matter. But ours remains open.

Michael

--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Sat Jan 29 05:29:16 2000
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA56715
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 05:29:02 -0500 (EST) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id NAA17747
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 13:28:58 +0300 (GMT)
Date: Sat, 29 Jan 2000 13:28:58 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgreSQL.org
Subject: Does initdb -e is working ? (Latest dev. snapshot)
Message-ID: <Pine.GSO.3.96.SK.1000129130635.18405q-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Probably I miss something
I tried latest snapshot and notice some changes in configure.
Everything went smoothly on my Linux 2.2.14, glic 2.1.2 system.

One problem: I tried initdb -e koi8 and it doesn't works -
all databases I have are in SQL_ASCII encoding
Database | Owner | Encoding
-----------+----------+-----------
discovery | postgres | SQL_ASCII
template1 | postgres | SQL_ASCII
test | postgres | SQL_ASCII

createdb -E koi8 works as expected:
createdb -E koi8 aa
CREATE DATABASE
zen:~$ psql -l
List of databases
Database | Owner | Encoding
-----------+----------+-----------
aa | postgres | KOI8
discovery | postgres | SQL_ASCII
template1 | postgres | SQL_ASCII
test | postgres | SQL_ASCII

I found -e for initdb , -E for createdb options for specifying encoding a
little bit confused - why not just use one of them !

Is't possible to change encoding of database except dump/destroydb/createdb
cycle ? Is't worth to have pg_encoding to do this ?

Regards,

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Sat Jan 29 06:07:17 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA67942
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 06:06:48 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64125 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S155691AbQA2LF7>;
Sat, 29 Jan 2000 12:05:59 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12EVoy-0000Ab-00; Sat, 29 Jan 2000 12:13:40 +0100
Date: Sat, 29 Jan 2000 12:13:40 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgresql.org
Subject: GUC (Re: AW: AW: [HACKERS] Some notes on optimizer cost estimates)
In-Reply-To: <11010.949078779@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001281949040.487-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-01-28, Tom Lane mentioned:

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Added to TODO:
* Unify configuration into one configuration file

... and that is a good example of database design because?? ;)

This has more to do with software administration than database design or
databases in the first place. IMHO, o.c.

One thing to consider while contemplating a grand unified config file
(GUC?)

Darn, I was gonna suggest that name.

is that much of this stuff needs to be settable per-client.
It would be wrong to rip out whatever dynamic option-setting code
there is. Cleaning it up and making a more uniform interface to the
various options does sound like a good project though.

Nobody said anything about ripping out existing code. There just need to
be defaults settable somewhere without entering -o -F -f -B -q -R -n all
the time. I'm sure we can come up with something.

I'd want to see a paper design for how things should work before any
coding starts --- the existing methods do have some non-obvious
advantages. For example, even something as grotty as the PGOPTIONS
environment variable has its uses: you can pass options through to
a backend without needing explicit cooperation from your client
application.

So PGOPTIONS can be tied into the scheme.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Jan 29 06:07:19 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA67952
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 06:06:57 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64300 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S176165AbQA2LGS>;
Sat, 29 Jan 2000 12:06:18 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12EVpJ-0000Bi-00; Sat, 29 Jan 2000 12:14:01 +0100
Date: Sat, 29 Jan 2000 12:14:01 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] TODO list check
In-Reply-To: <7234.949017952@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001291151150.364-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-01-27, Tom Lane mentioned:

* Disallow inherited columns with the same name as new columns

Either this was just not marked off, or there is some misconception about
how things should work.

Well, I'm not sure. Clearly, multiple inheritance is a problem if you
can't inherit similar columns from two parents. But is it a good idea
to allow a child to declare (what it thinks is) a new column, and have
that silently get merged with an inherited column? Seems like kicking
out an error would be a better idea.

Okay, now it gives an error if you try to create a new column with the
same name as an inherited column, but allows merging of columns between
inherited tables. Check.

* SELECT ... UNION ... ORDER BY fails when sort expr not in result list

Looks good to me:

No, it's still broken; your test case doesn't actually exercise any
sorting, does it? The bug is that the ORDER BY only gets applied to the
first SELECT; the rest are just appended on. This bug is awaiting
querytree redesign; it's possible that it could be fixed now, but the
UNION code is so bogus that no one really wants to touch it now...

* SELECT ... UNION ... GROUP BY fails if column types disagree

Shouldn't it?

Not if they can be promoted to a common supertype. The entry is pretty
misleading because it is so terse though.

How about adding this into TODO.detail, so two months from now everyone
(except those that keep outside lists) remembers it. (Or just rephrase
this item, if you can.)

* Do not allow bpchar column creation without length

Looks good to me (and is standard compliant).

I don't see a good reason for this item either.

This item may be the same as the one below. The other day while working on
psql and mapping internal to sql types for \d output I noticed that system
tables have char columns with -1 typmod. I suppose that this would be your
char1 type?

* Allow user to define char1 column

Come to think of it, it was mostly me complaining about this, so maybe
I should just go do it; no time for it like 7.0, no? Will anyone object
if I do this?

At least the above behaviour is very subtle indeed. While I'm not so
excited about having all kinds of "more efficient" types around for
internal use (char1, abstime, some of the oid arrays), do what you feel is
best. The clean solution would seem to be item

* Allow char() not to use variable-sized header to reduce disk size

where you would use the atttypmod as the length instead of the header. But
a general solution like this would probably require too many structural
changes.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Jan 29 06:10:16 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA68244
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 06:09:39 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62057 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S167979AbQA2LIt>;
Sat, 29 Jan 2000 12:08:49 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12EVrn-0000Hf-00; Sat, 29 Jan 2000 12:16:35 +0100
Date: Sat, 29 Jan 2000 12:16:35 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] END/ABORT
In-Reply-To: <12524.949097912@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001291215400.364-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-01-28, Tom Lane mentioned:

Peter Eisentraut <peter_e@gmx.net> writes:

I'd like to yank the END/ABORT commands, since they're non-standard and
redundant (COMMIT/ROLLBACK). Anyone who could not bear to see them go?

Exactly what will this accomplish, other than breaking a lot of existing
applications? (Including all of mine, which no doubt biases my thinking.)

Okay, I was just wondering. But I'm going to change all the notices and
docs to use commit and rollback instead.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Jan 29 06:30:17 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA71182
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 06:29:56 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id UAA19546;
Sat, 29 Jan 2000 20:29:54 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-4 [133.137.84.4])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id UAA09894;
Sat, 29 Jan 2000 20:29:52 +0900
To: oleg@sai.msu.su
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Does initdb -e is working ? (Latest dev. snapshot)
In-Reply-To: <Pine.GSO.3.96.SK.1000129130635.18405q-100000@ra>
References: <Pine.GSO.3.96.SK.1000129130635.18405q-100000@ra>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000129203243B.t-ishii@sra.co.jp>
Date: Sat, 29 Jan 2000 20:32:43 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 25

Probably I miss something
I tried latest snapshot and notice some changes in configure.
Everything went smoothly on my Linux 2.2.14, glic 2.1.2 system.

One problem: I tried initdb -e koi8 and it doesn't works -

Because someone has changed -e to -E.

I found -e for initdb , -E for createdb options for specifying encoding a
little bit confused - why not just use one of them !

So now both initdb and createdb use -E as you expect. I think this is
a good thing.

Is't possible to change encoding of database except dump/destroydb/createdb
cycle ? Is't worth to have pg_encoding to do this ?

update pg_database set encoding = pg_char_to_encoding('KOI8');

should work for you. However I'm a little bit worried about the
syscache staffs. It would be safer to shutdown postmaster then issue
the update command from standalone postgres.
--
Tatsuo Ishii

From bouncefilter Sat Jan 29 07:04:17 2000
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA81757
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 07:02:27 -0500 (EST) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id PAA19301;
Sat, 29 Jan 2000 15:02:06 +0300 (GMT)
Date: Sat, 29 Jan 2000 15:02:05 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Does initdb -e is working ? (Latest dev. snapshot)
In-Reply-To: <20000129203243B.t-ishii@sra.co.jp>
Message-ID: <Pine.GSO.3.96.SK.1000129145432.18405t-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 29 Jan 2000, Tatsuo Ishii wrote:

Date: Sat, 29 Jan 2000 20:32:43 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: oleg@sai.msu.su
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Does initdb -e is working ? (Latest dev. snapshot)

Probably I miss something
I tried latest snapshot and notice some changes in configure.
Everything went smoothly on my Linux 2.2.14, glic 2.1.2 system.

One problem: I tried initdb -e koi8 and it doesn't works -

Because someone has changed -e to -E.

OK. this is good if we have now similar option,
I suggest Peter should reflect this change in initdb --help
Usage:
initdb [options] datadir

Options:
[-D, --pgdata] <datadir> Location for this database
-W, --pwprompt Prompt for a password for the new superuser's
-e, --encoding <encoding> Set the default multibyte encoding for new databases
^^^

I found -e for initdb , -E for createdb options for specifying encoding a
little bit confused - why not just use one of them !

So now both initdb and createdb use -E as you expect. I think this is
a good thing.

Is't possible to change encoding of database except dump/destroydb/createdb
cycle ? Is't worth to have pg_encoding to do this ?

update pg_database set encoding = pg_char_to_encoding('KOI8');

should work for you. However I'm a little bit worried about the
syscache staffs. It would be safer to shutdown postmaster then issue
the update command from standalone postgres.

Thanks, it works fine.

Regards,
Oleg

--
Tatsuo Ishii

************

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Sat Jan 29 08:45:18 2000
Received: from fep132.fep.ru (mail@fep132.fep.ru [195.230.89.88])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA03953
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 08:45:16 -0500 (EST) (envelope-from phd@phd.russ.ru)
Received: from localhost [127.0.0.1] (phd)
by fep132.fep.ru with esmtp (Exim 2.05 #1 (Debian))
id 12EYBO-0007au-00; Sat, 29 Jan 2000 16:44:58 +0300
Date: Sat, 29 Jan 2000 13:44:58 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Postgres LOGO(was: Beta is February 15th)
In-Reply-To: <200001290155.UAA00217@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001291335080.29138-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 28 Jan 2000, Bruce Momjian wrote:

Not sure this was announced, but we are planning beta for 7.0 to start
in February 15, not February 1, as originally planned.

I am taking part in writing articles for
http://www.simplex.ru/news/koi/. It is russian weblog, similar to Slahdot.
Mostly I post announcements of different Python and Zope-related products.
But the version 7.0 will be so major change. I want to put an
announcement there, and to do this I need a logo - any small picture. Where
can I get Postgres logo?

http://www.postgresql.org/images/verh2.gif is mostly good for me. Are
there others?

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Sat Jan 29 09:39:19 2000
Received: from fep132.fep.ru (mail@fep132.fep.ru [195.230.89.88])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA20723
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 09:38:55 -0500 (EST) (envelope-from phd@phd.russ.ru)
Received: from localhost [127.0.0.1] (phd)
by fep132.fep.ru with esmtp (Exim 2.05 #1 (Debian))
id 12EZ1S-0007fm-00; Sat, 29 Jan 2000 17:38:46 +0300
Date: Sat, 29 Jan 2000 14:38:46 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Locale patch
Message-ID: <Pine.LNX.4.21.0001291434560.29457-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello!

I posted a patch to pgsql-patches list for locale tests. There are two
things to patch there - "destroydb" was renamed to "dropdb", and psql
output format changes.

I want to report that both locale and multibyte support works pretty
well for russian cyrillic in the snapshot of 21 Jan.

Is here anyone who understand Greek and use ISO8859-7 locale? Can you
verify this part of locale tests?

Anyone going to submit locale tests for other locales?

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Sat Jan 29 10:42:20 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA35801
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 10:41:56 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA16645;
Sat, 29 Jan 2000 07:40:43 -0800 (PST)
Message-Id: <3.0.1.32.20000129070058.00ed58f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 29 Jan 2000 07:00:58 -0800
To: Philip Warner <pjw@rhyme.com.au>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Copyright
Cc: The Hermit Hacker <scrappy@hub.org>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <3.0.5.32.20000129175046.009cca30@mail.rhyme.com.au>
References: <3.0.1.32.20000128223248.00ed3e10@mail.pacifier.com>
<3.0.5.32.20000129170141.00cf5e40@mail.rhyme.com.au>
<200001290542.AAA09066@candle.pha.pa.us>
<3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 05:50 PM 1/29/00 +1100, Philip Warner wrote:

There's an explicit permission to publish when you mail in your letter
to the editor. If you were to sue, the court would have a couple of
questions:

Again, there is an implied license for a one-off usage, but no loss of
copyright. They could not publish my collected letters in a book without
obtaining further permission.

It's debatable, at least here in the US. You could look into recent
fights among photographers and publishers over web redistribution of
articles originally published with ink on paper, for instance.

The issue isn't loss of copyright, but license scope...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Jan 29 10:42:19 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA35813
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 10:42:12 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA16660;
Sat, 29 Jan 2000 07:40:45 -0800 (PST)
Message-Id: <3.0.1.32.20000129070734.0103b5b0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 29 Jan 2000 07:07:34 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Copyright
Cc: bruc@acm.org, pgsql-hackers@postgreSQL.org
In-Reply-To: <14004.949129822@sss.pgh.pa.us>
References: <3.0.1.32.20000128222128.00ed0b70@mail.pacifier.com>
<200001290245.VAA15243@stone.congenomics.com>
<200001290245.VAA15243@stone.congenomics.com>
<3.0.1.32.20000128222128.00ed0b70@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:10 AM 1/29/00 -0500, Tom Lane wrote:

If anyone wants to look into Apache and see how it's set up, I've got no
problem with taking a look. I think it's real easy to make a mountain
out of a molehill in this area, however. Look at FSF --- they actually
require signed paperwork (hard copy, not email) from any potential
contributor before they will accept code contributions. Do we want to
get that anal-retentive? I hope not.

Yes, in spirit I'm certainly with you on this one. I presume some
laywer started hacking code in his spare time then started hacking
the FSF as well :)

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Jan 29 10:48:19 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA36572
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 10:47:53 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm243.noc.fukui.nsk.ne.jp [210.161.188.118])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id AAA08832; Sun, 30 Jan 2000 00:47:36 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "The Hermit Hacker" <scrappy@hub.org>
Cc: <bright@ns1.wintelcom.net>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] [6.5.2] potentially major bug?
Date: Sun, 30 Jan 2000 00:48:36 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFIEHOCCAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <000d01bf6953$46daa700$2801007e@tpf.co.jp>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of The Hermit
Hacker

Okay, I don't know if this has been fixed in 7.0, but:

webcounter=> drop index webhit_referer_raw_url;
DROP
webcounter=> create index webhit_referer_raw_url on
webhit_referer_raw using btree ( referrer_url );
CREATE
webcounter=> vacuum verbose webhit_referer_raw;
NOTICE: --Relation webhit_referer_raw--
NOTICE: Pages 7910: Changed 3, Reapped 2192, Empty 0, New 0; Tup
547520: Vac 43402, Keep/VTL 0/0, Crash 0, UnUsed 4871, MinLen 60,
MaxLen 312; Re-using: Free/Avail. Space 4388524/4361716;
EndEmpty/Avail. Pages 0/915. Elapsed 0/0 sec.
NOTICE: Index webhit_referer_raw_url: Pages 5048; Tuples 547400:
Deleted 0. Elapsed 0/2 sec.
NOTICE: Index webhit_referer_raw_url: NUMBER OF INDEX' TUPLES
(547400) IS NOT THE SAME AS HEAP' (547520)

Hmmm,isn't there old transaction running somewhere ?

If so,this may be due to the use of SnapshotNow in CREATE INDEX
command which Tom already specified a few months ago.
We have already SnapshotAny(Jan added ?) now.
Probably this would be solved by changing SnapshotNow -> SnapshotAny.

Oops,this is not so easy.
Comparetub_index() rejects duplicate index.
Is it an appropriate way to check visibility of heap
tuples in comapretub_index() ?

Comments ?

Regards.

Hirioshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sat Jan 29 10:59:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA38286
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 10:58:42 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA14741;
Sat, 29 Jan 2000 10:58:37 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list check
In-reply-to: <Pine.LNX.4.21.0001291151150.364-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001291151150.364-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sat, 29 Jan 2000 12:14:01 +0100"
Date: Sat, 29 Jan 2000 10:58:37 -0500
Message-ID: <14738.949161517@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

The clean solution would seem to be item

* Allow char() not to use variable-sized header to reduce disk size

where you would use the atttypmod as the length instead of the header. But
a general solution like this would probably require too many structural
changes.

Right now, *all* variable-length types have a varlena header, and
I think there isn't much of any way around that for internal
representation --- if Datums aren't self-sufficient then we've got
a real notational nightmare in the expression evaluator and function
call mechanism. Maybe we could make the inside-a-tuple representation
different from what gets passed around in expression evaluation, but
that sure looks like a can of worms to me. So I don't foresee this
TODO item getting done any time soon --- the cost/benefit ratio looks
way too high compared to all our other projects.

The reason the "allow access to char1" item is there is that I have an
application that has several different status indicators in each row
of a large table. I represented them as "char" values, which was both
useful for debugging ('P' = pending, etc) and compact, or so I thought.
When I realized that my status fields were not taking one byte apiece
as I expected, but eight bytes apiece (length word + alignment), I
wasn't happy.

We are using char1 as an enumerated type in several system fields
(relkind, for example) so I see no good reason why that type shouldn't
be available to user applications. It is actually possible to *make*
a char1 field in a user table:
create table t1 (f1 "char");
but pg_dump won't reliably dump and restore this declaration because
it depends on a quoting hack not to be rewritten as bpchar(1) by the
parser.

regards, tom lane

From bouncefilter Sat Jan 29 11:00:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA38363
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 10:59:23 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA14758;
Sat, 29 Jan 2000 10:59:21 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] END/ABORT
In-reply-to: <Pine.LNX.4.21.0001291215400.364-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001291215400.364-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sat, 29 Jan 2000 12:16:35 +0100"
Date: Sat, 29 Jan 2000 10:59:21 -0500
Message-ID: <14755.949161561@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

I'd like to yank the END/ABORT commands, since they're non-standard and
redundant (COMMIT/ROLLBACK). Anyone who could not bear to see them go?

Exactly what will this accomplish, other than breaking a lot of existing
applications? (Including all of mine, which no doubt biases my thinking.)

Okay, I was just wondering. But I'm going to change all the notices and
docs to use commit and rollback instead.

OK, that seems fair enough.

regards, tom lane

From bouncefilter Sat Jan 29 11:26:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA45542
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 11:25:32 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA14905;
Sat, 29 Jan 2000 11:24:59 -0500 (EST)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] select count(*) from hits group by count;
In-reply-to: <Pine.GSO.3.96.SK.1000129123357.18405o-100000@ra>
References: <Pine.GSO.3.96.SK.1000129123357.18405o-100000@ra>
Comments: In-reply-to Oleg Bartunov <oleg@sai.msu.su>
message dated "Sat, 29 Jan 2000 12:39:42 +0300"
Date: Sat, 29 Jan 2000 11:24:58 -0500
Message-ID: <14902.949163098@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Oleg Bartunov <oleg@sai.msu.su> writes:

discovery=> select count(*) from hits group by count;
ERROR: Aggregates not allowed in GROUP BY clause

There's easy workaround :
discovery=> select count(*) as qq from hits group by count;
but I'm curious is this a valid query ?

I believe this is probably a bug. We are treating GROUP BY the same
way we treat ORDER BY, namely that if an item is a simple name or
integer constant, we try first to interpret it as a result-column
name or number; only if it does not match any column name do we fall
back on treating it as a general expression. And the default result-
column name for "count(*)" is just "count".

This behavior is necessary to conform to the standard for ORDER BY ---
in fact, SQL92 doesn't actually allow anything *but* a result-column
name or number for ORDER BY. Accepting an expression is a Postgres
extension (I imagine other DBMSs do it too).

But I can't see anything in the spec that justifies treating a GROUP BY
item that way: a GROUP BY item is defined as a <column reference> which
is a plain expression constituent. We should probably change the code
behavior so that GROUP BY is always interpreted as a normal expression.

Question is, how many existing apps might be broken by such a change?

Another question:
discovery=> select count(*) as qqq,* from hits group by last_access;
produces error:
ERROR: Illegal use of aggregates or non-group column in target list

Do I really need to have all fields in GROUP clause ?

Yes. See SQL92 7.9(7):

7) If T is a grouped table, then each <column reference> in each
<value expression> that references a column of T shall refer-
ence a grouping column or be specified within a <set function
specification>.

Mysql seems allows this ?

Mysql is broken if it accepts this. There's no unique answer to give
for an ungrouped, non-aggregated column.

regards, tom lane

From bouncefilter Sat Jan 29 11:40:20 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA51114
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 11:40:06 -0500 (EST)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id TAA90439;
Sat, 29 Jan 2000 19:35:46 +0300 (MSK)
X-Real-To: pgsql-hackers@postgresql.org
Received: (from dms@localhost)
by woland.wplus.net (8.9.3/8.9.1/wplus.2) id TAA06868;
Sat, 29 Jan 2000 19:40:04 +0300 (MSK)
Message-ID: <XFMail.20000129194004.dms@wplus.net>
X-Mailer: XFMail 1.4.4 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.GSO.3.96.SK.1000129123357.18405o-100000@ra>
Date: Sat, 29 Jan 2000 19:40:04 +0300 (MSK)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Oleg Bartunov <oleg@sai.msu.su>
Subject: RE: [HACKERS] select count(*) from hits group by count;
Cc: pgsql-hackers@postgresql.org

On 29-Jan-2000 Oleg Bartunov wrote:

Hi there,
and query:
discovery=> select count(*) from hits group by count;
ERROR: Aggregates not allowed in GROUP BY clause

There's easy workaround :
discovery=> select count(*) as qq from hits group by count;
but I'm curious is this a valid query ?
Last snapshot also behave like 6.5.3

Another question:
discovery=> select count(*) as qqq,* from hits group by last_access;
produces error:
ERROR: Illegal use of aggregates or non-group column in target list

AFAIK, MS SQL, Sybase and Informix have the same restrictions,
because using all fields in query with aggregates and grouping
is meaningless. Order of fields in group by clause also significant.

--
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

From bouncefilter Sat Jan 29 11:54:21 2000
Received: from thelab.hub.org (nat202.87.mpoweredpc.net [142.177.202.87])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA53778
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 11:54:13 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA44811;
Sat, 29 Jan 2000 12:51:27 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 29 Jan 2000 12:51:27 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, bruc@acm.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Copyright
In-Reply-To: <3.0.1.32.20000128222128.00ed0b70@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001291240550.555-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 28 Jan 2000, Don Baccus wrote:

At 12:52 AM 1/29/00 -0500, Tom Lane wrote:

As long as those terms don't change, adding PostgreSQL Inc (or
PostgreSQL Nonprofit Copyright Holding Corporation, or anything else)
to the copyright notices doesn't really change anything, except for
adding one more line to the boilerplate notice that people aren't
supposed to strip out of their copies.

I think this is the concern (not mine, raised by others) - what
guarantee is there that PG, Inc couldn't change the terms if
(say) a new disease cropped up that killed all believers in Open
Source? :) (yes intentionally silly).

Simple answer: the developers all go off with source code at the time that
PostgreSQL, Inc changes those terms and continues off where they left off
... IMHO, that is the nice thing about Open Source ... look at the
FreeBSD/OpenBSD/NetBSD camps ... developers A became unhappy with politics
in camp A so formed camp B and went on their merry way ... all three are
equally successful...

The same thing applies to Linux ... how many different distributions and
philosophies are out there now?

You are right, PostgreSQL, Inc could go out, change the license on the
code "from this day forth", but that doesn't stop developers to branch off
a new code base based upon the license of "the day before" and totally
leaving PostgreSQL, Inc in the dust ...

This could be really simple to fix in legal terms. With a not
for profit, distribution and development of a free and unencumbered
system could probably be incorporated into the bylaws and this may
be why the Apache Foundation was formed. It's harder with companies,
which by definition are formed to be profitable and indeed in the
eyes of the IRS are supposed to strive for that goal (though there
is no need to succeed).

So...maybe "Inc" isn't the right long-term shape of the entity?

Personally, I don't think anyone should be terribly concerned about
this. But I can see how some, especially folks who aren't US
citizens and perhaps don't know much about the realities of all this
in US law, could become concerned.

Ummm...PostgreSQL, Inc isn't a US company...*technically*, like OpenBSD,
PostgreSQL is a Canadian Open Source Project, as its development is based
in Canada ... which has this neat little advantage that OpenBSD has taken
advantage of, but we haven't yet: we can add stuff like SSL encryption
directly into the source code and distribute it legally...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sat Jan 29 12:00:22 2000
Received: from thelab.hub.org (nat202.87.mpoweredpc.net [142.177.202.87])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA54725
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 11:59:27 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA44835;
Sat, 29 Jan 2000 12:58:15 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 29 Jan 2000 12:58:15 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Philip Warner <pjw@rhyme.com.au>, Bruce Momjian <pgman@candle.pha.pa.us>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Copyright
In-Reply-To: <3.0.1.32.20000128223248.00ed3e10@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001291255210.555-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 28 Jan 2000, Don Baccus wrote:

It doesn't identify which portions. Nor does the original statement
by UC. The reality is that no one could necessarily claim that any
contribution you make is part of the "portions".

And, as the wu-ftpd distribution has always done, there is *nothing* to
stop someone working in 'heapam.c' from adding a personal 'Portions
Copyright(c) 1999 by Bruce Momjian' ... we put a 'blanket copyright on' to
provide a 'general cover', but there is nothing from stopping ppl from
adding more specific ones for the work they do:

===========================================
/****************************************************************************

Copyright (c) 1999 WU-FTPD Development Group.
All rights reserved.

Portions Copyright (c) 1980, 1985, 1988, 1989, 1990, 1991, 1993, 1994
The Regents of the University of California.
Portions Copyright (c) 1993, 1994 Washington University in Saint Louis.
Portions Copyright (c) 1996, 1998 Berkeley Software Design, Inc.
Portions Copyright (c) 1989 Massachusetts Institute of Technology.
Portions Copyright (c) 1998 Sendmail, Inc.
Portions Copyright (c) 1983, 1995, 1996, 1997 Eric P. Allman.
Portions Copyright (c) 1997 by Stan Barber.
Portions Copyright (c) 1997 by Kent Landfield.
Portions Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997
Free Software Foundation, Inc.
===========================================

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sat Jan 29 11:53:28 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA53464
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 11:52:23 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64099 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S200739AbQA2Qvf>;
Sat, 29 Jan 2000 17:51:35 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12EbCh-00027T-00; Sat, 29 Jan 2000 17:58:31 +0100
Date: Sat, 29 Jan 2000 17:58:31 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Does initdb -e is working ? (Latest dev. snapshot)
In-Reply-To: <Pine.GSO.3.96.SK.1000129130635.18405q-100000@ra>
Message-ID: <Pine.LNX.4.21.0001291248530.364-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-01-29, Oleg Bartunov mentioned:

One problem: I tried initdb -e koi8 and it doesn't works -

createdb -E koi8 works as expected:

I found -e for initdb , -E for createdb options for specifying encoding a
little bit confused - why not just use one of them !

That's exactly why initdb uses -E as well now. But I see now it doesn't
reject invalid args because it interprets them as data directory. Will
fix.

Next time: initdb -? or initdb --help.

Is't possible to change encoding of database except dump/destroydb/createdb
cycle ? Is't worth to have pg_encoding to do this ?

pg_encoding is just a tools that maps encoding names to codes and vice
versa.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Jan 29 11:53:22 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA53472
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 11:52:26 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64284 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S272430AbQA2Qvo>;
Sat, 29 Jan 2000 17:51:44 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12EbDB-00027Z-00; Sat, 29 Jan 2000 17:59:01 +0100
Date: Sat, 29 Jan 2000 17:59:00 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] END/ABORT
In-Reply-To: <200001281837.NAA01003@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001291355220.364-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-01-28, Bruce Momjian mentioned:

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

I'd like to yank the END/ABORT commands, since they're non-standard and
redundant (COMMIT/ROLLBACK). Anyone who could not bear to see them go?
(Of course END would stay as a reserved word.)

We have to keep them in there for compatibility with older code.

Okay, maybe yank was the wrong word. But I changed the command tags to
commit/rollback and the notices to something friendlier.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Jan 29 11:53:28 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA53466
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 11:52:24 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64442 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S213033AbQA2Qvp>;
Sat, 29 Jan 2000 17:51:45 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12EbDO-00027b-00; Sat, 29 Jan 2000 17:59:14 +0100
Date: Sat, 29 Jan 2000 17:59:14 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Copyright
In-Reply-To: <200001281837.NAA00971@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001291255550.364-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-01-28, Bruce Momjian mentioned:

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

This came down with my latest update and confused me quite a bit:

* Portions Copyright (c) 1996-2000, PostgreSQL, Inc

Since when do *they* own the copyright? Whatever happened to the good old
PostgreSQL Global Development Group? Assigning the copyright of an open
source project to a commercial entity is something unprecedented, and
quite frankly (without having anything at all against PostgreSQL, Inc) I
am not so excited about it.

That is what I was told by Marc. If we want to discuss it, go ahead.
Such a change was planned in late December, though there was no
discussion who gets the copyright. I believe he used PostgreSQL Inc.
because it is a legal entity, vs. the development team, which is not.

In any case, a better way to search for copyright notices is

egrep -i '\(c\)|copyright'

Just

egrep '\(C\)'

will miss some. ;)

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Jan 29 11:54:20 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id LAB53662
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 11:53:42 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61717 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S251938AbQA2QxE>;
Sat, 29 Jan 2000 17:53:04 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12EbEv-00027f-00; Sat, 29 Jan 2000 18:00:49 +0100
Date: Sat, 29 Jan 2000 18:00:49 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Does initdb -e is working ? (Latest dev. snapshot)
In-Reply-To: <Pine.LNX.4.21.0001291248530.364-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0001291800200.364-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-01-29, Peter Eisentraut mentioned:

On 2000-01-29, Oleg Bartunov mentioned:

One problem: I tried initdb -e koi8 and it doesn't works -

createdb -E koi8 works as expected:

I found -e for initdb , -E for createdb options for specifying encoding a
little bit confused - why not just use one of them !

That's exactly why initdb uses -E as well now. But I see now it doesn't
reject invalid args because it interprets them as data directory. Will
fix.

Next time: initdb -? or initdb --help.

Sorry, I just noticed that the help is wrong.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Jan 29 12:11:20 2000
Received: from thelab.hub.org (nat202.87.mpoweredpc.net [142.177.202.87])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA60684
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 12:10:23 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id NAA45004;
Sat, 29 Jan 2000 13:07:48 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 29 Jan 2000 13:07:48 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, bruc@acm.org,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: Copyright
In-Reply-To: <14004.949129822@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001291303420.555-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 29 Jan 2000, Tom Lane wrote:

The worst-case possible scenario is that Marc goes around the bend
and, five minutes before the release of version 7.42, announces that
7.42 will be distributed under new terms that everyone else thinks are
too tight. Everyone else just flips him the bird, goes back to 7.41
and continues on with life. (Furthermore, if anyone felt like suing,
such a last-minute switcheroo would never hold up in court. Anyone
who had contributed code to 7.42 under the reasonable expectation that
it would be licensed just like 7.41 would have plenty of grounds to
say "wait a minute, where do you think you're going with my code?")

Actually, given that scenario, it wouldn't even a matter of going back to
7.41 ... everything in CVS, so you'd go back to the source tree as of the
date before the license changed ...

IMHO, the worst thing *anyone* organization could do is change the license
in such a way as to alienate the only thing of value ... the developers
*shrug*

From bouncefilter Sat Jan 29 12:26:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA64208
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 12:25:46 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA28392;
Sat, 29 Jan 2000 12:23:45 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001291723.MAA28392@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list check
In-Reply-To: <Pine.LNX.4.21.0001291151150.364-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 29, 2000 12:14:01 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 29 Jan 2000 12:23:45 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

TODO list updated with your suggestions.

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

On 2000-01-27, Tom Lane mentioned:

* Disallow inherited columns with the same name as new columns

Either this was just not marked off, or there is some misconception about
how things should work.

Well, I'm not sure. Clearly, multiple inheritance is a problem if you
can't inherit similar columns from two parents. But is it a good idea
to allow a child to declare (what it thinks is) a new column, and have
that silently get merged with an inherited column? Seems like kicking
out an error would be a better idea.

Okay, now it gives an error if you try to create a new column with the
same name as an inherited column, but allows merging of columns between
inherited tables. Check.

* SELECT ... UNION ... ORDER BY fails when sort expr not in result list

Looks good to me:

No, it's still broken; your test case doesn't actually exercise any
sorting, does it? The bug is that the ORDER BY only gets applied to the
first SELECT; the rest are just appended on. This bug is awaiting
querytree redesign; it's possible that it could be fixed now, but the
UNION code is so bogus that no one really wants to touch it now...

* SELECT ... UNION ... GROUP BY fails if column types disagree

Shouldn't it?

Not if they can be promoted to a common supertype. The entry is pretty
misleading because it is so terse though.

How about adding this into TODO.detail, so two months from now everyone
(except those that keep outside lists) remembers it. (Or just rephrase
this item, if you can.)

* Do not allow bpchar column creation without length

Looks good to me (and is standard compliant).

I don't see a good reason for this item either.

This item may be the same as the one below. The other day while working on
psql and mapping internal to sql types for \d output I noticed that system
tables have char columns with -1 typmod. I suppose that this would be your
char1 type?

* Allow user to define char1 column

Come to think of it, it was mostly me complaining about this, so maybe
I should just go do it; no time for it like 7.0, no? Will anyone object
if I do this?

At least the above behaviour is very subtle indeed. While I'm not so
excited about having all kinds of "more efficient" types around for
internal use (char1, abstime, some of the oid arrays), do what you feel is
best. The clean solution would seem to be item

* Allow char() not to use variable-sized header to reduce disk size

where you would use the atttypmod as the length instead of the header. But
a general solution like this would probably require too many structural
changes.

--
Peter Eisentraut Sernanders v_g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

************

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Jan 29 12:26:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA64206
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 12:25:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA28548;
Sat, 29 Jan 2000 12:24:19 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001291724.MAA28548@candle.pha.pa.us>
Subject: Re: [HACKERS] END/ABORT
In-Reply-To: <Pine.LNX.4.21.0001291215400.364-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 29, 2000 12:16:35 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 29 Jan 2000 12:24:19 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

On 2000-01-28, Tom Lane mentioned:

Peter Eisentraut <peter_e@gmx.net> writes:

I'd like to yank the END/ABORT commands, since they're non-standard and
redundant (COMMIT/ROLLBACK). Anyone who could not bear to see them go?

Exactly what will this accomplish, other than breaking a lot of existing
applications? (Including all of mine, which no doubt biases my thinking.)

Okay, I was just wondering. But I'm going to change all the notices and
docs to use commit and rollback instead.

Great.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Jan 29 12:28:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA64493
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 12:28:07 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA28851;
Sat, 29 Jan 2000 12:26:09 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001291726.MAA28851@candle.pha.pa.us>
Subject: Re: [HACKERS] Postgres LOGO(was: Beta is February 15th)
In-Reply-To: <Pine.LNX.4.21.0001291335080.29138-100000@fep132.fep.ru> from
Oleg
Broytmann at "Jan 29, 2000 01:44:58 pm"
To: phd2@earthling.net
Date: Sat, 29 Jan 2000 12:26:09 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

www.postgresql.org, right?

On Fri, 28 Jan 2000, Bruce Momjian wrote:

Not sure this was announced, but we are planning beta for 7.0 to start
in February 15, not February 1, as originally planned.

I am taking part in writing articles for
http://www.simplex.ru/news/koi/. It is russian weblog, similar to Slahdot.
Mostly I post announcements of different Python and Zope-related products.
But the version 7.0 will be so major change. I want to put an
announcement there, and to do this I need a logo - any small picture. Where
can I get Postgres logo?

http://www.postgresql.org/images/verh2.gif is mostly good for me. Are
there others?

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

************

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Jan 29 12:29:21 2000
Received: from thelab.hub.org (nat202.87.mpoweredpc.net [142.177.202.87])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA64620
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 12:29:04 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id NAA45202;
Sat, 29 Jan 2000 13:28:11 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 29 Jan 2000 13:28:11 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: phd2@earthling.net
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Postgres LOGO(was: Beta is February 15th)
In-Reply-To: <Pine.LNX.4.21.0001291335080.29138-100000@fep132.fep.ru>
Message-ID: <Pine.BSF.4.21.0001291326480.555-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Everything revolves around the elephant ... all the 'wearables' use the
more cartoonish logo at: http://www.pgsql.com/propaganda.html ... I know
Vince is planning on redoing the http://www.postgresql.org web site, so
I'm not sure whether he's going to continue to work with the one there, or
move towards the cartoonish one also ...

On Sat, 29 Jan 2000, Oleg Broytmann wrote:

On Fri, 28 Jan 2000, Bruce Momjian wrote:

Not sure this was announced, but we are planning beta for 7.0 to start
in February 15, not February 1, as originally planned.

I am taking part in writing articles for
http://www.simplex.ru/news/koi/. It is russian weblog, similar to Slahdot.
Mostly I post announcements of different Python and Zope-related products.
But the version 7.0 will be so major change. I want to put an
announcement there, and to do this I need a logo - any small picture. Where
can I get Postgres logo?

http://www.postgresql.org/images/verh2.gif is mostly good for me. Are
there others?

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

************

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sat Jan 29 12:39:21 2000
Received: from fep132.fep.ru (mail@fep132.fep.ru [195.230.89.88])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA69683
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 12:38:47 -0500 (EST) (envelope-from phd@phd.russ.ru)
Received: from localhost [127.0.0.1] (phd)
by fep132.fep.ru with esmtp (Exim 2.05 #1 (Debian))
id 12Ebkc-0007vR-00; Sat, 29 Jan 2000 20:33:34 +0300
Date: Sat, 29 Jan 2000 17:33:34 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Postgres LOGO(was: Beta is February 15th)
In-Reply-To: <200001291726.MAA28851@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001291729570.30449-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 29 Jan 2000, Bruce Momjian wrote:

www.postgresql.org, right?

There is no logo - there are 3 image files, so I need to combine them
into one picture by hands :(

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Sat Jan 29 12:38:21 2000
Received: from fep132.fep.ru (mail@fep132.fep.ru [195.230.89.88])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA69529
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 12:38:01 -0500 (EST) (envelope-from phd@phd.russ.ru)
Received: from localhost [127.0.0.1] (phd)
by fep132.fep.ru with esmtp (Exim 2.05 #1 (Debian))
id 12EboX-0007vl-00; Sat, 29 Jan 2000 20:37:37 +0300
Date: Sat, 29 Jan 2000 17:37:37 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: The Hermit Hacker <scrappy@hub.org>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Postgres LOGO(was: Beta is February 15th)
In-Reply-To: <Pine.BSF.4.21.0001291326480.555-100000@thelab.hub.org>
Message-ID: <Pine.LNX.4.21.0001291736400.30449-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 29 Jan 2000, The Hermit Hacker wrote:

Everything revolves around the elephant ... all the 'wearables' use the
more cartoonish logo at: http://www.pgsql.com/propaganda.html ...

http://www.pgsql.com/propaganda/powered_button.gif is very near to what
I want. Thanks.

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Sat Jan 29 12:46:21 2000
Received: from thelab.hub.org (nat202.87.mpoweredpc.net [142.177.202.87])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA71036
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 12:45:42 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id NAA45334;
Sat, 29 Jan 2000 13:45:37 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 29 Jan 2000 13:45:37 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: phd2@earthling.net
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Postgres LOGO(was: Beta is February 15th)
In-Reply-To: <Pine.LNX.4.21.0001291736400.30449-100000@fep132.fep.ru>
Message-ID: <Pine.BSF.4.21.0001291345270.555-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 29 Jan 2000, Oleg Broytmann wrote:

On Sat, 29 Jan 2000, The Hermit Hacker wrote:

Everything revolves around the elephant ... all the 'wearables' use the
more cartoonish logo at: http://www.pgsql.com/propaganda.html ...

http://www.pgsql.com/propaganda/powered_button.gif is very near to what
I want. Thanks.

*nod* no probs :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sat Jan 29 13:29:21 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA81041
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 13:28:43 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id KAA25865;
Sat, 29 Jan 2000 10:27:11 -0800 (PST)
Message-Id: <3.0.1.32.20000129101133.00ede620@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 29 Jan 2000 10:11:33 -0800
To: The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Copyright
Cc: Tom Lane <tgl@sss.pgh.pa.us>, bruc@acm.org, pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.BSF.4.21.0001291240550.555-100000@thelab.hub.org>
References: <3.0.1.32.20000128222128.00ed0b70@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:51 PM 1/29/00 -0400, The Hermit Hacker wrote:

The same thing applies to Linux ... how many different distributions and
philosophies are out there now?

Either too many, or not enough, I can never decide :)

Ummm...PostgreSQL, Inc isn't a US company...*technically*, like OpenBSD,
PostgreSQL is a Canadian Open Source Project, as its development is based
in Canada

I hadn't realized that (not that I've cared!).

... which has this neat little advantage that OpenBSD has taken
advantage of, but we haven't yet: we can add stuff like SSL encryption
directly into the source code and distribute it legally...

Sigh...it's always painful to have my country's stupidity flaunted
in public :)

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Jan 29 13:38:21 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA86176
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 13:37:26 -0500 (EST)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id VAA40987;
Sat, 29 Jan 2000 21:31:42 +0300 (MSK)
X-Real-To: pgman@candle.pha.pa.us
Received: (from dms@localhost)
by woland.wplus.net (8.9.3/8.9.1/wplus.2) id VAA07011;
Sat, 29 Jan 2000 21:36:00 +0300 (MSK)
Message-ID: <XFMail.20000129213559.dms@wplus.net>
X-Mailer: XFMail 1.4.4 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.4.21.0001291729570.30449-100000@fep132.fep.ru>
Date: Sat, 29 Jan 2000 21:35:59 +0300 (MSK)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Oleg Broytmann <phd@phd.russ.ru>
Subject: Re: [HACKERS] Postgres LOGO(was: Beta is February 15th)
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
Bruce Momjian <pgman@candle.pha.pa.us>

On 29-Jan-2000 Oleg Broytmann wrote:

On Sat, 29 Jan 2000, Bruce Momjian wrote:

www.postgresql.org, right?

There is no logo - there are 3 image files, so I need to combine them
into one picture by hands :(

I'll try to find psd source in my archive.
May be it is more convenient.

What is name of file you need for?
(Unfortunately, I miss previose discussion)

--
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

From bouncefilter Sat Jan 29 14:11:22 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id OAA95921
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 14:11:16 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 12762 invoked from network); 29 Jan 2000 19:11:02 -0000
Received: from h-62.96.159.157.host.de.colt.net (62.96.159.157)
by pille.addcom.de with SMTP; 29 Jan 2000 19:11:02 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id UAA01038
for pgsql-hackers@postgreSQL.org; Sat, 29 Jan 2000 20:02:28 +0100
Date: Sat, 29 Jan 2000 20:02:28 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Copyright
Message-ID: <20000129200228.A1009@fam-meskes.de>
Mail-Followup-To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
References: <20000128170743.A12694@rice.edu>
<Pine.BSF.4.21.0001290101540.555-100000@thelab.hub.org>
<3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>
<20000129104217.B1966@fam-meskes.de>
<389275A1.8AD0B5BC@mascari.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <389275A1.8AD0B5BC@mascari.com>;
from mascarm@mascari.com on Sat, Jan 29, 2000 at 12:07:45AM -0500

On Sat, Jan 29, 2000 at 12:07:45AM -0500, Mike Mascari wrote:

Yes, you can sell Mostgress. That's one of the problems with a BSD type
license. That's why may use GPL for there open source projects.

^^^

Should have been 'many'. :-)

Some of us view this the other way around....using anything GPL can "infect"
any product which may be putting the food on the programmer's table....What do
we care if someone else out there is making money off of, say,
"Mostgress"...good for them. Letting people do whatever the devil they want, it
seems to me, is the as free as free can get. :-)

I can understand and tolerate both reasonings. That's why I do some of my
open source work under BSD (ecpg) and other under GPL (watchdog).

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Sat Jan 29 14:18:22 2000
Received: from rage.hub.org (root@nat194.27.mpoweredpc.net [142.177.194.27])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA97241
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 14:18:11 -0500 (EST) (envelope-from jeffm@pgsql.com)
Received: from localhost (jeffm@localhost)
by rage.hub.org (8.9.3/8.9.3) with ESMTP id PAA10019;
Sat, 29 Jan 2000 15:18:14 -0400 (AST) (envelope-from jeffm@pgsql.com)
X-Authentication-Warning: rage.hub.org: jeffm owned process doing -bs
Date: Sat, 29 Jan 2000 15:15:34 -0400 (AST)
From: "Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com>
X-Sender: jeffm@rage.hub.org
Reply-To: Jeff MacDonald <jeff@pgsql.com>
To: phd2@earthling.net
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Postgres LOGO(was: Beta is February 15th)
In-Reply-To: <Pine.LNX.4.21.0001291335080.29138-100000@fep132.fep.ru>
Message-ID: <Pine.BSF.4.10.10001291514010.380-100000@rage.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

At PostgreSQL Inc we have been using the cartoon ish elephant
head , as seen on http://www.pgsql.com.

It is the image we use on the CD's, shirts, keychains, hats,
stationary, and soon to be released coffee mugs.

You can get a whole bunch of these images on
www.pgsql.com/propaganda.html

Jeff

======================================================
Jeff MacDonald
jeff@pgsql.com irc: bignose on EFnet
======================================================

On Sat, 29 Jan 2000, Oleg Broytmann wrote:

On Fri, 28 Jan 2000, Bruce Momjian wrote:

Not sure this was announced, but we are planning beta for 7.0 to start
in February 15, not February 1, as originally planned.

I am taking part in writing articles for
http://www.simplex.ru/news/koi/. It is russian weblog, similar to Slahdot.
Mostly I post announcements of different Python and Zope-related products.
But the version 7.0 will be so major change. I want to put an
announcement there, and to do this I need a logo - any small picture. Where
can I get Postgres logo?

http://www.postgresql.org/images/verh2.gif is mostly good for me. Are
there others?

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

************

From bouncefilter Sat Jan 29 14:54:22 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA07920
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 14:53:25 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id OAA29931;
Sat, 29 Jan 2000 14:53:20 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Sure enough, SI buffer overrun is broken
In-reply-to: <NDBBIJLOILGIKBGDINDFGEGFCCAA.Inoue@tpf.co.jp>
References: <NDBBIJLOILGIKBGDINDFGEGFCCAA.Inoue@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Fri, 28 Jan 2000 00:38:20 +0900"
Date: Sat, 29 Jan 2000 14:53:19 -0500
Message-ID: <29928.949175599@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

I built the current sources with MAXNUMMESSAGES set to 32 in
src/include/storage/sinvaladt.h. The regular regress tests
run OK, with just a few NOTICEs about 'cache state reset'
and 'SI buffer overflow' inserted in the normal outputs
(as you'd expect, if SI overrun occurs).

However, the parallel tests crash spectacularly, with weird errors
and Assert() coredumps.

Is the call RelationCacheInvalidate(false not true) in ResetSys-
temCaches() right ? Relation descriptors would be destoryed if
ResetSystemCaches() occurs in CommandConterIncrement().

You are absolutely right. I have thought before that it was extremely
dangerous for RelationCacheInvalidate *ever* to blow away a relcache
entry with a positive refcount. I have changed ResetSystemCaches to
pass TRUE, and have modified the comments for RelationCacheInvalidate
to indicate that this is probably the only safe setting. I also changed
RelationIdInvalidateRelationCacheByRelationId to unconditionally pass
true to RelationFlushRelation. Now, RelationFlushRelation is *never*
called with onlyFlushReferenceCountZero=false, so it will always attempt
to rebuild a relcache entry that has positive refcount.

I suspect that the "feature" of RelationFlushRelation to allow blowing
away a relcache entry regardless of refcount was a hack put in back when
relcache refcounts couldn't be trusted (because elog(ERROR) would leave
refcounts positive). Now we have RelationCacheAbort to fix refcounts
after elog, so I see no reason to take the risk of trying to destroy an
open relcache entry.

With these two changes in place, the parallel regress tests seem much
more stable. There is still a big problem though, which is that the
"portals" regress test sometimes fails. I traced this far enough to
discover that the code is trying to use a TupleDesc that it's stored in
the ScanTupleSlot of a plan, and this TupleDesc is no longer valid ---
presumably the relcache entry it was gotten from has been flushed and
rebuilt, leaving the plan with a dangling TupleDesc pointer. Ugh.

I do not think it is very practical to try to change all of the places
that assume that they can save pointers to the TupleDesc of a relcache
entry. Instead I am thinking about solving the problem inside the
relcache, as follows:

During a relcache entry rebuild, do not simply free and reconstruct
the TupleDesc. Instead, read the catalogs to build a new TupleDesc,
and compare this one to the old one. If they are the same, free the
new one instead (leaving the old one in place, and hence stored pointers
to it are still valid). If they are not the same, then elog(ERROR).

(elog may sound overly paranoid, but this condition indicates that the
table's definition has actually changed since we grabbed the refcount on
it --- remember we wouldn't be doing this at all if the relcache entry had
zero refcount --- and therefore all kinds of derived information such as
plans may be wrong. Pressing ahead will probably lead to crash.)

We may need to do the same for any other substructures of the relcache
entry that are visible from outside relcache.c.

I know this sounds pretty grotty, but we are already doing it for the
relcache entry itself --- rebuild re-uses the same physical entry
rather than deleting and reallocating it, to ensure that pointers
to an open Relation stay valid over an SI flush. We need to extend
the same guarantee to the substructure of the relcache entry.

Unless someone has a better idea, I'll work on that.

Some of the unexpected messages in the
postmaster log are:

NOTICE: LockRelease: locktable lookup failed, no lock

I have seen this NOTICE only once or twice.
This seems because of setting MyProc->xid to InvalidTransa
ctionId in CommitTransaction() and AbortTransaction().
There's a little time until AtCommit(Abort)_Locks.
I have no idea to solve this now.

I am not seeing it after the change to never flush relcaches with
positive refcount. I think the locks being complained of are
probably the locks that should have been kept on flushed relations,
and that it's not CommitTransaction's fault.

regards, tom lane

From bouncefilter Sat Jan 29 15:05:22 2000
Received: from hu.tm.ee (ppp835.tele2.ee [212.107.37.135])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA13366
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 15:04:32 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 1E417135D1; Sat, 29 Jan 2000 22:11:03 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38934956.73530456@tm.ee>
Date: Sat, 29 Jan 2000 22:11:02 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: Philip Warner <pjw@rhyme.com.au>, The Hermit Hacker <scrappy@hub.org>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Copyright
References: <20000128170743.A12694@rice.edu>
<3.0.5.32.20000129163155.03787100@mail.rhyme.com.au>
<38929086.8B961E91@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

This depends on the definition of open source; I think Netscape is
OpenSource these days, but I doubt if anyone would be allowed to take the
sources and create "Petscape: The Dog's Browser". But, as far as I know, I
could go away tomorrow with the PostgreSQL sources and create "Mostgress",
so long as I did not try to sell it. AFAIK, I might even get away with
selling it, but it's not really the point.

Yes you could. The original Postgres developers (or at least some of
them) did just that in founding Illustra. They sold the company a
couple of years later for $50M US to Informix.

Actually Postgres was _not_ distributed under the BSD (do-whatever-you-want
but
give credit) license but a much more restrictive license that required a
special
permission from UBC to to anything non-educational.

IIRC Stonebraker et al founded Illustra after getting special permissions from
UCB

The shift to BSD license (that enabled the current blooming of PostgreSQL ;)
was oftained sometime during the development of postgres 95, with some
considerable backing from Stonebraker.

-------------
Hannu

From bouncefilter Sat Jan 29 15:41:24 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA22191
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 15:40:52 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id PAA00197;
Sat, 29 Jan 2000 15:40:35 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
Cc: pgsql-hackers@postgreSQL.org
Subject: ImmediateSharedRelationCacheInvalidate considered harmful
Date: Sat, 29 Jan 2000 15:40:35 -0500
Message-ID: <194.949178435@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Hiroshi,
I have been looking at the cache invalidation changes you committed
on 10 Jan. Most of them look fine, but I am suspicious of the routine
ImmediateSharedRelationCacheInvalidate, which you added for md.c to
call when it truncates or removes a relation. I believe that this
routine is unnecessary, and since it makes for a very ugly linkage
between md.c and the cache code, I would like to take it out again.

I think it is unnecessary because no backend should ever be deleting
or truncating a relation unless it has an exclusive lock on the
relation.  It should be impossible for any other backend to try to
touch the relation until it's acquired some kind of lock on the relation
--- which cannot happen until the deleting/truncating transaction
commits, by which time it will have sent the normal SI message for the
relation's pg_class tuple.  And since LockRelation processes SI messages
after acquiring the relation's lock, the other backend should have seen
the SI update before it can do anything with the relation.

Of course, the other backend may have open file descriptors for the
relation's file(s), but so what? The descriptors will get closed when
the SI message is processed, before they can be used for anything; so
the only consequence is that the Unix kernel won't release the physical
file storage until then.

Furthermore, if it *were* necessary to force other backends to react
immediately to md.c's truncation or deletion, the SI message mechanism
will not do the trick, even if a message is sent instantly; there is
no guarantee that other backends will process it promptly.

So I can see no value in this code. Have I missed something?

regards, tom lane

From bouncefilter Sat Jan 29 15:41:23 2000
Received: from thelab.hub.org (nat202.87.mpoweredpc.net [142.177.202.87])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA22240
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 15:41:05 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA46512;
Sat, 29 Jan 2000 16:40:48 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 29 Jan 2000 16:40:48 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, bruc@acm.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Copyright
In-Reply-To: <3.0.1.32.20000129101133.00ede620@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001291638210.555-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 29 Jan 2000, Don Baccus wrote:

At 12:51 PM 1/29/00 -0400, The Hermit Hacker wrote:

The same thing applies to Linux ... how many different distributions and
philosophies are out there now?

Either too many, or not enough, I can never decide :)

Ummm...PostgreSQL, Inc isn't a US company...*technically*, like OpenBSD,
PostgreSQL is a Canadian Open Source Project, as its development is based
in Canada

I hadn't realized that (not that I've cared!).

... which has this neat little advantage that OpenBSD has taken
advantage of, but we haven't yet: we can add stuff like SSL encryption
directly into the source code and distribute it legally...

Sigh...it's always painful to have my country's stupidity flaunted
in public :)

When those laws were created, there was a reason for them ... in this day
and age, there isn't, but, unfortunately, I think its easier to put *in* a
law then it is to repeal it, no? :( Give it time ... just thank god for
loopholes :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sat Jan 29 15:47:23 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA23082
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 15:46:54 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA05457;
Sat, 29 Jan 2000 15:41:38 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001292041.PAA05457@candle.pha.pa.us>
Subject: Re: [HACKERS] Copyright
In-Reply-To: <38934956.73530456@tm.ee> from Hannu Krosing at "Jan 29,
2000 10:11:02 pm"
To: Hannu Krosing <hannu@tm.ee>
Date: Sat, 29 Jan 2000 15:41:38 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Philip Warner <pjw@rhyme.com.au>, The Hermit Hacker <scrappy@hub.org>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

This depends on the definition of open source; I think Netscape is
OpenSource these days, but I doubt if anyone would be allowed to take the
sources and create "Petscape: The Dog's Browser". But, as far as I know, I
could go away tomorrow with the PostgreSQL sources and create "Mostgress",
so long as I did not try to sell it. AFAIK, I might even get away with
selling it, but it's not really the point.

Yes you could. The original Postgres developers (or at least some of
them) did just that in founding Illustra. They sold the company a
couple of years later for $50M US to Informix.

Actually Postgres was _not_ distributed under the BSD (do-whatever-you-want
but
give credit) license but a much more restrictive license that required a
special
permission from UBC to to anything non-educational.

IIRC Stonebraker et al founded Illustra after getting special permissions from
UCB

The shift to BSD license (that enabled the current blooming of PostgreSQL ;)
was oftained sometime during the development of postgres 95, with some
considerable backing from Stonebraker.

Well, that's interesting.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Jan 29 17:52:25 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA52610
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 17:51:36 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA00740
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 17:51:28 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: freefuncs.c is never called from anywhere!?
Date: Sat, 29 Jan 2000 17:51:27 -0500
Message-ID: <737.949186287@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I was rather bemused to discover just now that the node-freeing
functions in nodes/freefuncs.c are never called from anywhere;
in fact, the module hasn't got a single exported entry point!

(I expect that freeObject() is supposed to be an external entry
point; perhaps it got demoted to a static during one of Bruce's
periodic get-rid-of-unreferenced-global-symbols passes.)

So much for all that tedious labor to maintain the freeXXX functions
every time we update a node type ;-)

Now I am not quite sure what to do. I was intending to use freeObject
to clean up rule qual/action trees during relcache flush --- up to now,
that cache data has been permanently leaked by any relcache flush
affecting a relation with rules. But if freefuncs.c hasn't actually
been used in a long time, it may well be suffering serious bit-rot.
I am worried about turning it on just before beta. I am especially
worried about turning it on for use only in a seldom-taken code path ---
if there are bugs in it, we may not find them until after release.

Should I chicken out and let the memory leak persist until we start
7.1 development cycle? Or go for it and hope the code's OK?

regards, tom lane

From bouncefilter Sat Jan 29 19:22:26 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA87109
for <pgsql-hackers@postgresql.org>;
Sat, 29 Jan 2000 19:22:04 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12Ei7n-000LEMC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Sat, 29 Jan 2000 18:21:55 -0600 (CST)
Date: Sat, 29 Jan 2000 18:21:55 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Don Baccus <dhogaza@pacifier.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, bruc@acm.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: Copyright
Message-ID: <20000129182155.A14612@rice.edu>
References: <3.0.1.32.20000128222128.00ed0b70@mail.pacifier.com>
<200001290245.VAA15243@stone.congenomics.com>
<200001290245.VAA15243@stone.congenomics.com>
<3.0.1.32.20000128222128.00ed0b70@mail.pacifier.com>
<14004.949129822@sss.pgh.pa.us>
<3.0.1.32.20000129070734.0103b5b0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <3.0.1.32.20000129070734.0103b5b0@mail.pacifier.com>;
from dhogaza@pacifier.com on Sat, Jan 29, 2000 at 07:07:34AM -0800

On Sat, Jan 29, 2000 at 07:07:34AM -0800, Don Baccus wrote:

At 02:10 AM 1/29/00 -0500, Tom Lane wrote:

If anyone wants to look into Apache and see how it's set up, I've got no
problem with taking a look. I think it's real easy to make a mountain
out of a molehill in this area, however. Look at FSF --- they actually
require signed paperwork (hard copy, not email) from any potential
contributor before they will accept code contributions. Do we want to
get that anal-retentive? I hope not.

Yes, in spirit I'm certainly with you on this one. I presume some
laywer started hacking code in his spare time then started hacking
the FSF as well :)

Nah, I think it's more like how the rules are always more strict for
first born children: parents don't want to make a mistake, and don't
know what might _be_ a mistake, so set early curfews, etc. Once some more
kids come along (read Free Software projects) they start to loosen up...

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Sat Feb 5 13:20:08 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA20018;
Sat, 5 Feb 2000 13:19:11 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id NAA23604;
Sat, 5 Feb 2000 13:16:46 -0500 (EST) (envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: mp3_exchanger@hotmail.com
X-Newsgroups: comp.databases.orcale.marketplace, comp.databases.paradox,
comp.databases.pick, comp.databases.postgresql.hackers,
comp.databases.postgresql.questions
Subject: MP3Exchanger v1.13 New Internet utility. Use to exchange and locate
binaries of any file format.
Lines: 13
Message-ID: <CnNk4.17344$l82.231088@news20.bellglobal.com>
Date: Sun, 30 Jan 2000 02:30:58 GMT
X-Trace: news20.bellglobal.com 949199458 216.209.61.188 (Sat,
29 Jan 2000 21:30:58 EST)
Organization: Sympatico
To: pgsql-hackers@postgresql.org, pgsql-questions@postgresql.org

ftp://mp3exchanger.dynip.com/mp3exchanger.exe

By downloading and using, you can:

1) Exchange any files with other users anywhere in the world.
2) Simultaneously download and upload up to 32,000 files!!!
3) See all on-line users.
4) By clicking on on-line users, you can see the list of files they have to offer.
5) Access the search engine and search all files users, currently on-line, have to offer in a blink of an eye.
6) Share your files with other users by selecting so.
7) ENJOY THE 100% GUARANTEED DELIVERY. If you see something you like, double click on it and it starts to download.
8) Chat other users. Join chat rooms or create your own.

From bouncefilter Sat Jan 29 22:15:30 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA30017
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 22:15:27 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm256.noc.fukui.nsk.ne.jp [210.161.188.131])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id MAA08923; Sun, 30 Jan 2000 12:13:54 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: ImmediateSharedRelationCacheInvalidate considered harmful
Date: Sun, 30 Jan 2000 12:14:53 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFIEIECCAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <194.949178435@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]

Hiroshi,
I have been looking at the cache invalidation changes you committed
on 10 Jan. Most of them look fine, but I am suspicious of the routine
ImmediateSharedRelationCacheInvalidate, which you added for md.c to
call when it truncates or removes a relation. I believe that this
routine is unnecessary, and since it makes for a very ugly linkage
between md.c and the cache code, I would like to take it out again.

I'm happy you have noticed it.

The call is for abort/crash after mdunlink()/mdtruncate().
mdunlink()/mdtruncate() is executed immediately but
SI registration for all backends isn't executed until commit.
Yes the call is ugly and it doesn't solve the flaw basically.
Transaction control of relation files' handling would solve
it basically. Though I have hesitated to add the call,after
all I added it because it may be brought to developers' notice.
I don't mind to take it out

BTW strictly speaking,even a possibilty exists that backends
fail between RecordTransactionCommit() and AtCommit_Cache()
in CommitTransaction(). This isn't so little a problem if we want
a really strict consistency but seems very hard to solve.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sat Jan 29 22:16:28 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA30037
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 22:15:30 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm256.noc.fukui.nsk.ne.jp [210.161.188.131])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id MAA08924; Sun, 30 Jan 2000 12:13:56 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Sure enough, SI buffer overrun is broken
Date: Sun, 30 Jan 2000 12:14:55 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFKEIECCAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <29928.949175599@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

I built the current sources with MAXNUMMESSAGES set to 32 in
src/include/storage/sinvaladt.h. The regular regress tests
run OK, with just a few NOTICEs about 'cache state reset'
and 'SI buffer overflow' inserted in the normal outputs
(as you'd expect, if SI overrun occurs).

However, the parallel tests crash spectacularly, with weird errors
and Assert() coredumps.

With these two changes in place, the parallel regress tests seem much
more stable. There is still a big problem though, which is that the
"portals" regress test sometimes fails. I traced this far enough to
discover that the code is trying to use a TupleDesc that it's stored in
the ScanTupleSlot of a plan, and this TupleDesc is no longer valid ---
presumably the relcache entry it was gotten from has been flushed and
rebuilt, leaving the plan with a dangling TupleDesc pointer. Ugh.

Oh great,I've also doubted relcache entry rebuild but wasn't able to
trace so far.

I do not think it is very practical to try to change all of the places
that assume that they can save pointers to the TupleDesc of a relcache
entry. Instead I am thinking about solving the problem inside the
relcache, as follows:

During a relcache entry rebuild, do not simply free and reconstruct
the TupleDesc. Instead, read the catalogs to build a new TupleDesc,
and compare this one to the old one. If they are the same, free the
new one instead (leaving the old one in place, and hence stored pointers
to it are still valid). If they are not the same, then elog(ERROR).

(elog may sound overly paranoid, but this condition indicates that the
table's definition has actually changed since we grabbed the refcount on
it --- remember we wouldn't be doing this at all if the relcache entry had
zero refcount --- and therefore all kinds of derived information such as
plans may be wrong. Pressing ahead will probably lead to crash.)

Sounds reasonable.

We may need to do the same for any other substructures of the relcache
entry that are visible from outside relcache.c.

I know this sounds pretty grotty, but we are already doing it for the
relcache entry itself --- rebuild re-uses the same physical entry
rather than deleting and reallocating it, to ensure that pointers
to an open Relation stay valid over an SI flush. We need to extend
the same guarantee to the substructure of the relcache entry.

Unless someone has a better idea, I'll work on that.

Agreed.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sat Jan 29 22:19:27 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA30446
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 22:19:12 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA18832;
Sat, 29 Jan 2000 22:18:09 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001300318.WAA18832@candle.pha.pa.us>
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <737.949186287@sss.pgh.pa.us> from Tom Lane at "Jan 29,
2000 05:51:27 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 29 Jan 2000 22:18:09 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I was rather bemused to discover just now that the node-freeing
functions in nodes/freefuncs.c are never called from anywhere;
in fact, the module hasn't got a single exported entry point!

(I expect that freeObject() is supposed to be an external entry
point; perhaps it got demoted to a static during one of Bruce's
periodic get-rid-of-unreferenced-global-symbols passes.)

So much for all that tedious labor to maintain the freeXXX functions
every time we update a node type ;-)

Are you sure about this? I thought these things were called from
macros.

However, I can't find any macro that uses this like makeNode does with
its pasteing. I would perhaps move it to a _deadcode directory and see
what happens. Or should we enable it?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Jan 29 22:50:28 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA37890
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 22:49:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA13789;
Sat, 29 Jan 2000 22:49:19 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-reply-to: <200001300318.WAA18832@candle.pha.pa.us>
References: <200001300318.WAA18832@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sat, 29 Jan 2000 22:18:09 -0500"
Date: Sat, 29 Jan 2000 22:49:19 -0500
Message-ID: <13786.949204159@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I was rather bemused to discover just now that the node-freeing
functions in nodes/freefuncs.c are never called from anywhere;
in fact, the module hasn't got a single exported entry point!

Are you sure about this? I thought these things were called from
macros.

nm --defined --extern shows that freefuncs.o exports no symbols.
Therefore it's impossible for any outside code to refer to it.
(Hmm, I wonder if any other modules are equally dead?)

I would perhaps move it to a _deadcode directory and see
what happens. Or should we enable it?

I certainly don't want to bit-bucket it --- I was just very surprised
that it's not currently being used.

After further consideration I realized that if RelationClearRelation
uses freeObject() to flush rules, then a DROP on a view will exercise
the code. So it's not quite as hard to test as I was thinking before.
I'm leaning towards the "go for it" answer at the moment...

regards, tom lane

From bouncefilter Sat Jan 29 23:19:28 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA45561
for <pgsql-hackers@postgreSQL.org>;
Sat, 29 Jan 2000 23:18:43 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA13858;
Sat, 29 Jan 2000 23:18:38 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: ImmediateSharedRelationCacheInvalidate considered harmful
In-reply-to: <NDBBIJLOILGIKBGDINDFIEIECCAA.Inoue@tpf.co.jp>
References: <NDBBIJLOILGIKBGDINDFIEIECCAA.Inoue@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Sun, 30 Jan 2000 12:14:53 +0900"
Date: Sat, 29 Jan 2000 23:18:38 -0500
Message-ID: <13855.949205918@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

I have been looking at the cache invalidation changes you committed
on 10 Jan. Most of them look fine, but I am suspicious of the routine
ImmediateSharedRelationCacheInvalidate, which you added for md.c to
call when it truncates or removes a relation. I believe that this
routine is unnecessary, and since it makes for a very ugly linkage
between md.c and the cache code, I would like to take it out again.

The call is for abort/crash after mdunlink()/mdtruncate().
mdunlink()/mdtruncate() is executed immediately but
SI registration for all backends isn't executed until commit.
Yes the call is ugly and it doesn't solve the flaw basically.

Right. As the code currently stands, we are up the creek with no
paddle if an abort occurs after mdunlink/mdtruncate. The only real
solution is to postpone these operations until after commit, which
can only be done if we change the naming convention for relation files.
I think we are drifting towards a consensus that that has to be done.

So the question is, does ImmediateSharedRelationCacheInvalidate add
any useful amount of (incomplete) robustness in the meantime?
I'm not sure --- but since it's not a step towards a real solution,
I'm inclined to leave it out.

Just my $0.02 worth; if you think it's better to leave it in until
we have a complete solution, I will go along.

BTW strictly speaking,even a possibilty exists that backends
fail between RecordTransactionCommit() and AtCommit_Cache()
in CommitTransaction(). This isn't so little a problem if we want
a really strict consistency but seems very hard to solve.

Hmm, haven't looked at that...

regards, tom lane

From bouncefilter Sun Jan 30 01:04:29 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA71757
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 01:04:21 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm237.noc.fukui.nsk.ne.jp [210.161.188.112])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id PAA08956; Sun, 30 Jan 2000 15:04:13 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] freefuncs.c is never called from anywhere!?
Date: Sun, 30 Jan 2000 15:05:13 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFIEIGCCAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <737.949186287@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane

I was rather bemused to discover just now that the node-freeing
functions in nodes/freefuncs.c are never called from anywhere;
in fact, the module hasn't got a single exported entry point!

(I expect that freeObject() is supposed to be an external entry
point; perhaps it got demoted to a static during one of Bruce's
periodic get-rid-of-unreferenced-global-symbols passes.)

So much for all that tedious labor to maintain the freeXXX functions
every time we update a node type ;-)

As far as I see,freeObject() has a fundamental problem.
Probably it couldn't free multiple references safely.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Jan 30 01:33:29 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA82782
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 01:33:12 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA18904;
Sun, 30 Jan 2000 01:32:52 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-reply-to: <NDBBIJLOILGIKBGDINDFIEIGCCAA.Inoue@tpf.co.jp>
References: <NDBBIJLOILGIKBGDINDFIEIGCCAA.Inoue@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Sun, 30 Jan 2000 15:05:13 +0900"
Date: Sun, 30 Jan 2000 01:32:51 -0500
Message-ID: <18901.949213971@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

As far as I see,freeObject() has a fundamental problem.
Probably it couldn't free multiple references safely.

Yes, that code will have a problem with node trees that have
circular references or multiple links to the same node.
Both of which are cases that we can currently generate :-(.

Of course, circular links will also break copyfuncs, equalfuncs,
and printfuncs. We have a known bug with the backend crashing
when -d is enabled for certain queries, because of infinite
recursion in printfuncs.

For the moment, the only thing I need the freefuncs code for is
to free nodetrees that have been created by stringToNode. AFAICT
that routine is incapable of creating circular links or multiple
links, so it should work.

Eventually it would be nice to have a better solution.

regards, tom lane

From bouncefilter Sun Jan 30 09:44:35 2000
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA96519
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 09:44:16 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.8/MAPS) with ESMTP
id QAA08640; Sun, 30 Jan 2000 16:44:04 +0200 (EET)
Sender: a.joubert@albourne.com
Message-ID: <38944E06.DA17AE62@albourne.com>
Date: Sun, 30 Jan 2000 14:43:18 +0000
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Postgresql <pgsql-hackers@postgreSQL.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Bit strings
References: <3891D54C.E0004C05@albourne.com>
<38929158.F84EAB80@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

If the code works or can be made workable we should integrate it imho.
There is not likely to be any good excuse to keep out an
SQL92-compliant type.

Nobody else replied, so I guess we can go ahead. Let me know if there is
anything I can do, or you need any explanations to the code, etc.

Adriaan

From bouncefilter Sun Jan 30 10:41:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA09315
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 10:41:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA22888
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 10:41:13 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Another nasty cache problem
Date: Sun, 30 Jan 2000 10:41:13 -0500
Message-ID: <22885.949246873@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I'm down to the point where the parallel tests mostly work with a small
SI buffer --- but they do still sometimes fail. I've realized that
there is a whole class of bugs along the following lines:

There are plenty of routines that do two or more SearchSysCacheTuple
calls to get the information they need. As the code stands, it is
unsafe to continue accessing the tuple returned by SearchSysCacheTuple
after making a second such call, because the second call could possibly
cause an SI cache reset message to be processed, thereby flushing the
contents of the caches.

heap_open and CommandCounterIncrement are other routines that could
cause cache entries to be dropped.

This is a very insidious kind of bug because the probability of
occurrence is very low (at normal SI buffer size a reset is unlikely,
and even if it happens, you won't observe a failure unless the
pfree'd tuple is actually overwritten before you're done with it).
So we cannot hope to catch these things by testing.

I am not sure what to do about it. One solution path is to make
all the potential trouble spots do SearchSysCacheTupleCopy and then
pfree the copied tuple when done. However, that adds a nontrivial
amount of overhead, and it'd be awfully easy to miss some trouble
spots or to introduce new ones in the future.

Another possibility is to introduce some sort of notion of a reference
count, and to make the standard usage pattern be
tuple = SearchSysCacheTuple(...);
... use tuple ...
ReleaseSysCacheTuple(tuple);
The idea here is that a tuple with positive refcount would not be
deleted during a cache reset, but would simply be removed from its
cache, and then finally deleted when released (or during elog
recovery).

This might allow us to get rid of SearchSysCacheTupleCopy, too,
since the refcount should be just as good as palloc'ing one's own
copy for most purposes.

I haven't looked at the callers of SearchSysCacheTuple to see whether
this would be a practical change to make. I was wondering if anyone
had any comments or better ideas...

regards, tom lane

From bouncefilter Sun Jan 30 13:00:38 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA37825
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 12:59:48 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA12393;
Sun, 30 Jan 2000 12:57:58 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001301757.MAA12393@candle.pha.pa.us>
Subject: Re: [HACKERS] Another nasty cache problem
In-Reply-To: <22885.949246873@sss.pgh.pa.us> from Tom Lane at "Jan 30,
2000 10:41:13 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 30 Jan 2000 12:57:58 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I'm down to the point where the parallel tests mostly work with a small
SI buffer --- but they do still sometimes fail. I've realized that
there is a whole class of bugs along the following lines:

There are plenty of routines that do two or more SearchSysCacheTuple
calls to get the information they need. As the code stands, it is
unsafe to continue accessing the tuple returned by SearchSysCacheTuple
after making a second such call, because the second call could possibly
cause an SI cache reset message to be processed, thereby flushing the
contents of the caches.

Yes, I have always been aware of this problem. The issue is that since
cache entries are removed on a oldest-removed-first basis, I never
thought that several cache lookups would be a problem. If you do many
cache lookups and expect very old ones to still exist, that could be a
problem.

However, a full reset of the cache could cause major problems. Is there
a way to re-load the cache after the reset with the most recently cached
entries? Seems that would be easier. However, your issue is probably
that the new cache entries would have different locations from the old
entries. Is it possible to delay the cache reset of the five most
recent cache entries, and do them later? I don't see many places where
more than 2-3 cache entries are kept. Maybe we need to keep them around
somehow during cache reset.

I am not sure what to do about it. One solution path is to make
all the potential trouble spots do SearchSysCacheTupleCopy and then
pfree the copied tuple when done. However, that adds a nontrivial
amount of overhead, and it'd be awfully easy to miss some trouble
spots or to introduce new ones in the future.

Sounds like a lot of overhead to do the copy.

Another possibility is to introduce some sort of notion of a reference
count, and to make the standard usage pattern be
tuple = SearchSysCacheTuple(...);
... use tuple ...
ReleaseSysCacheTuple(tuple);
The idea here is that a tuple with positive refcount would not be
deleted during a cache reset, but would simply be removed from its
cache, and then finally deleted when released (or during elog
recovery).

If you can do that, can't you just keep the few most recent ones by
default. Seems that would be very clean.

This might allow us to get rid of SearchSysCacheTupleCopy, too,
since the refcount should be just as good as palloc'ing one's own
copy for most purposes.

Yes, that would be nice.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Jan 30 13:22:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA55561
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 13:22:14 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA29895;
Sun, 30 Jan 2000 13:22:05 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <200001301757.MAA12393@candle.pha.pa.us>
References: <200001301757.MAA12393@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 30 Jan 2000 12:57:58 -0500"
Date: Sun, 30 Jan 2000 13:22:05 -0500
Message-ID: <29892.949256525@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Yes, I have always been aware of this problem. The issue is that since
cache entries are removed on a oldest-removed-first basis, I never
thought that several cache lookups would be a problem.

They're not, under normal circumstances...

However, a full reset of the cache could cause major problems. Is there
a way to re-load the cache after the reset with the most recently cached
entries? Seems that would be easier. However, your issue is probably
that the new cache entries would have different locations from the old
entries. Is it possible to delay the cache reset of the five most
recent cache entries, and do them later?

I don't think that's a good answer; what if one of those entries is the
one that the SI messages wanted us to update? With a scheme like that,
you might be protecting a cache entry that actually isn't being used
anymore. With a refcount you'd at least know whether it was safe to
throw the entry away.

Of course this just begs the question of what to do when an SI update
message arrives for a tuple that is locked down by refcount. Maybe
we have to kick out an elog(ERROR) then. Could be messy.

regards, tom lane

From bouncefilter Sun Jan 30 14:30:39 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA70720
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 14:29:50 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA13522;
Sun, 30 Jan 2000 14:25:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001301925.OAA13522@candle.pha.pa.us>
Subject: Re: [HACKERS] Another nasty cache problem
In-Reply-To: <29892.949256525@sss.pgh.pa.us> from Tom Lane at "Jan 30,
2000 01:22:05 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 30 Jan 2000 14:25:29 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Yes, I have always been aware of this problem. The issue is that since
cache entries are removed on a oldest-removed-first basis, I never
thought that several cache lookups would be a problem.

They're not, under normal circumstances...

However, a full reset of the cache could cause major problems. Is there
a way to re-load the cache after the reset with the most recently cached
entries? Seems that would be easier. However, your issue is probably
that the new cache entries would have different locations from the old
entries. Is it possible to delay the cache reset of the five most
recent cache entries, and do them later?

I don't think that's a good answer; what if one of those entries is the
one that the SI messages wanted us to update? With a scheme like that,
you might be protecting a cache entry that actually isn't being used
anymore. With a refcount you'd at least know whether it was safe to
throw the entry away.

Of course this just begs the question of what to do when an SI update
message arrives for a tuple that is locked down by refcount. Maybe
we have to kick out an elog(ERROR) then. Could be messy.

Yep, that was my question. You can re-load it, but if it is the one
that just got invalidated, what do you reload? My guess is that you
keep using the same cache entry until the current transaction finishes,
at which point you can throw it away.

Now, if we did proper locking, no SI message could arrive for such an
entry.

My assumption is that these are mostly system cache entries, and they
rarely change, right? If someone is operating on a table that gets an
SI entry, odds are that later on the system will fail because the table
is changed in some way, right?

Actually, don't we have a transaction id for the transaction that loaded
that cache entry. We can add a transaction id to the cache record that
shows the transaction that last accessed that cache entry. Then we can
say if any SI message comes in for a cache entry that was accessed by
the current transaction, we throw an elog.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Jan 30 15:59:40 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA91781
for <pgsql-hackers@postgresql.org>;
Sun, 30 Jan 2000 15:59:23 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id PAA73523
for pgsql-hackers@postgresql.org; Sun, 30 Jan 2000 15:43:04 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "jo" <hotcd@gmx.net>
X-Newsgroups: comp.databases.postgresql.hackers
Subject: corel9
Date: Sun, 30 Jan 2000 21:29:45 +0100
Lines: 3
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID: <38949f40@news.restena.lu>
X-Trace: 30 Jan 2000 21:29:52 +0100, ppp-101-239.restena.lu
To: pgsql-hackers@postgresql.org

anyone got a crack or password for corel9

From bouncefilter Sun Jan 30 16:54:40 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA18330
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 16:54:28 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id QAA26594;
Sun, 30 Jan 2000 16:54:14 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <200001301925.OAA13522@candle.pha.pa.us>
References: <200001301925.OAA13522@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 30 Jan 2000 14:25:29 -0500"
Date: Sun, 30 Jan 2000 16:54:14 -0500
Message-ID: <26591.949269254@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Now, if we did proper locking, no SI message could arrive for such an
entry.

My assumption is that these are mostly system cache entries, and they
rarely change, right? If someone is operating on a table that gets an
SI entry, odds are that later on the system will fail because the table
is changed in some way, right?

If the tuple is actually *changed* then that's true (and locking should
have prevented it anyway). But we also issue cache flushes against
whole system tables in order to handle VACUUM of a system table. There,
the only thing that's actually been modified is the tuple's physical
location (ctid). We don't want to blow away transactions that are just
looking at cache entries when a VACUUM happens.

Perhaps the caches shouldn't store ctid? Not sure.

regards, tom lane

From bouncefilter Sun Jan 30 16:57:42 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA18605
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 16:57:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA19093;
Sun, 30 Jan 2000 16:56:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001302156.QAA19093@candle.pha.pa.us>
Subject: Re: [HACKERS] Another nasty cache problem
In-Reply-To: <26591.949269254@sss.pgh.pa.us> from Tom Lane at "Jan 30,
2000 04:54:14 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 30 Jan 2000 16:56:14 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Now, if we did proper locking, no SI message could arrive for such an
entry.

My assumption is that these are mostly system cache entries, and they
rarely change, right? If someone is operating on a table that gets an
SI entry, odds are that later on the system will fail because the table
is changed in some way, right?

If the tuple is actually *changed* then that's true (and locking should
have prevented it anyway). But we also issue cache flushes against
whole system tables in order to handle VACUUM of a system table. There,
the only thing that's actually been modified is the tuple's physical
location (ctid). We don't want to blow away transactions that are just
looking at cache entries when a VACUUM happens.

Perhaps the caches shouldn't store ctid? Not sure.

I am guilt of that. There are a few place where I grab the tuple from
the cache, then use that to update the heap. I thought it was a nifty
solution at the time. I thought I used the CacheCopy calls for that,
but I am not positive. Even if I did, that doesn't help because the
copy probably has an invalid tid at that point, thought I have opened
the table. Maybe I have to make sure I open the table before geting the
tid from the cache.

Is it only the tid that is of concern. If so, that can probably be
fixed somehow.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Jan 30 17:02:41 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA22875
for <pgsql-general@postgresql.org>;
Sun, 30 Jan 2000 17:01:56 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sun, 30 Jan 2000 15:52:17 -0600
Sender: ed
Message-ID: <3894B51F.A9D35D2D@austin.rr.com>
Date: Sun, 30 Jan 2000 16:03:11 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pg-gen <pgsql-general@postgresql.org>
Subject: [GENERAL] float4 confused as int??
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Can someone enlighten me why this error is occurring in which a float
value is apparently being interpreted as an integer? Known
workarounds??

emsdb=>   UPDATE contract_activity_type SET duration = 3.5, updater_id
= 1, last_update = now() WHERE id = 72;  
] ERROR:  pg_atoi: error in "3.5": can't parse ".5"
emsdb=> \d contract_activity_type
Table    = contract_activity_type
+----------------------------------+----------------------------------+-------+
|              Field               |              Type               
| Length|
+----------------------------------+----------------------------------+-------+
| id                               | int4 not null default nextval ( 
|     4 |
| contract_id                      | int4 not null                   
|     4 |
| activity_type_id                 | int4 not null                   
|     4 |
| travel_required                  | int4 not null                   
|     4 |
| billable                         | int4 not null                   
|     4 |
| duration                         | float4 not null                 
|     4 |

Thanks in advance.

Cheers,
Ed Loehr

From bouncefilter Sun Jan 30 17:24:41 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA35247
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 17:24:32 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <D7S3WTKW>; Mon, 31 Jan 2000 00:20:47 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C4C1@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Tom Lane '" <tgl@sss.pgh.pa.us>,
"'The Hermit Hacker '" <scrappy@hub.org>
Cc: "'Chris Bitmead '" <chris@bitmead.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Re: ORDBMS
Date: Mon, 31 Jan 2000 00:09:58 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

The Hermit Hacker <scrappy@hub.org> writes:
What I don't understand yet is whether the contents of table
"address" have any connection to the data stored in table "person".
If not, why must I create a table in order to define a datatype?

Seems

like a separate CREATE DATATYPE command would make more sense...

Not quite an answer to your question, but my guess is that 'address
ADDRESS' would contain a pointer (OID) to the address table ... so >>

the

person table would be realtively small in comparison to the address

table

...
The way I look at the above, its a 'JOIN' at table create time, based

on a

unique value, the OID ...

Hmm. OK, that makes sense, because I know I've seen places in the code
that think that any "set type" is represented as an OID. I never
understood what that was all about, but in this context that would be
what would happen. Assuming that this facility is the same as what
the code calls a set, that is.

So, if I looked into table address, presumably I'd find rows
corresponding to each value that is (ever has been?) stored in another
table with an ADDRESS column. How do no-longer-useful values get
cleaned out of the address table, do you suppose?

There's something that doesn't gel though. From the syntax of the creation,
it looks like the relationship between person and address is one-to-one.
Yet, when storing in separate tables, you are implying a one-to-many
relationship. If it really was one-to-one, you would have the address
fields on the person table. Right?

MikeA

From bouncefilter Sun Jan 30 17:20:40 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA34396
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 17:20:31 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA27438;
Sun, 30 Jan 2000 17:20:28 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Case-folding bogosity in new psql
Date: Sun, 30 Jan 2000 17:20:27 -0500
Message-ID: <27435.949270827@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

New psql doesn't case-fold in \d command:

regression=# \d DEFAULT_TBL
Did not find any relation named "DEFAULT_TBL".
regression=# \d default_tbl
Table "default_tbl"
Attribute | Type | Modifier
... etc ...

I'd expect the name of the table to get folded to lower case unless
I put quotes around it. That is in fact how 6.5 psql behaves.

regards, tom lane

From bouncefilter Sun Jan 30 18:19:41 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA50520
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 18:18:49 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA26218 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 10:18:11 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd8uDha_;
Mon Jan 31 10:17:49 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA02535 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 10:17:49 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdrCsTt_; Mon Jan 31 10:17:18 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA21388
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 10:17:18 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA12374 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 10:16:38 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id KAA01929
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 10:15:54 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3894C62A.BE0ACD4C@bitmead.com>
Date: Mon, 31 Jan 2000 10:15:54 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Copyright
References: <Pine.BSF.4.21.0001290101540.555-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Right. Although IANAL, I'm pretty sure it's pointless to slap a
copyright notice on something unless the copyright names an actual>
legal entity (one which could go sue an infringer, if necessary).
The development team is not a person, corporation, or partnership,
so in the eyes of the law it doesn't exist.

Since the licence lets anybody do pretty much anything, who are you
going to sue?? It seems like the only reason to have the copyright
is to establish that the code is not stolen.

From bouncefilter Sun Jan 30 18:36:41 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA56387
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 18:36:12 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id IAA09143; Mon, 31 Jan 2000 08:36:05 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: ImmediateSharedRelationCacheInvalidate considered harmful
Date: Mon, 31 Jan 2000 08:41:55 +0900
Message-ID: <001001bf6b7b$973d7540$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <13855.949205918@sss.pgh.pa.us>
Importance: Normal

-----Original Message-----

From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Sunday, January 30, 2000 1:19 PM
To: Hiroshi Inoue
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: ImmediateSharedRelationCacheInvalidate considered harmful

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

I have been looking at the cache invalidation changes you committed
on 10 Jan. Most of them look fine, but I am suspicious of the routine
ImmediateSharedRelationCacheInvalidate, which you added for md.c to
call when it truncates or removes a relation. I believe that this
routine is unnecessary, and since it makes for a very ugly linkage
between md.c and the cache code, I would like to take it out again.

The call is for abort/crash after mdunlink()/mdtruncate().
mdunlink()/mdtruncate() is executed immediately but
SI registration for all backends isn't executed until commit.
Yes the call is ugly and it doesn't solve the flaw basically.

Right. As the code currently stands, we are up the creek with no
paddle if an abort occurs after mdunlink/mdtruncate. The only real
solution is to postpone these operations until after commit, which
can only be done if we change the naming convention for relation files.
I think we are drifting towards a consensus that that has to be done.

So the question is, does ImmediateSharedRelationCacheInvalidate add
any useful amount of (incomplete) robustness in the meantime?
I'm not sure --- but since it's not a step towards a real solution,
I'm inclined to leave it out.

OK,I would remove the call.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Jan 30 19:00:41 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA60483
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 19:00:29 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id IAA09150; Mon, 31 Jan 2000 08:58:57 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] freefuncs.c is never called from anywhere!?
Date: Mon, 31 Jan 2000 09:04:47 +0900
Message-ID: <001101bf6b7e$c948b560$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <18901.949213971@sss.pgh.pa.us>
Importance: Normal

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

As far as I see,freeObject() has a fundamental problem.
Probably it couldn't free multiple references safely.

Yes, that code will have a problem with node trees that have
circular references or multiple links to the same node.
Both of which are cases that we can currently generate :-(.

Of course, circular links will also break copyfuncs, equalfuncs,
and printfuncs. We have a known bug with the backend crashing
when -d is enabled for certain queries, because of infinite
recursion in printfuncs.

Multiple links to the same node is not so fatal for other xxxxObject().
In fact they are used without big problem.
But isn't it fatal for freeObject() ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Jan 30 19:14:41 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA63716
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 19:13:48 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA14107 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:13:15 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0nagss;
Mon Jan 31 11:13:07 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA09808 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:13:07 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd023iZw; Mon Jan 31 11:12:36 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA05550
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:12:35 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
LAA14431 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:11:55 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id LAA02216
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:11:12 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3894D320.44D383AA@bitmead.com>
Date: Mon, 31 Jan 2000 11:11:12 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: ORDBMS
References: <Pine.GSO.4.02A.10001271343320.1124-100000@Oxe.DoCS.UU.SE>
<3890EAD1.39089F4C@bitmead.com> <9261.949031039@sss.pgh.pa.us>
<389125F8.7728965F@bitmead.com> <9839.949040200@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

I thought that the original berkeley doco covered this to some extent.

Where would I find that?

No offence intended guys, but I'm a bit shocked that you're all hacking
on
postgres without having read the design docs. The design docs are
extremely cool and I'd personally like to see the database return
to the glory days of all this cool technology, features and ideas.
(Hey wouldn't even mind if it went back to postquel hey hey :)

Ok, the postgres 4.2 distribution is at
http://s2k-ftp.cs.berkeley.edu:8000:8000/postgres/postgres-v4r2/
and it has the design docs inside it.

Here is a little excert from one doc...

In addition to the Retrieve-portal command, portals can be defined by an
Execute
command.
For example, suppose the EMP relation had a field of type POSTQUEL
named ``hobbies''

EMP (name, salary, age, hobbies)
that contained commands to retrieve a person's hobbies from the
following
relations:
SOFTBALL (name, position, batting-avg)
COMPUTERS (name, isowner, brand, interest)
An application program can define a portal that will range over the
tuples
describing a person's hobbies as follows:
execute portal H(EMP.hobbies)
where EMP.name = ``Smith''
This command defines a portal, named ``H,'' that is bound to Smith's
hobby records.
Since a person can have several hobbies, represented by more than on
Retrieve
command in the ``hobbies'' field, the records in the
buffer may have different types.
Consequently,
HITCHING POST must provide routines that allow the program
to determine the number of fields, and the type, name,
and value of each field in each record fetched into the buffer.

From bouncefilter Sun Jan 30 19:16:44 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA63923
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 19:16:19 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA15843 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:15:48 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0KlhD6;
Mon Jan 31 11:15:21 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA12132 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:15:21 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd07WIzz; Mon Jan 31 11:14:59 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA07139
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:14:58 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
LAA14528 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:14:18 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id LAA02220
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:13:35 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3894D3AF.F335EB78@bitmead.com>
Date: Mon, 31 Jan 2000 11:13:35 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: ORDBMS
References: <Pine.GSO.4.02A.10001271343320.1124-100000@Oxe.DoCS.UU.SE>
<3890EAD1.39089F4C@bitmead.com> <9261.949031039@sss.pgh.pa.us>
<389125F8.7728965F@bitmead.com> <9839.949040200@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Hmm. This looks like a CREATE TABLE implicitly creates a datatype
that acts more or less like a C 'struct' declaration, ie, it's just a
collection of subfields. OK, a struct-making declaration is certainly
useful. What I don't understand yet is whether the contents of table
"address" have any connection to the data stored in table "person".
If not, why must I create a table in order to define a datatype? Seems
like a separate CREATE DATATYPE command would make more sense...

I think the idea is like in C++ if you create a
class Address {
...
}

and a class
class Person {
Address address;
}

Then you can create both standalone Addresses as well as addresses
embedded
inside the Person.

CREATE DATATYPE might be a thought, but it's probably not very
essential.

From bouncefilter Sun Jan 30 19:36:43 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA70606
for <pgsql-hackers@postgresql.org>;
Sun, 30 Jan 2000 19:36:01 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA04128 for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 11:35:29 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdbI5V7_;
Mon Jan 31 11:34:52 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA06890 for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 11:34:52 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd4L5Vk_; Mon Jan 31 11:33:47 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA23370
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 11:33:46 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
LAA15220 for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 11:33:04 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id LAA02226
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 11:32:19 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3894D813.3C2EE1BF@bitmead.com>
Date: Mon, 31 Jan 2000 11:32:19 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: ORDBMS
References: <Pine.BSF.4.21.0001281054130.555-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The Hermit Hacker wrote:

Not quite an answer to your question, but my guess is that 'address
ADDRESS' would contain a pointer (OID) to the address table ... so the
person table would be realtively small in comparison to the address table

I'm 99% sure that this is not the case. Rather the address is embedded
inside
the person object. I think this is basicly what Oracle has done with 8i
too.
I think then if you do SELECT * from person it flattens out all the
fields.
(This might even still work).

Not that the idea of relating to oid as another feature is bad. My last
message I gave the example of how postquel could do this. I think
that design had the advantage that you could construct 1:M relationships
this way too.

Just a trade off a bit like in C++
class Person {
Address address;
}

vs

class Person {
Address *address;
}

vs

class Person {
List<Address> addresses;
}

pros and cons for each one.

The way I look at the above, its a 'JOIN' at table create time, based on a
unique value, the OID ...

How 'dep' can you go with this? ie:

CREATE TABLE address (street TEXT, number TEXT, suburb TEXT, zip TEXT);
CREATE TABLE telephone ( home TEXT, business TEXT, fax TEXT );
CREATE TABLE person (name TEXT, address ADDRESS, telephone TELEPHONE);

Question, if I did an INSERT person VALUES ('myname');

What happens to the address table? a row gets created with all NULL? Or?

The reason I ask is the way it was taught to me was that an RDBMS gains
its benefit through normalization and joins ...with the outer join syntax
coming up, if you had a table of 'person' fully populated, but only
address info for 1/2 of them, you could still get all 'people', while your
'address' table has 1/2 the tuples of the person one ... space savings ...

HSorry, rambling thoughts out o fmy head without putting them together
very well :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sun Jan 30 19:38:42 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA70869
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 19:38:14 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA06263 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:37:42 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0.gDs5;
Mon Jan 31 11:37:15 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA10066 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:37:15 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0zF44_; Mon Jan 31 11:35:59 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA25202
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:35:58 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
LAA15285 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:35:20 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id LAA02230
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:34:36 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3894D89C.F9CA9DD7@bitmead.com>
Date: Mon, 31 Jan 2000 11:34:36 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: ORDBMS
References: <Pine.GSO.4.02A.10001271343320.1124-100000@Oxe.DoCS.UU.SE>
<3890EAD1.39089F4C@bitmead.com> <9261.949031039@sss.pgh.pa.us>
<389125F8.7728965F@bitmead.com> <9839.949040200@sss.pgh.pa.us>
<3891B8DA.9FA3073E@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

Chris, one major reason why we run the risk of damaging the OR
features is that we don't have good coverage of these in the
regression tests. And as Tom pointed out, we aren't sure how to get at
the original Postgres papers and docs which might cover this in more
detail;

Why not include the original Postgres papers in the postgresql
distribution? While it's not all applicable now, at least it would
help keep in people's minds what was there.

the only thing we had directly was the old Postgres95 User's
Guide, which may not cover all of the possible features (in fact I
know it doesn't, since I made sure that all info in that guide
appeared somewhere in the newer docs).

I know that there are at least a few people with an interest in this
(including me, but I'm suffering from, among other things, a lack of
knowledge of what used to be there and what could be done). A great
first step would be documenting the behaviors one would expect in a
regression test, even if parts of that test currently fails.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sun Jan 30 20:08:42 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id UAA77866
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 20:08:08 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 5048 invoked by uid 1001); 31 Jan 2000 01:08:13 -0000
Date: Sun, 30 Jan 2000 20:08:13 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: phd2@earthling.net
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Postgres LOGO(was: Beta is February 15th)
In-Reply-To: <Pine.LNX.4.21.0001291729570.30449-100000@fep132.fep.ru>
Message-ID: <Pine.BSF.4.05.10001302007420.4874-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 29 Jan 2000, Oleg Broytmann wrote:

On Sat, 29 Jan 2000, Bruce Momjian wrote:

www.postgresql.org, right?

There is no logo - there are 3 image files, so I need to combine them
into one picture by hands :(

Then try this one:

http://www.postgresql.org/images/sqlephant.gif

You'll only have to crop it.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Sun Jan 30 20:16:42 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA78683
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 20:16:01 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA22887;
Sun, 30 Jan 2000 20:11:15 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001310111.UAA22887@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: ORDBMS
In-Reply-To: <3894D320.44D383AA@bitmead.com> from Chris Bitmead at "Jan 31,
2000 11:11:12 am"
To: Chris Bitmead <chris@bitmead.com>
Date: Sun, 30 Jan 2000 20:11:14 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

I thought that the original berkeley doco covered this to some extent.

Where would I find that?

No offence intended guys, but I'm a bit shocked that you're all hacking
on
postgres without having read the design docs. The design docs are
extremely cool and I'd personally like to see the database return
to the glory days of all this cool technology, features and ideas.
(Hey wouldn't even mind if it went back to postquel hey hey :)

Suppy and demand. We little demand for fancy features, and huge demand
for SQL standard features.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Jan 30 20:52:42 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA86743
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 20:52:31 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA12634;
Sun, 30 Jan 2000 20:52:22 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <200001302156.QAA19093@candle.pha.pa.us>
References: <200001302156.QAA19093@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 30 Jan 2000 16:56:14 -0500"
Date: Sun, 30 Jan 2000 20:52:22 -0500
Message-ID: <12631.949283542@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Perhaps the caches shouldn't store ctid? Not sure.

I am guilt of that. There are a few place where I grab the tuple from
the cache, then use that to update the heap. I thought it was a nifty
solution at the time. I thought I used the CacheCopy calls for that,
but I am not positive. Even if I did, that doesn't help because the
copy probably has an invalid tid at that point, thought I have opened
the table. Maybe I have to make sure I open the table before geting the
tid from the cache.

I believe we worked that out and fixed it a few months ago: it's safe
to use the cache to find a tuple you want to update, if you open and
lock the containing table *before* doing the cache lookup. Then you
know VACUUM's not running on that table (since you have it locked)
and you have an up-to-date TID for the tuple (since the open+lock
would have processed any pending shared-inval messages). I went
around and made sure that's true everywhere.

What I was thinking about was adding code to the caches that would
(a) maintain refcounts on cached tuples, (b) reread rather than
discard a tuple if it is invalidated while refcount > 0, and (c)
kick out an error if the reread shows that the tuple has in fact
changed. It seems that we would need to ignore the TID when deciding
if a tuple has changed, however.

regards, tom lane

From bouncefilter Sun Jan 30 20:55:44 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA87169
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 20:55:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA12668;
Sun, 30 Jan 2000 20:55:15 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-reply-to: <001101bf6b7e$c948b560$2801007e@tpf.co.jp>
References: <001101bf6b7e$c948b560$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Mon, 31 Jan 2000 09:04:47 +0900"
Date: Sun, 30 Jan 2000 20:55:14 -0500
Message-ID: <12665.949283714@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

Multiple links to the same node is not so fatal for other xxxxObject().
In fact they are used without big problem.
But isn't it fatal for freeObject() ?

Yes, of course. We could possibly fix that by maintaining a list of
already-freed nodes during any one freeObject() call, but that seems
painful and slow.

However, the case I'm interested in would only be trying to free
nodetrees that were created by either copyObject or stringToNode,
and since neither of those routines produce multiple or circular
links, it seems safe enough to use freeObject as-is for the purpose.

regards, tom lane

From bouncefilter Sun Jan 30 21:34:43 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA00191
for <pgsql-hackers@postgreSQL.org>;
Sun, 30 Jan 2000 21:34:10 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA24603;
Sun, 30 Jan 2000 21:18:52 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001310218.VAA24603@candle.pha.pa.us>
Subject: Re: [HACKERS] Another nasty cache problem
In-Reply-To: <12631.949283542@sss.pgh.pa.us> from Tom Lane at "Jan 30,
2000 08:52:22 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 30 Jan 2000 21:18:51 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I believe we worked that out and fixed it a few months ago: it's safe
to use the cache to find a tuple you want to update, if you open and
lock the containing table *before* doing the cache lookup. Then you
know VACUUM's not running on that table (since you have it locked)
and you have an up-to-date TID for the tuple (since the open+lock
would have processed any pending shared-inval messages). I went
around and made sure that's true everywhere.

Good.

What I was thinking about was adding code to the caches that would
(a) maintain refcounts on cached tuples, (b) reread rather than
discard a tuple if it is invalidated while refcount > 0, and (c)
kick out an error if the reread shows that the tuple has in fact
changed. It seems that we would need to ignore the TID when deciding
if a tuple has changed, however.

Yes, that is one solution. We can do it the same way heap_fetch works.
It requires a Buffer pointer which it uses to return a value that calls
ReleaseBuffer() when completed.

However, would just throwing an elog on any cache invalidate on a cache
row looked up in the current transaction/command counter make more
sense? Sometimes you are using that cache oid in some later actions
that really can't be proper unlocked at the end? Would be less code.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Jan 30 23:48:44 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA35642
for <pgsql-hackers@postgresql.org>;
Sun, 30 Jan 2000 23:48:13 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sun, 30 Jan 2000 22:48:44 -0600
Sender: ed
Message-ID: <38951455.28A436A@austin.rr.com>
Date: Sun, 30 Jan 2000 22:49:25 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pghackers <pgsql-hackers@postgresql.org>
Subject: [HACKERS] float4 confused as int??
References: <3894B51F.A9D35D2D@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Can someone enlighten me why this error is occurring in which a float
value is apparently being interpreted as an integer? Known
workarounds??

emsdb=>   UPDATE contract_activity_type SET duration = 3.5, updater_id
= 1, last_update = now() WHERE id = 72;
ERROR:  pg_atoi: error in "3.5": can't parse ".5"
emsdb=> \d contract_activity_type
Table    = contract_activity_type
+----------------------------------+----------------------------------+-------+
|              Field               |              Type
| Length|
+----------------------------------+----------------------------------+-------+
| id                               | int4 not null default nextval (
|     4 |
| contract_id                      | int4 not null
|     4 |
| activity_type_id                 | int4 not null
|     4 |
| travel_required                  | int4 not null
|     4 |
| billable                         | int4 not null
|     4 |
| duration                         | float4 not null
|     4 |
...

Thanks in advance.

Cheers,
Ed Loehr

From bouncefilter Mon Jan 31 03:53:47 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id DAA01016
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 03:53:08 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12FCP9-0003kMC; Mon, 31 Jan 100 09:41 MET
Message-Id: <m12FCP9-0003kMC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] END/ABORT
In-Reply-To: <200001281837.NAA01003@candle.pha.pa.us> from Bruce Momjian at
"Jan 28, 2000 01:37:55 pm"
To: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Mon, 31 Jan 2000 09:41:51 +0100 (CET)
CC: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

I'd like to yank the END/ABORT commands, since they're non-standard and
redundant (COMMIT/ROLLBACK). Anyone who could not bear to see them go?
(Of course END would stay as a reserved word.)

We have to keep them in there for compatibility with older code.

How long?

IIRC, CURRENT has been replaced by OLD after I've fixed the
rewriter. Both have been there between 6.4 and 6.5. With 6.5
CURRENT was gone.

Of course, removing END/ABORT will touch many applications
using transactions, but I would vote for it anyway, since
it's standard.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

Ed Loehr wrote:

At least in 6.5.2, you can definitely implement referential integrity
(RI) via pl/pgsql. As someone noted earlier, RI is to be released in
7.0, but I suspect it will take a subsequent release or two to
stabilize before it's fit for consumption by the more conservative
reliability-focused users among us...

I hope that this isn't true.

First, because FOREIGN KEY is implemented as builtin triggers
written in C. BETA should turn out most of the bugs, which
could still be in it.

Second, RI cannot get implemented reliable with regular
triggers. You can easily violate the semantics with
concurrently running transactions. Have first transaction
inserting a reference, the trigger checks for key existence
and finds it. Now second transaction deletes the key, and an
eventually existing ON DELETE CASCADE trigger fired on that
wouldn't find the reference, because it isn't committed yet.
Second transaction commits, what finally removes the key. Now
first transaction commits, making the reference visible, but
referencing a non existing key - inconsistency.

So anyone who needs referential integrity is asked to stress
the code as far as he can, at least during BETA.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Jan 31 05:27:48 2000
Received: from hu.tm.ee (ppp46.tele2.ee [212.107.33.46])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA30116
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 05:26:57 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 42E1C135F1; Mon, 31 Jan 2000 12:32:54 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389564D5.1195BC3F@tm.ee>
Date: Mon, 31 Jan 2000 12:32:53 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Chris Bitmead <chris@bitmead.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: ORDBMS
References: <200001310111.UAA22887@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Tom Lane wrote:

I thought that the original berkeley doco covered this to some extent.

Where would I find that?

No offence intended guys, but I'm a bit shocked that you're all hacking
on
postgres without having read the design docs. The design docs are
extremely cool and I'd personally like to see the database return
to the glory days of all this cool technology, features and ideas.
(Hey wouldn't even mind if it went back to postquel hey hey :)

Suppy and demand. We little demand for fancy features, and huge demand
for SQL standard features.

And even bigger demand for stability and speed (in this order);)

Once we have both to some high level (which we mostly have now) the demand
for fancyness will no doubt return.

----------
Hannu

From bouncefilter Mon Jan 31 07:30:51 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA61689
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 07:30:28 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Hund.DoCS.UU.SE (e99re41@Hund.DoCS.UU.SE [130.238.9.89])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA25908;
Mon, 31 Jan 2000 13:30:19 +0100 (MET)
Received: from localhost (e99re41@localhost) by Hund.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA12806;
Mon, 31 Jan 2000 13:30:17 +0100
X-Authentication-Warning: Hund.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 31 Jan 2000 13:30:16 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <200001300318.WAA18832@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.10001311328290.12762-100000@Hund.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 29 Jan 2000, Bruce Momjian wrote:

However, I can't find any macro that uses this like makeNode does with
its pasteing. I would perhaps move it to a _deadcode directory and see
what happens. Or should we enable it?

Please no more _deadcode. Why do we have CVS?

(In the same spirit it would also be nice to tag NOT_USED sections with a
version number, so it could be yanked two or three releases past.)

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Jan 31 07:55:50 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA67946
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 07:55:22 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Hund.DoCS.UU.SE (e99re41@Hund.DoCS.UU.SE [130.238.9.89])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA28071;
Mon, 31 Jan 2000 13:55:19 +0100 (MET)
Received: from localhost (e99re41@localhost) by Hund.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA13214;
Mon, 31 Jan 2000 13:55:16 +0100
X-Authentication-Warning: Hund.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 31 Jan 2000 13:55:15 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-Reply-To: <22885.949246873@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10001311337440.12762-100000@Hund.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 30 Jan 2000, Tom Lane wrote:

There are plenty of routines that do two or more SearchSysCacheTuple
calls to get the information they need. As the code stands, it is
unsafe to continue accessing the tuple returned by SearchSysCacheTuple
after making a second such call, because the second call could possibly
cause an SI cache reset message to be processed, thereby flushing the
contents of the caches.

heap_open and CommandCounterIncrement are other routines that could
cause cache entries to be dropped.

This sort of thing should be documented, at least in the comment on top of
the function. From the developer's FAQ I gathered something like that
these tuples can be used for a short while, which is of course very exact.

Anyway, I just counted 254 uses of SearchSysCacheTuple in the backend tree
and a majority of these are probably obviously innocent. Since I don't
have any more developing planned, I would volunteer to take a look at all
of those and look for violations of second cache look up, heap_open, and
CommandCounterIncrement, fixing them where possible, or at least pointing
them out to more experienced people. That might save you from going out of
your way and instituting some reference count or whatever, and it would be
an opportunity for me to read some code.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Jan 31 07:58:50 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA69387
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 07:57:57 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Hund.DoCS.UU.SE (e99re41@Hund.DoCS.UU.SE [130.238.9.89])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA28346;
Mon, 31 Jan 2000 13:57:51 +0100 (MET)
Received: from localhost (e99re41@localhost) by Hund.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA13226;
Mon, 31 Jan 2000 13:57:48 +0100
X-Authentication-Warning: Hund.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 31 Jan 2000 13:57:48 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-Reply-To: <200001302156.QAA19093@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.10001311357010.12762-100000@Hund.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 30 Jan 2000, Bruce Momjian wrote:

Perhaps the caches shouldn't store ctid? Not sure.

I am guilt of that. There are a few place where I grab the tuple from
the cache, then use that to update the heap. I thought it was a nifty
solution at the time. I thought I used the CacheCopy calls for that,
but I am not positive. Even if I did, that doesn't help because the
copy probably has an invalid tid at that point, thought I have opened
the table. Maybe I have to make sure I open the table before geting the
tid from the cache.

Urgh, I better check my code for that as well ... :(

Is it only the tid that is of concern. If so, that can probably be
fixed somehow.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Jan 31 08:14:50 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA75201
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 08:14:21 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Hund.DoCS.UU.SE (e99re41@Hund.DoCS.UU.SE [130.238.9.89])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id OAA29881;
Mon, 31 Jan 2000 14:14:13 +0100 (MET)
Received: from localhost (e99re41@localhost) by Hund.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id OAA13267;
Mon, 31 Jan 2000 14:14:12 +0100
X-Authentication-Warning: Hund.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 31 Jan 2000 14:14:11 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: Case-folding bogosity in new psql
In-Reply-To: <27435.949270827@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10001311402110.12762-100000@Hund.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is not a bogosity if you read and understand the psql grammar. Quotes
are for protecting whitespace and other metacharacters. For example, in
6.5 there was no good way to connect (\c) to a database with a space in
the name. psql tries to emulate one of the popular shells in many places,
such as this one. Furthermore single and double quotes also carry the
same difference as in shells and Perl.

psql is also case sensitive, so \D is not the same as \d, hence
DEFAULT_TBL is not the same as default_tbl.

The conceptual problem I would have with your idea is that command option
interpretation would be inconsistent. For example \e FILE should surely
not cause any lower-casing to happen. Now if I'm supposed to pass on the
identity of the quote character with every option that's read all the way
to the execution phase I'm creating a big hazard. It would furthermore
wash away the above mentioned quoting scheme, because double quotes would
mean one thing to one kind of command, and another thing to another.

I'd agree with your objection if we had a DESCRIBE command or some such,
but the psql grammar is different from SQL, and I think it's good to keep
that clear.

What do other people say about this?

On Sun, 30 Jan 2000, Tom Lane wrote:

New psql doesn't case-fold in \d command:

regression=# \d DEFAULT_TBL
Did not find any relation named "DEFAULT_TBL".
regression=# \d default_tbl
Table "default_tbl"
Attribute | Type | Modifier
... etc ...

I'd expect the name of the table to get folded to lower case unless
I put quotes around it. That is in fact how 6.5 psql behaves.

regards, tom lane

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Jan 31 08:27:52 2000
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA76877
for <pgsql-general@postgresql.org>;
Mon, 31 Jan 2000 08:26:53 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id OAA16524;
Mon, 31 Jan 2000 14:26:41 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 12FHlt-0000D3-00; Mon, 31 Jan 2000 14:25:41 +0000
Message-ID: <38958E20.6C517510@sferacarta.com>
Date: Mon, 31 Jan 2000 14:29:04 +0100
From: Jose Soares <jose@sferacarta.com>
Organization: Sfera Carta
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Loehr <eloehr@austin.rr.com>
CC: pg-gen <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] float4 confused as int??
References: <3894B51F.A9D35D2D@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

What version are you running?
I tried it on 6.5.2 and it works.

Ed Loehr wrote:

Can someone enlighten me why this error is occurring in which a float
value is apparently being interpreted as an integer? Known
workarounds??

emsdb=>   UPDATE contract_activity_type SET duration = 3.5, updater_id
= 1, last_update = now() WHERE id = 72;
] ERROR:  pg_atoi: error in "3.5": can't parse ".5"
emsdb=> \d contract_activity_type
Table    = contract_activity_type
+----------------------------------+----------------------------------+-------+
|              Field               |              Type
| Length|
+----------------------------------+----------------------------------+-------+
| id                               | int4 not null default nextval (
|     4 |
| contract_id                      | int4 not null
|     4 |
| activity_type_id                 | int4 not null
|     4 |
| travel_required                  | int4 not null
|     4 |
| billable                         | int4 not null
|     4 |
| duration                         | float4 not null
|     4 |

Thanks in advance.

Cheers,
Ed Loehr

************

--
Jose' Soares
Bologna, Italy Jose@sferacarta.com

From bouncefilter Mon Jan 31 08:40:50 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA82349
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 08:40:23 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA67811;
Mon, 31 Jan 2000 09:36:26 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 09:36:26 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <Pine.GSO.4.02A.10001311328290.12762-100000@Hund.DoCS.UU.SE>
Message-ID: <Pine.BSF.4.21.0001310935390.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 31 Jan 2000, Peter Eisentraut wrote:

On Sat, 29 Jan 2000, Bruce Momjian wrote:

However, I can't find any macro that uses this like makeNode does with
its pasteing. I would perhaps move it to a _deadcode directory and see
what happens. Or should we enable it?

Please no more _deadcode. Why do we have CVS?

(In the same spirit it would also be nice to tag NOT_USED sections with a
version number, so it could be yanked two or three releases past.)

Why not just yank it period? 'cvs diff' will show what was yanked, and
the log message could say just 'yanked NOT_USED code from source tree'...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 08:42:50 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA82597
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 08:42:02 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Hund.DoCS.UU.SE (e99re41@Hund.DoCS.UU.SE [130.238.9.89])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id OAA02304;
Mon, 31 Jan 2000 14:41:56 +0100 (MET)
Received: from localhost (e99re41@localhost) by Hund.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id OAA13313;
Mon, 31 Jan 2000 14:41:54 +0100
X-Authentication-Warning: Hund.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 31 Jan 2000 14:41:53 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <Pine.BSF.4.21.0001310935390.480-100000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10001311438530.12762-100000@Hund.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 31 Jan 2000, The Hermit Hacker wrote:

On Mon, 31 Jan 2000, Peter Eisentraut wrote:

On Sat, 29 Jan 2000, Bruce Momjian wrote:

However, I can't find any macro that uses this like makeNode does with
its pasteing. I would perhaps move it to a _deadcode directory and see
what happens. Or should we enable it?

Please no more _deadcode. Why do we have CVS?

(In the same spirit it would also be nice to tag NOT_USED sections with a
version number, so it could be yanked two or three releases past.)

Why not just yank it period? 'cvs diff' will show what was yanked, and
the log message could say just 'yanked NOT_USED code from source tree'...

I *suspect* the purpose of some of these sections is that if it turns out
somebody needed them for their application, we could just tell them to
re-enable them there and there. If this is the case, then it has gone way
past abuse already, though. Some parts of been NOT_USED for many years and
most likely don't work anymore.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Jan 31 09:02:51 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA00246
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 09:01:55 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id KAA68012;
Mon, 31 Jan 2000 10:00:51 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 10:00:51 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <Pine.GSO.4.02A.10001311438530.12762-100000@Hund.DoCS.UU.SE>
Message-ID: <Pine.BSF.4.21.0001310959350.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 31 Jan 2000, Peter Eisentraut wrote:

On Mon, 31 Jan 2000, The Hermit Hacker wrote:

On Mon, 31 Jan 2000, Peter Eisentraut wrote:

On Sat, 29 Jan 2000, Bruce Momjian wrote:

However, I can't find any macro that uses this like makeNode does with
its pasteing. I would perhaps move it to a _deadcode directory and see
what happens. Or should we enable it?

Please no more _deadcode. Why do we have CVS?

(In the same spirit it would also be nice to tag NOT_USED sections with a
version number, so it could be yanked two or three releases past.)

Why not just yank it period? 'cvs diff' will show what was yanked, and
the log message could say just 'yanked NOT_USED code from source tree'...

I *suspect* the purpose of some of these sections is that if it turns out
somebody needed them for their application, we could just tell them to
re-enable them there and there. If this is the case, then it has gone way
past abuse already, though. Some parts of been NOT_USED for many years and
most likely don't work anymore.

IMHO, if you want to take the time to do it, yank it. we have a cvs
history of everything we do, so it isn't as if its permanently lost, and,
as you say, with all the changes that have gone around some of the
NOT_USED code, they are most likely not even valid/working anymore :)

Makes for a good time to do clean up ... before beta and/or major release
...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 09:12:51 2000
Received: from kredit.sth.szif.hu (IDENT:neko@kredit.sth.szif.hu
[193.224.129.23]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA03165
for <pgsql-admin@hub.org>; Mon, 31 Jan 2000 09:12:23 -0500 (EST)
(envelope-from neko@kredit.sth.szif.hu)
Received: from localhost (neko@localhost)
by kredit.sth.szif.hu (8.9.3/8.9.3) with ESMTP id PAA27063;
Mon, 31 Jan 2000 15:13:55 +0100
Date: Mon, 31 Jan 2000 15:13:55 +0100 (CET)
From: Peter Vazsonyi <neko@kredit.sth.szif.hu>
To: pgsql-admin@hub.org
cc: pgsql-hackers@postgresql.org
Subject: Re: [ADMIN] Attribute 'aggtransfn1' is repeated
In-Reply-To: <Pine.LNX.4.10.10001281234500.18016-100000@kredit.sth.szif.hu>
Message-ID: <Pine.LNX.4.10.10001311506300.27029-200000@kredit.sth.szif.hu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
BOUNDARY="-524216447-1720092117-949328035=:27045"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

---524216447-1720092117-949328035=:27045
Content-Type: TEXT/PLAIN; charset=US-ASCII

Opps... that was simple bug.
I don't understand why works on x86, why not on sparc (gcc?), but this small
patch should correct the error.

On Fri, 28 Jan 2000, Peter Vazsonyi wrote:

[postgres@sun2 pgsql]$ initdb -r $PWD -l /usr/local/pgsql/lib/

We are initializing the database system with username postgres (uid=40).
This user will own all the files and must also own the server process.

Creating template database in /var/lib/pgsql/base/template1
ERROR: Attribute 'aggtransfn1' is repeated
ERROR: Attribute 'aggtransfn1' is repeated

--
nek;(

---524216447-1720092117-949328035=:27045
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="nameerr.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.10001311513550.27045@kredit.sth.szif.hu>
Content-Description:
Content-Disposition: attachment; filename="nameerr.patch"

LS0tIHNyYy9iYWNrZW5kL3V0aWxzL2FkdC9uYW1lLmMub3JpZyAgIE1vbiBK
YW4gMzEgMTQ6MjY6MDMgMjAwMA0KKysrIHNyYy9iYWNrZW5kL3V0aWxzL2Fk
dC9uYW1lLmMgICAgICAgIE1vbiBKYW4gMzEgMTQ6MjY6NTAgMjAwMA0KQEAg
LTg5LDMgKzg5LDMgQEAgbmFtZWVxKE5hbWVEYXRhICphcmcxLCBOYW1lRGF0
YSAqYXJnMikNCiAgICAgICAgZWxzZQ0KLSAgICAgICAgICAgICAgIHJldHVy
biAoYm9vbCkgc3RybmNtcChhcmcxLT5kYXRhLCBhcmcyLT5kYXRhLCBOQU1F
REFUQUxFTikgPT0gMDsNCisgICAgICAgICAgICAgICByZXR1cm4gKGJvb2wp
IChzdHJuY21wKGFyZzEtPmRhdGEsIGFyZzItPmRhdGEsIE5BTUVEQVRBTEVO
KSA9PSAwKTsNCiB9DQo=
---524216447-1720092117-949328035=:27045--

From bouncefilter Mon Jan 31 09:45:51 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA10833
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 09:45:16 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm148.noc.fukui.nsk.ne.jp [210.161.188.67])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id XAA09546 for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 23:45:09 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Duplicate index check in btbuild
Date: Mon, 31 Jan 2000 23:46:09 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFAEIKCCAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi all,

Currently btbuild() rejects duplicate index in comparetup_index().
But there are some cases that index tuples for already deleted
heap tuples should be made. comparetup_index() doesn't work
well in such cases because comparetup_index() couldn't ignore
deleted tuples. In addition I could find no other place to check
index uniqueness in tuplesort.c .
Seems we have to give up the uniqueness check in comparetup_
index() and have to check it in _bt_buildadd().
We would be able to take the visibility of heap tuples into acount
in _bt_buildadd().

Comments ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Jan 31 10:09:53 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA17673
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 10:08:56 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA09764;
Mon, 31 Jan 2000 10:08:43 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: Case-folding bogosity in new psql
In-reply-to: <Pine.GSO.4.02A.10001311402110.12762-100000@Hund.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10001311402110.12762-100000@Hund.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Mon, 31 Jan 2000 14:14:11 +0100"
Date: Mon, 31 Jan 2000 10:08:43 -0500
Message-ID: <9761.949331323@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

This is not a bogosity if you read and understand the psql grammar.

In other words, you have (by fiat and with no discussion AFAIR) decided
to change psql's "grammar" so that its handling of names is inconsistent
with the backend's. That might be OK if psql were an independent
product, but it's not. There are already enough discrepancies between
parsing of backslash commands and parsing of SQL commands; do we need
to add more?

Quotes
are for protecting whitespace and other metacharacters. For example, in
6.5 there was no good way to connect (\c) to a database with a space in
the name.

That indicates that \c failed to accept quoted names properly --- but
that's just a bug in \c, not a reason to transfer the same breakage
to other places.

The conceptual problem I would have with your idea is that command option
interpretation would be inconsistent. For example \e FILE should surely
not cause any lower-casing to happen.

No, but a filename is not an SQL name. Claiming that filename
interpretation must govern SQL name interpretation is about like
claiming that psql should misinterpret SQL names that happen to
match file names in your current directory.

I think that you have reduced usability considerably in order not to
have to distinguish SQL names and file names in some parts of your
code. That's a design error IMHO.

What do other people say about this?

I'll wait for other reactions ... but I am not happy.

regards, tom lane

From bouncefilter Mon Jan 31 10:24:53 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA22533
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 10:24:28 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA09853;
Mon, 31 Jan 2000 10:24:24 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <Pine.GSO.4.02A.10001311337440.12762-100000@Hund.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10001311337440.12762-100000@Hund.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Mon, 31 Jan 2000 13:55:15 +0100"
Date: Mon, 31 Jan 2000 10:24:23 -0500
Message-ID: <9850.949332263@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

This sort of thing should be documented,

... or changed ...

Anyway, I just counted 254 uses of SearchSysCacheTuple in the backend tree
and a majority of these are probably obviously innocent. Since I don't
have any more developing planned, I would volunteer to take a look at all
of those and look for violations of second cache look up, heap_open, and
CommandCounterIncrement, fixing them where possible, or at least pointing
them out to more experienced people. That might save you from going out of
your way and instituting some reference count or whatever, and it would be
an opportunity for me to read some code.

I appreciate the offer, but I don't really want to fix it that way.
If that's how things have to work, then the code will be *extremely*
fragile --- any routine that opens a relation or looks up a cache tuple
will potentially break its callers as well as itself. And since the
probability of failure is so low, we'll never find it; we'll just keep
getting the occasional irreproducible failure report from the field.
I think we need a designed-in solution rather than a restrictive coding
rule.

Also, I am not sure that the existing uses are readily fixable. For
example, I saw a number of crashes in the parser last night, most of
which traced to uses of Operator or Type pointers --- which are really
SearchSysCacheTuple results, but the parser passes them around with wild
abandon. I don't see any easy way of restructuring that code to avoid
this.

I am starting to think that Bruce's idea might be the way to go: lock
down any cache entry that's been referenced since the last transaction
start or CommandCounterIncrement, and elog() if it's changed by
invalidation. Then the only coding rule needed is "cached tuples don't
stay valid across CommandCounterIncrement", which is relatively
simple to check for.

regards, tom lane

From bouncefilter Mon Jan 31 10:26:52 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA22755
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 10:26:36 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA68542;
Mon, 31 Jan 2000 11:26:23 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 11:26:23 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
In-Reply-To: <9761.949331323@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001311125330.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

have to agree ... psql behaviour should be an extension of the backend's
...

On Mon, 31 Jan 2000, Tom Lane wrote:

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

This is not a bogosity if you read and understand the psql grammar.

In other words, you have (by fiat and with no discussion AFAIR) decided
to change psql's "grammar" so that its handling of names is inconsistent
with the backend's. That might be OK if psql were an independent
product, but it's not. There are already enough discrepancies between
parsing of backslash commands and parsing of SQL commands; do we need
to add more?

Quotes
are for protecting whitespace and other metacharacters. For example, in
6.5 there was no good way to connect (\c) to a database with a space in
the name.

That indicates that \c failed to accept quoted names properly --- but
that's just a bug in \c, not a reason to transfer the same breakage
to other places.

The conceptual problem I would have with your idea is that command option
interpretation would be inconsistent. For example \e FILE should surely
not cause any lower-casing to happen.

No, but a filename is not an SQL name. Claiming that filename
interpretation must govern SQL name interpretation is about like
claiming that psql should misinterpret SQL names that happen to
match file names in your current directory.

I think that you have reduced usability considerably in order not to
have to distinguish SQL names and file names in some parts of your
code. That's a design error IMHO.

What do other people say about this?

I'll wait for other reactions ... but I am not happy.

regards, tom lane

************

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 10:29:55 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA23139
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 10:29:16 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Hund.DoCS.UU.SE (e99re41@Hund.DoCS.UU.SE [130.238.9.89])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id QAA11451;
Mon, 31 Jan 2000 16:29:09 +0100 (MET)
Received: from localhost (e99re41@localhost) by Hund.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id QAA13481;
Mon, 31 Jan 2000 16:29:07 +0100
X-Authentication-Warning: Hund.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 31 Jan 2000 16:29:07 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: Case-folding bogosity in new psql
In-Reply-To: <9761.949331323@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10001311625250.12762-100000@Hund.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 31 Jan 2000, Tom Lane wrote:

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

This is not a bogosity if you read and understand the psql grammar.

In other words, you have (by fiat and with no discussion AFAIR) decided
to change psql's "grammar" so that its handling of names is inconsistent
with the backend's. That might be OK if psql were an independent
product, but it's not. There are already enough discrepancies between
parsing of backslash commands and parsing of SQL commands; do we need
to add more?

I have written so many requests for comments on psql, I don't know. This
handling of names was nowhere documented, so I couldn't have known it. On
the other hand, the current behaviour is documented and consistent with
something at least. I totally see what you're saying and I'm going to try
to address it. But there was noone who said anything about this so far.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Jan 31 10:30:56 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA23492
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 10:30:18 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Hund.DoCS.UU.SE (e99re41@Hund.DoCS.UU.SE [130.238.9.89])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id QAA11532;
Mon, 31 Jan 2000 16:30:14 +0100 (MET)
Received: from localhost (e99re41@localhost) by Hund.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id QAA13491;
Mon, 31 Jan 2000 16:30:12 +0100
X-Authentication-Warning: Hund.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 31 Jan 2000 16:30:12 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
In-Reply-To: <Pine.BSF.4.21.0001311125330.480-100000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10001311629140.12762-100000@Hund.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 31 Jan 2000, The Hermit Hacker wrote:

have to agree ... psql behaviour should be an extension of the backend's

Okay. Then it shall be ...

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Jan 31 10:42:53 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA29191
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 10:42:34 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA09905;
Mon, 31 Jan 2000 10:42:04 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-reply-to: <Pine.GSO.4.02A.10001311438530.12762-100000@Hund.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10001311438530.12762-100000@Hund.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Mon, 31 Jan 2000 14:41:53 +0100"
Date: Mon, 31 Jan 2000 10:42:04 -0500
Message-ID: <9901.949333324@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

Please no more _deadcode. Why do we have CVS?

I *suspect* the purpose of some of these sections is that if it turns out
somebody needed them for their application, we could just tell them to
re-enable them there and there.

I think there are several different motivations, and it would be bad to
tar all the occurrences of NOT_USED with the same brush.

Some of them are indeed just code that was #ifdef'd out while testing
a replacement solution, and never physically removed. I think that's what
CVS is for; we should keep history in CVS versions, not in the current
sources.

Some of them are useful code that just happens not to be referenced
at the moment, but might be needed again at any time. (And who'd
think to go look in back CVS versions, when wondering "is there a
routine that ..."?)

Some of them are code that was disabled because it was broken, but with
hopes of fixing and re-enabling it someday. (The expensive-function
code in the optimizer seems to be an example of this.) The advantage
of leaving such code in current sources is that it has a better chance
of tracking global edits, such as routine or struct field renamings.

I know that I have usually ignored files in _deadcode directories when
making widespread changes, which means that those files drift further
and further away from any hope of future usefulness. This doesn't
happen quite as fast for code that's #ifdef NOT_USED but still present
in current source files.

I think it would be a bad idea to go around and yank out NOT_USED code
wholesale --- this should be looked at on a case-by-case basis, with
consideration of whether the code might be useful again in future.

But I think I might vote for pruning the _deadcode directories
wholesale. I suspect the files in them are suffering from
irrecoverable bit rot.

regards, tom lane

From bouncefilter Mon Jan 31 10:52:52 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA33138
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 10:52:45 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA09973;
Mon, 31 Jan 2000 10:52:35 -0500 (EST)
To: Ed Loehr <eloehr@austin.rr.com>
cc: pghackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] float4 confused as int??
In-reply-to: <38951455.28A436A@austin.rr.com>
References: <3894B51F.A9D35D2D@austin.rr.com> <38951455.28A436A@austin.rr.com>
Comments: In-reply-to Ed Loehr <eloehr@austin.rr.com>
message dated "Sun, 30 Jan 2000 22:49:25 -0600"
Date: Mon, 31 Jan 2000 10:52:35 -0500
Message-ID: <9970.949333955@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ed Loehr <eloehr@austin.rr.com> writes:

emsdb=> UPDATE contract_activity_type SET duration = 3.5, updater_id
= 1, last_update = now() WHERE id = 72;
ERROR: pg_atoi: error in "3.5": can't parse ".5"

?? What version are you running? I can't reproduce that with either
6.5.3 or current sources.

regards, tom lane

From bouncefilter Mon Jan 31 11:01:52 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA35408
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 11:01:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA09993;
Mon, 31 Jan 2000 11:00:57 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Duplicate index check in btbuild
In-reply-to: <NDBBIJLOILGIKBGDINDFAEIKCCAA.Inoue@tpf.co.jp>
References: <NDBBIJLOILGIKBGDINDFAEIKCCAA.Inoue@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Mon, 31 Jan 2000 23:46:09 +0900"
Date: Mon, 31 Jan 2000 11:00:57 -0500
Message-ID: <9990.949334457@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

In addition I could find no other place to check
index uniqueness in tuplesort.c .
Seems we have to give up the uniqueness check in comparetup_
index() and have to check it in _bt_buildadd().

Checking index uniqueness in tuplesort is pretty much of a hack,
although kind of cool since it doesn't take any extra comparisons
to do it there. But if we're doing the wrong thing then it has
to be removed.

I'm a little unclear on *why* it's wrong though. Don't we grab an
exclusive lock on a table while building an index for it? (If not,
shouldn't we be doing so?) I don't see how there can be tuples of
uncertain commit state that need to be included in the index.

regards, tom lane

From bouncefilter Mon Jan 31 11:30:52 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA42684
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 11:30:24 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 31 Jan 2000 10:31:00 -0600
Sender: ed
Message-ID: <3895B8EB.6E34CB9E@austin.rr.com>
Date: Mon, 31 Jan 2000 10:31:39 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pghackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] float4 confused as int??
References: <3894B51F.A9D35D2D@austin.rr.com> <38951455.28A436A@austin.rr.com>
<9970.949333955@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Ed Loehr <eloehr@austin.rr.com> writes:

emsdb=> UPDATE contract_activity_type SET duration = 3.5, updater_id
= 1, last_update = now() WHERE id = 72;
ERROR: pg_atoi: error in "3.5": can't parse ".5"

?? What version are you running? I can't reproduce that with either
6.5.3 or current sources.

6.5.2

From bouncefilter Mon Jan 31 11:31:52 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA45089
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 11:31:40 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 31 Jan 2000 10:32:15 -0600
Sender: ed
Message-ID: <3895B937.FEFA87F1@austin.rr.com>
Date: Mon, 31 Jan 2000 10:32:55 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, pghackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] float4 confused as int??
References: <3894B51F.A9D35D2D@austin.rr.com> <38951455.28A436A@austin.rr.com>
<9970.949333955@sss.pgh.pa.us> <3895B8EB.6E34CB9E@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Loehr wrote:

Tom Lane wrote:

Ed Loehr <eloehr@austin.rr.com> writes:

emsdb=> UPDATE contract_activity_type SET duration = 3.5, updater_id
= 1, last_update = now() WHERE id = 72;
ERROR: pg_atoi: error in "3.5": can't parse ".5"

?? What version are you running? I can't reproduce that with either
6.5.3 or current sources.

6.5.2

This happens only via DBI/DBD::Pg. I can't reproduce via psql.

Cheers,
Ed Loehr

From bouncefilter Mon Jan 31 13:23:54 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA87096
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 13:23:11 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (ip201.pdx2.pacifier.com [216.65.144.201])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id KAA23169;
Mon, 31 Jan 2000 10:21:51 -0800 (PST)
Message-Id: <3.0.1.32.20000131094558.00f068ac@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 31 Jan 2000 09:45:58 -0800
To: Jan Wieck <wieck@debis.com>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] END/ABORT
Cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <m12FCP9-0003kMC@orion.SAPserv.Hamburg.dsh.de>
References: <200001281837.NAA01003@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:41 AM 1/31/00 +0100, Jan Wieck wrote:

Of course, removing END/ABORT will touch many applications
using transactions, but I would vote for it anyway, since
it's standard.

Does it make all that much sense to worry about the actual word
used when the need to use "begin" is non-standard to begin with?

Of course, removing that would REALLY impact current applications...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Jan 31 13:36:54 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA92989
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 13:36:32 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 31 Jan 2000 12:26:49 -0600
Sender: ed
Message-ID: <3895D678.A55E96B1@austin.rr.com>
Date: Mon, 31 Jan 2000 12:37:44 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, pghackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] float4 confused as int??
References: <3894B51F.A9D35D2D@austin.rr.com> <38951455.28A436A@austin.rr.com>
<9970.949333955@sss.pgh.pa.us> <3895B8EB.6E34CB9E@austin.rr.com>
<3895B937.FEFA87F1@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Loehr wrote:

Ed Loehr wrote:

Tom Lane wrote:

Ed Loehr <eloehr@austin.rr.com> writes:

emsdb=> UPDATE contract_activity_type SET duration = 3.5, updater_id
= 1, last_update = now() WHERE id = 72;
ERROR: pg_atoi: error in "3.5": can't parse ".5"

?? What version are you running? I can't reproduce that with either
6.5.3 or current sources.

6.5.2

This happens only via DBI/DBD::Pg. I can't reproduce via psql.

Not getting enough sleep...

Correction: DBI or not makes no difference. I can reproduce it on
*this* table via psql, but I cannot reproduce on a newly created table
with a float column.

From bouncefilter Mon Jan 31 14:16:56 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA02925
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 14:16:25 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12FMH2-0005yF-00; Mon, 31 Jan 2000 19:14:08 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12FMGq-0003gk-00; Mon, 31 Jan 2000 19:13:56 +0000
Date: Mon, 31 Jan 2000 19:13:56 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
Message-ID: <20000131191356.B8582@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <22885.949246873@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <22885.949246873@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Sun, Jan 30, 2000 at 10:41:13AM -0500

Tom Lane wrote:

I'm down to the point where the parallel tests mostly work with a small
SI buffer --- but they do still sometimes fail.

Have you committed your changes? I tried the parallel tests with cvs of around
5pm GMT 31 Jan, and they were all fine (I just ran out of procs at one point).
This is much better than last week! Thanks! I also tried that nonsensical
join from the other day, and it failed in the same way again:

newnham=# select * from crsids,"tblPerson" where
newnham-# crsids.crsid != "tblPerson"."CRSID";
Backend sent B message without prior T
D21Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.

After \. :

Unknown protocol character 'M' read from backend. (The protocol character is the first character the backend sends in response to a query it receives).
PQendcopy: resetting connection
Asynchronous NOTIFY 'ndropoulou' from backend with pid '1818589281' received.
Asynchronous NOTIFY 'ndropoulou' from backend with pid '1818589281' received.

pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32

but no NOTICEs about SI anywhere any more, in fact no messages at all until
the "Unknown protocol character" bit above. The psql frontend process grows to
about 120Mb in size before this if that matters (200Mb swap free).

(Looking at why pg_dumpall creates unique indices for each different type
of index at the moment...)

Cheers,

Patrick

From bouncefilter Mon Jan 31 15:04:55 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA18293
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 15:04:23 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 31 Jan 2000 14:04:58 -0600
Sender: ed
Message-ID: <3895EB10.CC9EC4A9@austin.rr.com>
Date: Mon, 31 Jan 2000 14:05:36 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pghackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] float4 confused as int??
References: <3894B51F.A9D35D2D@austin.rr.com> <38951455.28A436A@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The problem is occurring with a database that was restored with psql
from a pg_dump (6.5.2).

If I dump the problem table, then drop/recreate it with my original
table creation commands, and then reload with only the insert commands
from the pg_dump'ed file, it reloads and allows updating of the float
field without a problem. Testing my entire DB to find other problem
float fields is painful; doing this drop/recreate process would be
even more so.

As you can see below, this makes no sense given '\d' shows the field
is a float4 yet the code is trying to call pg_atoi on the new value...

I'm still looking into this more to understand what hoops I may have
to jump through to salvage/reuse pg_dump output...any tips would be
appreciated.

Ed Loehr wrote:

Can someone enlighten me why this error is occurring in which a float
value is apparently being interpreted as an integer? Known
workarounds??

emsdb=>   UPDATE contract_activity_type SET duration = 3.5, updater_id
= 1, last_update = now() WHERE id = 72;
ERROR:  pg_atoi: error in "3.5": can't parse ".5"
emsdb=> \d contract_activity_type
Table    = contract_activity_type
+----------------------------------+----------------------------------+-------+
|              Field               |              Type
| Length|
+----------------------------------+----------------------------------+-------+
| id                               | int4 not null default nextval (
|     4 |
| contract_id                      | int4 not null
|     4 |
| activity_type_id                 | int4 not null
|     4 |
| travel_required                  | int4 not null
|     4 |
| billable                         | int4 not null
|     4 |
| duration                         | float4 not null
|     4 |
...

Thanks in advance.

Cheers,
Ed Loehr

From bouncefilter Mon Jan 31 16:34:56 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA52894;
Mon, 31 Jan 2000 16:34:51 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA71121;
Mon, 31 Jan 2000 17:34:42 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 17:34:42 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
cc: pgsql-interfaces@postgresql.org
Subject: PClabs Survey, Part I: Administration
Message-ID: <Pine.BSF.4.21.0001311730410.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

PCLabs is doing a survey of RDBMSs, and has requested that we answer the
following survey. As one file, its over 250 lines long, so I'm breaking
into multiple parts, to make the 'thread' smaller. Some of this is
obvious, but would rather make sure then risk feeding mis-information :)

In this one, they talk about 'graphical tools', so I'm CC'ng
pgsql-interfaces@postgresql.org, in the hopes that both
Constantin(pgaccess) and Dave (PgAdmin) will jump into the thread and
answer those questions...

==========
Administration
- graphical tools for
- database administration
- installing the database server
- creating and managing databases
- creating and managing disk devices
- creating and managing users
- creating and managing indicies
- creating and managing stored procedures
- backup and restore operations
- creating and managing replication links
- Web publishing
- database diagramming tools
- viewing and entering data into database tables
- submitting SQL commands and viewing results
- send a message to all logged-in database users
- database perforformance tuning
- configuring server engine options
- viewing the SQL commands currently executing
- detecting resource-intensive queries
- killing selected queries
- graphing overall server engine statistics
- single statement graphical execution plan display
- SQL rewrite suggestions for a single SQL statement
- index suggestions for a single SQL statement
- index suggestions for overall server (based on actual usage)
- pre-calculation (summary table) suggestions (based on actual usage)
- baselining and then tracking server performance over time
- administration tools can be run from a 4.x Web browser
- data file import and export tools
- for ASCII text files
- for native format database data files
- database data files can be directly moved from one database to another

- scripting support
- tools have command-line access
- can reverse-engineer database objects to a SQL script
- can reverse-engineer database data to a SQL script
- languages supplied for command scripting
- security
- security audit log of administrator and user activity
- can set security by user or by group
- can set password qualification rules (minimum length, non-repeatabilitity)
- can set permissions on a table or view
- can set permissions on a particular column
- can set permissions on a particular row
- job scheduler
- by time
- by event
===========================

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 16:37:01 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA53940
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 16:36:16 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA71129
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 17:36:00 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 17:36:00 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: PCLabs Survey, Part II: Server Engine
Message-ID: <Pine.BSF.4.21.0001311734430.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Server Engine
- units of execution (granularity of multi-tasking engine)
- computes statistics while building index
- can run operations without logging
- can undo database structure modification (Data Definition Layer) commands
- can undo committed transactions if required
- locking
- levels of locking granulatity available (options are row, page, table,etc.)
- default locking level for queries
- readers of data can block writers of data (at default locking level)
- writers of data can block readers of data (at default locking level)
- can use different types of locks on index and data pages in one query
- can escalate many fine-grained locks to one coarser lock
- can use multiple CPUs
- within a query (intra-query parallelism)
- on database load
- on database index
- on database backup and restore
- on insert ... select ...
- on update
- on delete
- join and index selection
- joins
- nested loop join
- hash join
- merge join
- semi-join for star queries
- list any others:
- indicies
- B-tree
- clustered (data pages ordered by primary key value)
- allow secondary indices on a clustered index table
- bitmap
- hash
- list any others:
- can scan indices in reverse
- optimizer
- cost-based
- rule-based
- can use multiple indices in a single query
- can use just the index to satisfy the query (covered indices)
- automatically maintains necessary optimizer statistics
- cache and memory management
- dynamic SQL statements parameterized and cached for later use
- execution plans can be compiled once and then shared among all users
- can define dedicated caches for particular tables or tablespaces
- can mark tables as memory-resident
- dynamic memory resource sharing (e.g. cache can grow or shrink)
- scalability
- number of CPUs supported per server
- multi-machine clustering for performance
- clustered servers require shared disk subsystem
- clustered machines can run different operating systems
- availability
- failover server option
- primary and standby servers require shared disk subsystem or only a shared network connection
- primary and standby servers can run different operating systems
- failover server can be actively used (active/active configuration)
- client connection libraries support automatic failover to standby server
- ability to guarantee service (QoS)
- query resource consumption governor
- can assign priorities to different groups of users
- backup and restore
- restore to a particular point-in-time (partial restore)
- incremental backup
- recovery
- can control frequency of checkpointing by number of operations or estimated recovery time (list which)
- storage engine
- default disk data block size
- users can choose disk block size (list options)
- allow use of unformatted disks for extra speed
- parallel disk operations
- automatic disk read-ahead
- multi-task (asynchronous) disk operations
- data and log devices can grow when needed
- Year 2000 certified
- Euro currency support

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 16:36:56 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA53983
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 16:36:30 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA71133
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 17:36:24 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 17:36:24 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: PCLabs Survey, Part III: Multimedia Data Types
Message-ID: <Pine.BSF.4.21.0001311736030.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Multimedia data types
- binary large object (BLOB)
- Unicode text objects
- HTML
- sound
- video
- images
- text documents
- time series
- geospatial
- can leave managed objects in their original files outside the database

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 16:36:57 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA54034
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 16:36:53 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA71137
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 17:36:49 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 17:36:49 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: PCLabs Survey, Part IV: Interoperability
Message-ID: <Pine.BSF.4.21.0001311736250.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Interoperability
- included gateways to other databases:
- support reads
- support writes
- support distributed query optimization
- support replication
- support data loading (for warehousing purposes)
- single login with
- Windows NT
- LDAP
- OSF DCE
- Sun NIS+
- /etc/passwd file

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 16:37:59 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA54226
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 16:37:34 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA71142
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 17:37:28 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 17:37:28 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: PCLabs Survey, Part V: Programmability
Message-ID: <Pine.BSF.4.21.0001311736500.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Programmability
- stored procedures
- can call out to external routines (external stored procedures)
- internal programming language(s):
- flow control and loops
- user-defined (compound) structures
- recursion
- exceptions
- can return error messages to clients
- object-oriented
- debugger supplied for stored procedure language(s)
- triggers
- triggers can cascade (nested triggers)
- multiple triggers per action per row
- standard database client APIs supported in addition to native API (e.g. ODBC, JDBC, OLE DB, etc.)
- revision of ODBC driver supplied
- revision of JDBC driver supplied
- precompilers supplied for which languages:
- cursors can scroll backwards as well as forwards
- message queuing services

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 16:39:56 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA54447
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 16:38:59 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA71151
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 17:38:56 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 17:38:56 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: PCLabs Survey, Part VI: Query Language and Database Design
Message-ID: <Pine.BSF.4.21.0001311738130.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Query Language and Database Design
- ANSI/ISO standards compliance
- SQL standard supplied (e.g. SQL-89, SQL-92 entry level, any SQL3 support, etc.)
- SQL-92 catalog schema views
- ANSI isolation levels supported
- left, right and full outer joins
- declarative referential integrity
- declarative cascade delete
- declarative cascade update
- ability to modify existing designs
- rename table
- modify data type of existing column
- add/drop column in existing table
- add/drop constraint in existing table
- more than one unique constraint per table
- object-oriented design support (abstract types, inheritance)
- object references (REFs)
- computed columns
- can build an index on a computed column
- computed tables

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 16:39:58 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA54575
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 16:39:38 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA71156
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 17:39:33 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 17:39:33 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: PCLabs Survey, Part VII: Embedded Database / Branch Office Support
Message-ID: <Pine.BSF.4.21.0001311738580.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

- can run on a laptop running Windows 95 with 32MB of RAM
- replication
- trigger approach or log-sniffer approach?
- one-way (push) replication
- bi-directional (synchronize) replication
- remote administration
- pager or e-mail notification of errors on remote server
- administration tools can manage a remote database
- administration tools can send jobs to groups of servers at once
- can delegate administrative tasks (partial access to administration tools and jobs)
- can run stored procedures on remote system
- distributed transactions using two-phase commit
- with other servers running this database server software
- with other servers running database server software from other companies (e.g. XA support)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 16:40:56 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA54682
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 16:40:12 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA71174
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 17:40:10 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 17:40:09 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: PCLabs Survey, Part VIII: Data Warehousing and Reporting
Message-ID: <Pine.BSF.4.21.0001311739340.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Data Warehousing and Reporting
- availability
- fast loader (direct to disk pages) included
- loader provides data transformation and cleansing tools
- can load and index simultaneously
- incremental load possible
- can delay constraint checking during a bulk load
- can continue to insert data while index is being built
- precalculation of summary information
- included OLAP server
- summary tables (a.k.a. materialized views)
- summary tables understand dimensional hierarchies (e.g. time)
- automatic refresh on data change
- scheduled refresh
- can use data sampling to speed processing
- Top N query
- Top % query
- RANK function
- CUBE and ROLLUP functions

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 16:41:56 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA54923;
Mon, 31 Jan 2000 16:41:37 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA71222;
Mon, 31 Jan 2000 17:41:35 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 17:41:35 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
cc: pgsql-interfaces@postgresql.org
Subject: PClabs Survey, Part I: Administration (resend)
Message-ID: <Pine.BSF.4.21.0001311740440.480-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Missed part of this one in my cut-n-paste :(

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

=================

PCLabs is doing a survey of RDBMSs, and has requested that we answer the
following survey. As one file, its over 250 lines long, so I'm breaking
into multiple parts, to make the 'thread' smaller. Some of this is
obvious, but would rather make sure then risk feeding mis-information :)

In this one, they talk about 'graphical tools', so I'm CC'ng
pgsql-interfaces@postgresql.org, in the hopes that both
Constantin(pgaccess) and Dave (PgAdmin) will jump into the thread and
answer those questions...

==========
Administration
- graphical tools for
- database administration
- installing the database server
- creating and managing databases
- creating and managing disk devices
- creating and managing users
- creating and managing indicies
- creating and managing stored procedures
- backup and restore operations
- creating and managing replication links
- Web publishing
- database diagramming tools
- viewing and entering data into database tables
- submitting SQL commands and viewing results
- send a message to all logged-in database users
- database perforformance tuning
- configuring server engine options
- viewing the SQL commands currently executing
- detecting resource-intensive queries
- killing selected queries
- graphing overall server engine statistics
- single statement graphical execution plan display
- SQL rewrite suggestions for a single SQL statement
- index suggestions for a single SQL statement
- index suggestions for overall server (based on actual usage)
- pre-calculation (summary table) suggestions (based on actual usage)
- baselining and then tracking server performance over time
- administration tools can be run from a 4.x Web browser
- data file import and export tools
- for ASCII text files
- for native format database data files
- database data files can be directly moved from one database to another

- scripting support
- tools have command-line access
- can reverse-engineer database objects to a SQL script
- can reverse-engineer database data to a SQL script
- languages supplied for command scripting
- security
- security audit log of administrator and user activity
- can set security by user or by group
- can set password qualification rules (minimum length, non-repeatabilitity)
- can set permissions on a table or view
- can set permissions on a particular column
- can set permissions on a particular row
- job scheduler
- by time
- by event
- Web publishing
- static Web publishing (one time)
- static Web publishing (scheduled)
- dynamic Web publishing
- Web users can modify query
- documentation
- supply online versions of manuals
- manuals globally searchable

===========================

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 17:18:57 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA67393
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 17:18:13 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (max03-055.enterprise.net [194.72.196.55])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id WAA05154
for <pgsql-hackers@postgresql.org>; Mon, 31 Jan 2000 22:18:10 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id WAA32035
for <pgsql-hackers@postgresql.org>; Mon, 31 Jan 2000 22:18:19 GMT
Message-Id: <200001312218.WAA32035@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: pgsql-hackers@postgresql.org
Subject: Recent RI changes have broken something
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 31 Jan 2000 22:18:19 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>

Does anyone know what is happening here? There is no other user; the
CREATE TABLE is part of a much larger script that was working OK last
Thursday. The script drops and recreates an entire database.

bray=# \d country
        Table "country"
 Attribute |  Type   | Modifier 
-----------+---------+----------
 id        | char(2) | not null
 name      | text    | not null
 region    | text    | 
 telcode   | text    | 
Index: country_pkey
Constraint: (id ~ '[A-Z]{2}'::text)

bray=# create table country_ccy
(
country char(2) references country (id) match full,
ccy char(3) references currency (symbol) match full,
primary key (country, ccy)
)
;
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index
'country_ccy_pkey'
for table 'country_ccy'
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s)
ERROR: RelationClearRelation: relation 21645 modified while in use

bray=# select relname from pg_class where oid = 21645;
relname
---------
country
(1 row)

country was referenced in a previous table's foreign key. In view of
the notes on RelationClearRelation, I am wondering if refcount wasn't
decremented after that table was created.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"My son, if sinners entice thee, consent thou not."
Proverbs 1:10

From bouncefilter Mon Jan 31 18:00:57 2000
Received: from relayer.zd.com (relayer.zd.com [155.40.130.200])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA80653
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 18:00:06 -0500 (EST)
(envelope-from Timothy_Dyck@zd.com)
Received: from mailer.zd.com ([155.40.32.223])
by relayer.zd.com (PMDF V5.2-32 #37280)
with SMTP id <0FP80074Q1EVKX@relayer.zd.com> for
pgsql-hackers@postgresql.org; Mon, 31 Jan 2000 17:35:22 -0500 (EST)
Received: by mailer.zd.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998))
id 85256877.007C24C8 ; Mon, 31 Jan 2000 17:35:58 -0500
Date: Mon, 31 Jan 2000 17:29:05 -0500
From: Timothy Dyck <Timothy_Dyck@zd.com>
Subject: request for tuning suggestions from PC Week Labs
To: pgsql-hackers@postgresql.org
Message-id: <85256877.007C23E2.00@mailer.zd.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
X-Lotus-FromDomain: ZIFF-DAVIS@INET

(This was originally posted on the Admin list where it was suggested it
should be posted to pgsql-hackers.)

Hi all, I'm the database analyst for PC Week and am comparing
PostgreSQL with Inprise's InterBase (which will be open sourced later this
year). I wrote the features list that is circulating around the list right
now by
Marc Fournier.

As part of this project, I'm running a benchmark with a mix of OLTP
and DSS queries in a set of various mixes and at a variety of user loads
(up to 100 concurrent users). I'd like to get your tuning suggestions on
the engine to make sure I am not missing anything.

My test server is a departmental-type machine with two Pentium III 450MHz
CPUs with 512MB of RAM running RedHat Linux 6.1. PGDATA is pointing to a
RAID 5 array and the database is ~40 MB of data before indexing, and so
will fit entirely into the db cache. The OS swapfile is not used at all. I
will be using ODBC to query the database. I compiled with -m486 and am
using a page size of 2KB instead of 8KB as the benchmark is mostly
OLTP-type queries.

1. The biggest performance item I've seen in looking through the mailing
lists is the fsync option. I want to leave this enabled as I don't think a
transactional database should ever lose data. My understanding is that
with it on PG checkpoints after every commit. Is there a way to let the
log grow to a certain size before checkpointing? When fsync is off, how is
data loss possible?

2. Can I move the log to a different spindle from the disks the
database data is on? The manuals seem to indicate the log is actually
part of the datafile itself, which would imply it can't be moved
elsewhere.

3. Any other suggestions are much appreciated.

Regards,
Tim Dyck
Senior Analyst, PC Week Labs
timothy_dyck@zd.com
519-746-4241

From bouncefilter Mon Jan 31 18:49:58 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA98666
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 18:49:45 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id IAA09696; Tue, 01 Feb 2000 08:49:34 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Duplicate index check in btbuild
Date: Tue, 1 Feb 2000 08:55:25 +0900
Message-ID: <000301bf6c46$a4b50320$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <9990.949334457@sss.pgh.pa.us>
Importance: Normal

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

In addition I could find no other place to check
index uniqueness in tuplesort.c .
Seems we have to give up the uniqueness check in comparetup_
index() and have to check it in _bt_buildadd().

Checking index uniqueness in tuplesort is pretty much of a hack,
although kind of cool since it doesn't take any extra comparisons
to do it there. But if we're doing the wrong thing then it has
to be removed.

I'm a little unclear on *why* it's wrong though. Don't we grab an
exclusive lock on a table while building an index for it? (If not,
shouldn't we be doing so?) I don't see how there can be tuples of
uncertain commit state that need to be included in the index.

It's what you pointed out in [[HACKERS] Reproducible vacuum complaint!]
2 months ago.

Oh, I think I see --- you mean that CREATE INDEX needs to make index
entries for tuples that are committed dead but might still be visible
to some running transaction somewhere. Yes, that seems to fit what
I was seeing. VACUUM always complained that there were too few
index entries, never too many.

It looks like btbuild() only indexes tuples that satisfy SnapshotNow,
so this is definitely a potential problem for btree indexes. The other
index types are likely broken in the same way...

Comments anyone? What time qual should btbuild and friends be using,
if not that?

Same phenomenon was found in Marc's recent posting [HACKERS] [6.5.2]
potentially major bug?]. After changing SnapshotNow -> SnapshotAny I tried
and found that comparetup_index() rejects duplicate index tuples.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Jan 31 19:53:59 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA14030
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 19:53:11 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id LAA06023
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 11:51:41 +1100
Message-Id: <3.0.5.32.20000201115330.00d0bc40@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 01 Feb 2000 11:53:30 +1100
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
From: Philip Warner <pjw@rhyme.com.au>
Subject: The Apache Model (was Re: Copyright)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

I received the following from the Apache people:

The financial costs were actually fairly negligible; on
the order of US$500, I believe. Most of the effort went
into discussions about the structure, the bylaws, and the
articles of incorporation. I have raised this topic
to our board of directors, as it *does* seem as though
a case-study Web page might be useful. I've also asked
the treasurer and incorporator to recap the expenses.
Hopefully we will get back to you.. :-)

I'm obviously looking forward to further information, but this at least
sounds hopefull. The costs are not too high, and I presume one could build
on the work they have done on their by-lays and articles, thereby
short-circuiting that process.

What do other people think?

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

From bouncefilter Mon Jan 31 21:04:08 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA33415
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 21:02:59 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA21466;
Mon, 31 Jan 2000 20:48:07 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010148.UAA21466@candle.pha.pa.us>
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <Pine.GSO.4.02A.10001311328290.12762-100000@Hund.DoCS.UU.SE> from
Peter Eisentraut at "Jan 31, 2000 01:30:16 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 31 Jan 2000 20:48:07 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 29 Jan 2000, Bruce Momjian wrote:

However, I can't find any macro that uses this like makeNode does with
its pasteing. I would perhaps move it to a _deadcode directory and see
what happens. Or should we enable it?

Please no more _deadcode. Why do we have CVS?

No one looks in the old cvs versions. Better to have a separate
directory.

(In the same spirit it would also be nice to tag NOT_USED sections with a
version number, so it could be yanked two or three releases past.)

Good idea, but most NOT_USED must be checked to see if there is anything
valuable in there. If not, it can be removed. Age is not the issue.
We have code from Berkeley in NOT_USED because sometimes we may need it.
You can remove it when you understand why it was there, or what it is
doing, and know we will not need it.

We may be able to remove them all someday if some suggests that. They
are usually quite old.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 21:04:04 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA33559
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 21:03:23 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA21476;
Mon, 31 Jan 2000 20:49:45 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010149.UAA21476@candle.pha.pa.us>
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <Pine.BSF.4.21.0001310935390.480-100000@thelab.hub.org> from The
Hermit Hacker at "Jan 31, 2000 09:36:26 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 31 Jan 2000 20:49:45 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 31 Jan 2000, Peter Eisentraut wrote:

On Sat, 29 Jan 2000, Bruce Momjian wrote:

However, I can't find any macro that uses this like makeNode does with
its pasteing. I would perhaps move it to a _deadcode directory and see
what happens. Or should we enable it?

Please no more _deadcode. Why do we have CVS?

(In the same spirit it would also be nice to tag NOT_USED sections with a
version number, so it could be yanked two or three releases past.)

Why not just yank it period? 'cvs diff' will show what was yanked, and
the log message could say just 'yanked NOT_USED code from source tree'...

We will never think to look and find it again if we do that.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 21:03:01 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA33357
for <pgsql-admin@hub.org>; Mon, 31 Jan 2000 21:02:37 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA21533;
Mon, 31 Jan 2000 20:51:55 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010151.UAA21533@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [ADMIN] Attribute 'aggtransfn1' is repeated
In-Reply-To: <Pine.LNX.4.10.10001311506300.27029-200000@kredit.sth.szif.hu>
from Peter Vazsonyi at "Jan 31, 2000 03:13:55 pm"
To: Peter Vazsonyi <neko@kredit.sth.szif.hu>
Date: Mon, 31 Jan 2000 20:51:55 -0500 (EST)
CC: pgsql-admin@hub.org, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Opps... that was simple bug.
I don't understand why works on x86, why not on sparc (gcc?), but this small
patch should correct the error.

Already patched in current tree. Thanks.

On Fri, 28 Jan 2000, Peter Vazsonyi wrote:

[postgres@sun2 pgsql]$ initdb -r $PWD -l /usr/local/pgsql/lib/

We are initializing the database system with username postgres (uid=40).
This user will own all the files and must also own the server process.

Creating template database in /var/lib/pgsql/base/template1
ERROR: Attribute 'aggtransfn1' is repeated
ERROR: Attribute 'aggtransfn1' is repeated

--
nek;(

Content-Description:

[Attachment, skipping...]

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 21:02:00 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA31817
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 21:01:54 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA21581;
Mon, 31 Jan 2000 20:54:27 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010154.UAA21581@candle.pha.pa.us>
Subject: Re: [HACKERS] Another nasty cache problem
In-Reply-To: <9850.949332263@sss.pgh.pa.us> from Tom Lane at "Jan 31,
2000 10:24:23 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 31 Jan 2000 20:54:27 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I am starting to think that Bruce's idea might be the way to go: lock
down any cache entry that's been referenced since the last transaction
start or CommandCounterIncrement, and elog() if it's changed by
invalidation. Then the only coding rule needed is "cached tuples don't
stay valid across CommandCounterIncrement", which is relatively
simple to check for.

Yea, I had a good idea ...

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 21:04:01 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA33433
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 21:03:01 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA21588;
Mon, 31 Jan 2000 20:54:45 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010154.UAA21588@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
In-Reply-To: <Pine.BSF.4.21.0001311125330.480-100000@thelab.hub.org> from The
Hermit Hacker at "Jan 31, 2000 11:26:23 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 31 Jan 2000 20:54:45 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

have to agree ... psql behaviour should be an extension of the backend's
...

Agreed.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 21:04:03 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA33425
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 21:02:59 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA21598;
Mon, 31 Jan 2000 20:55:53 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010155.UAA21598@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
In-Reply-To: <Pine.GSO.4.02A.10001311625250.12762-100000@Hund.DoCS.UU.SE> from
Peter Eisentraut at "Jan 31, 2000 04:29:07 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 31 Jan 2000 20:55:53 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have written so many requests for comments on psql, I don't know. This
handling of names was nowhere documented, so I couldn't have known it. On
the other hand, the current behaviour is documented and consistent with
something at least. I totally see what you're saying and I'm going to try
to address it. But there was noone who said anything about this so far.

I remember general requests for psql comments, but nothing specific. Of
course, my memory may be wrong on this. I do remember some cases in
other areas where you did ask for ideas, and we didn't really offer any.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 21:02:01 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA31728
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 21:01:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA21631;
Mon, 31 Jan 2000 20:58:27 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010158.UAA21631@candle.pha.pa.us>
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <9901.949333324@sss.pgh.pa.us> from Tom Lane at "Jan 31,
2000 10:42:04 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 31 Jan 2000 20:58:27 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I think it would be a bad idea to go around and yank out NOT_USED code
wholesale --- this should be looked at on a case-by-case basis, with
consideration of whether the code might be useful again in future.

But I think I might vote for pruning the _deadcode directories
wholesale. I suspect the files in them are suffering from
irrecoverable bit rot.

I disagree on _deadcode. While the code is rotted, it does implement
some full functions that have no other history, like verion.c for
versioning and xfunc for expensive functions. Yanking them means we can
never know what they did.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 21:03:03 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA33358
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 21:02:38 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA12083;
Mon, 31 Jan 2000 21:02:30 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <20000131191356.B8582@quartz.newn.cam.ac.uk>
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Mon, 31 Jan 2000 19:13:56 +0000"
Date: Mon, 31 Jan 2000 21:02:30 -0500
Message-ID: <12080.949370550@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

Tom Lane wrote:

I'm down to the point where the parallel tests mostly work with a small
SI buffer --- but they do still sometimes fail.

Have you committed your changes? I tried the parallel tests with cvs
of around 5pm GMT 31 Jan, and they were all fine (I just ran out of
procs at one point). This is much better than last week! Thanks!

Yes, I committed what I had last night (about 04:35 GMT 1/31).

There are cache-flush-related bugs still left to deal with, but they
seem to be far lower in probability than the ones squashed so far.
I'm finding that even with MAXNUMMESSAGES set to 8, the parallel tests
usually pass; so it seems we need some other way of testing to nail down
the remaining problems.

I also tried that nonsensical join from the other day, and it failed in
the same way again:
newnham=# select * from crsids,"tblPerson" where
newnham-# crsids.crsid != "tblPerson"."CRSID";
Backend sent B message without prior T

Hmm. Can you provide a self-contained test case (a script to build the
failing tables, preferably)?

regards, tom lane

From bouncefilter Mon Jan 31 21:05:01 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA33676
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 21:04:07 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA02166;
Mon, 31 Jan 2000 22:03:41 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 22:03:41 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <200002010158.UAA21631@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001312202400.411-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 31 Jan 2000, Bruce Momjian wrote:

I think it would be a bad idea to go around and yank out NOT_USED code
wholesale --- this should be looked at on a case-by-case basis, with
consideration of whether the code might be useful again in future.

But I think I might vote for pruning the _deadcode directories
wholesale. I suspect the files in them are suffering from
irrecoverable bit rot.

I disagree on _deadcode. While the code is rotted, it does implement
some full functions that have no other history, like verion.c for
versioning and xfunc for expensive functions. Yanking them means we can
never know what they did.

even 'yanked' code is still in the cvs repository ... is it something that
ppl actually refer to, or are just afraid of possibly needing/wanting to
go back and look at it? maybe just add a '.readme' file to a subdirectory
to note files that were removed or something like that?

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 21:04:59 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA33792
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 21:04:35 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA12118;
Mon, 31 Jan 2000 21:04:31 -0500 (EST)
To: Ed Loehr <eloehr@austin.rr.com>
cc: pghackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] float4 confused as int??
In-reply-to: <3895EB10.CC9EC4A9@austin.rr.com>
References: <3894B51F.A9D35D2D@austin.rr.com> <38951455.28A436A@austin.rr.com>
<3895EB10.CC9EC4A9@austin.rr.com>
Comments: In-reply-to Ed Loehr <eloehr@austin.rr.com>
message dated "Mon, 31 Jan 2000 14:05:36 -0600"
Date: Mon, 31 Jan 2000 21:04:31 -0500
Message-ID: <12115.949370671@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ed Loehr <eloehr@austin.rr.com> writes:

The problem is occurring with a database that was restored with psql
from a pg_dump (6.5.2).

If I dump the problem table, then drop/recreate it with my original
table creation commands, and then reload with only the insert commands
from the pg_dump'ed file, it reloads and allows updating of the float
field without a problem.

OK. Almost certainly, the data in the table is of no consequence;
the table schema is what matters. What are your original table
creation commands, and what does pg_dump emit?

regards, tom lane

From bouncefilter Mon Jan 31 21:07:59 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA34227
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 21:07:02 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA12137;
Mon, 31 Jan 2000 21:06:45 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Recent RI changes have broken something
In-reply-to: <200001312218.WAA32035@linda.lfix.co.uk>
References: <200001312218.WAA32035@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Mon, 31 Jan 2000 22:18:19 +0000"
Date: Mon, 31 Jan 2000 21:06:45 -0500
Message-ID: <12134.949370805@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Oliver Elphick" <olly@lfix.co.uk> writes:

ERROR: RelationClearRelation: relation 21645 modified while in use

This is probably my fault. Can you provide a simple test case?
The two table declarations might be enough.

regards, tom lane

From bouncefilter Mon Jan 31 21:34:00 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA41660
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 21:32:48 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA02441;
Mon, 31 Jan 2000 22:32:19 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 22:32:19 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <200002010148.UAA21466@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001312231540.411-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 31 Jan 2000, Bruce Momjian wrote:

On Sat, 29 Jan 2000, Bruce Momjian wrote:

However, I can't find any macro that uses this like makeNode does with
its pasteing. I would perhaps move it to a _deadcode directory and see
what happens. Or should we enable it?

Please no more _deadcode. Why do we have CVS?

No one looks in the old cvs versions. Better to have a separate
directory.

Does anyone check the _deadcode directory? :) I never even remember its
there until you guys bring it up to move things into it *shrug*

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 21:37:01 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA44609
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 21:36:01 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA22716;
Mon, 31 Jan 2000 21:34:43 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010234.VAA22716@candle.pha.pa.us>
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <Pine.BSF.4.21.0001312231540.411-100000@thelab.hub.org> from The
Hermit Hacker at "Jan 31, 2000 10:32:19 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 31 Jan 2000 21:34:43 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

No one looks in the old cvs versions. Better to have a separate
directory.

Does anyone check the _deadcode directory? :) I never even remember its
there until you guys bring it up to move things into it *shrug*

We have removed some features like expensive functions, versioning and
recipe that were moved there, and could be used if we need them again.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 21:38:01 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA45893
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 21:37:39 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA12316;
Mon, 31 Jan 2000 21:37:32 -0500 (EST)
To: Timothy Dyck <Timothy_Dyck@zd.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] request for tuning suggestions from PC Week Labs
In-reply-to: <85256877.007C23E2.00@mailer.zd.com>
References: <85256877.007C23E2.00@mailer.zd.com>
Comments: In-reply-to Timothy Dyck <Timothy_Dyck@zd.com>
message dated "Mon, 31 Jan 2000 17:29:05 -0500"
Date: Mon, 31 Jan 2000 21:37:32 -0500
Message-ID: <12313.949372652@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Timothy Dyck <Timothy_Dyck@zd.com> writes:

1. The biggest performance item I've seen in looking through the mailing
lists is the fsync option. I want to leave this enabled as I don't think a
transactional database should ever lose data. My understanding is that
with it on PG checkpoints after every commit. Is there a way to let the
log grow to a certain size before checkpointing? When fsync is off, how is
data loss possible?

With fsync on, pgsql does fsync() after every write, which essentially
means you get zero overlap of computation and I/O. Horribly
inefficient.

With fsync off, we don't do the fsync() call. The data is still
pushed out to the Unix kernel at the same times, but the kernel's disk
scheduler has discretion about what order the disk pages actually get
sent to disk in. Also, you get fewer physical writes when several
successive transactions modify the same disk page. On most Unixes this
makes for a vast performance improvement.

The risk scenario here is that the pg_log update saying that your
transaction has committed might get physically written out before
the data pages that contain the actual tuples do. We write the
pg_log page last, of course, but the kernel might reorder the physical
writes.

If the pg_log update gets written, and some but not all of the updated
data pages have been written, and you suffer a system crash, then after
reboot it appears that some but not all of the changes made by your
transaction have "stuck". That counts as data corruption for most
applications.

Note that I'm talking about an actual system crash: power failure,
hardware failure, or kernel failure. A crash of the Postgres backend
does *not* create this hazard. Also note that a crash does not create
a corruption hazard unless pg_log says that the incomplete transaction
committed.

My feeling is that if you have a UPS and a reliable kernel, there is
no meaningful reliability benefit from keeping fsync on --- certainly
not enough to justify the performance hit. The above risk analysis
ignores non-software risk issues, when in fact there are big risks
at the hardware level. One of the more obvious ones is that modern
disk drives do a certain amount of traffic reordering themselves.
If your drive acts like that, I don't see that fsync buys anything
at all, except perhaps protection against kernel crashes. My experience
(on HPUX) is that the kernel's MTBF is little worse than the disk drive's,
so I don't use fsync. YMMV.

2. Can I move the log to a different spindle from the disks the
database data is on? The manuals seem to indicate the log is actually
part of the datafile itself, which would imply it can't be moved
elsewhere.

You could move pg_log to a different drive but it probably wouldn't buy
much. pg_log only contains a commit/no commit flag for each
transaction, not copies of data, so there's not that much traffic there.

People have reported seeing wins from moving indexes on big tables to
separate drives. We don't currently have any nice neat GUI for that,
but you can kluge it with a few symbolic links. Better methods are
under discussion...

regards, tom lane

From bouncefilter Mon Jan 31 21:30:00 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA39640
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 21:29:22 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA01253;
Tue, 1 Feb 2000 02:37:35 GMT
Sender: lockhart@hub.org
Message-ID: <389646EF.6B3724A7@alumni.caltech.edu>
Date: Tue, 01 Feb 2000 02:37:35 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
References: <Pine.GSO.4.02A.10001311625250.12762-100000@Hund.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I totally see what you're saying and I'm going to try
to address it. But there was noone who said anything
about this so far.

OK, an overdue comment: the new psql is great (current and future
discrepencies excepted of course ;)

Thanks for sticking with it Peter; we've already got a good
foundation, and as we stumble across these minor differences in
behavior it will get even closer to an ideal interface.

My current favorite feature: command history across psql sessions.
When testing I can jump in and out of psql after rebuilding the
backend and can just uparrow to my last test command. Nice. And for
this case, I won't complain about a lack of backward compatibility :))

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Mon Jan 31 21:47:00 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA48113
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 21:45:48 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA26171;
Mon, 31 Jan 2000 18:45:09 -0800 (PST)
Message-Id: <3.0.1.32.20000131184303.010667d0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 31 Jan 2000 18:43:03 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <389646EF.6B3724A7@alumni.caltech.edu>
References: <Pine.GSO.4.02A.10001311625250.12762-100000@Hund.DoCS.UU.SE>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:37 AM 2/1/00 +0000, Thomas Lockhart wrote:

My current favorite feature: command history across psql sessions.

Mine...errors referencing file name and line number.

Invaluable when porting over literally thousands of lines of sql
from Oracle.

Well, technically not "invaluable" since I managed to get an
earlier version of this data model ported over 6.5.

So I guess we'll have to settle for "damned valuable".

Psql's MUCH nicer than SQL*Plus, which doesn't seem to be even
dimly aware that it's running on a modern unix system...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Jan 31 21:46:00 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA47930
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 21:45:01 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA02555;
Mon, 31 Jan 2000 22:44:28 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 22:44:28 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
In-Reply-To: <389646EF.6B3724A7@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.21.0001312242590.411-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Personal opinion: I think we are coming across a little harder on Peter
then most of us are intending :( I think we're blowing a few
misconceptions a little out of proportion, which is just fueling things
further ...

Peter, I agree with Thomas about the work you are doing, I just tend to
come across 'strong' when I disagree with something ...

On Tue, 1 Feb 2000, Thomas Lockhart wrote:

I totally see what you're saying and I'm going to try
to address it. But there was noone who said anything
about this so far.

OK, an overdue comment: the new psql is great (current and future
discrepencies excepted of course ;)

Thanks for sticking with it Peter; we've already got a good
foundation, and as we stumble across these minor differences in
behavior it will get even closer to an ideal interface.

My current favorite feature: command history across psql sessions.
When testing I can jump in and out of psql after rebuilding the
backend and can just uparrow to my last test command. Nice. And for
this case, I won't complain about a lack of backward compatibility :))

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

************

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 22:09:21 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA01647
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 22:09:01 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA12423;
Mon, 31 Jan 2000 22:08:34 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-reply-to: <Pine.BSF.4.21.0001312202400.411-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001312202400.411-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Mon, 31 Jan 2000 22:03:41 -0400"
Date: Mon, 31 Jan 2000 22:08:33 -0500
Message-ID: <12420.949374513@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

The Hermit Hacker <scrappy@hub.org> writes:

I disagree on _deadcode. While the code is rotted, it does implement
some full functions that have no other history, like verion.c for
versioning and xfunc for expensive functions. Yanking them means we can
never know what they did.

even 'yanked' code is still in the cvs repository ...

Precisely. Seems to me we ought to think about our code maintenance
methods with knowledge that back versions will be available from CVS.
Keeping stuff in the current tree has some advantages if it's stuff
you think you might want again in the near term, but I think it's
the wrong way to deal with stuff that we're only keeping for historical
purposes. For example, if I wanted to try to understand the xfunc
code, I'd really have to go back to the last version where it worked;
the partially-patched files sitting in _deadcode would most likely be
more confusing than helpful...

regards, tom lane

From bouncefilter Mon Jan 31 22:11:20 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA01928
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 22:10:50 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA02816
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 23:10:34 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 23:10:34 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: reduce pg_hba.conf restrictions ...
Message-ID: <Pine.BSF.4.21.0001312309380.411-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

is there any reason why we can't make the permissions on pg_hba.conf 600
vs 400? the data directory itself is only readable by the 'superuser'...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 22:16:20 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA02505
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 22:15:21 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA23354;
Mon, 31 Jan 2000 22:12:55 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010312.WAA23354@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
In-Reply-To: <3.0.1.32.20000131184303.010667d0@mail.pacifier.com> from Don
Baccus at "Jan 31, 2000 06:43:03 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 31 Jan 2000 22:12:55 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

At 02:37 AM 2/1/00 +0000, Thomas Lockhart wrote:

My current favorite feature: command history across psql sessions.

Mine...errors referencing file name and line number.

Invaluable when porting over literally thousands of lines of sql
from Oracle.

Well, technically not "invaluable" since I managed to get an
earlier version of this data model ported over 6.5.

So I guess we'll have to settle for "damned valuable".

Psql's MUCH nicer than SQL*Plus, which doesn't seem to be even
dimly aware that it's running on a modern unix system...

Yes, many people love psql, and with Peter's additions, it is even
better.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 22:15:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA02466
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 22:15:10 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA12453;
Mon, 31 Jan 2000 22:14:38 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
In-reply-to: <389646EF.6B3724A7@alumni.caltech.edu>
References: <Pine.GSO.4.02A.10001311625250.12762-100000@Hund.DoCS.UU.SE>
<389646EF.6B3724A7@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Tue, 01 Feb 2000 02:37:35 +0000"
Date: Mon, 31 Jan 2000 22:14:38 -0500
Message-ID: <12450.949374878@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

OK, an overdue comment: the new psql is great (current and future
discrepencies excepted of course ;)

Agreed. Peter, you've done a really nice job. We're just holding
you to the standards you've proven yourself capable of meeting ;-)

Seriously, it seems like the culture on this list is mostly that
you can expect to hear about it when you break something, but if
you did good you will know it because no one complains...

regards, tom lane

From bouncefilter Mon Jan 31 22:18:20 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA03015
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 22:18:10 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA02847;
Mon, 31 Jan 2000 23:17:37 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 23:17:37 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <12420.949374513@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001312315290.411-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 31 Jan 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

I disagree on _deadcode. While the code is rotted, it does implement
some full functions that have no other history, like verion.c for
versioning and xfunc for expensive functions. Yanking them means we can
never know what they did.

even 'yanked' code is still in the cvs repository ...

Precisely. Seems to me we ought to think about our code maintenance
methods with knowledge that back versions will be available from CVS.
Keeping stuff in the current tree has some advantages if it's stuff
you think you might want again in the near term, but I think it's
the wrong way to deal with stuff that we're only keeping for historical
purposes. For example, if I wanted to try to understand the xfunc
code, I'd really have to go back to the last version where it worked;
the partially-patched files sitting in _deadcode would most likely be
more confusing than helpful...

have to agree here ... how much of the NOT_USED code is totally irrelevant
based on the changes around it?

Some sort of 'text log' of what is removed and date should be kept, if ppl
want to be able to go back ... basically, instead of 'moved to _deadcode',
just add a line to a text file stating 'function X removed on date Y' so
that ppl have a guide to look at the cvs repository with ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 22:21:20 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA03495
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 22:20:27 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org ([207.144.235.98])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with SMTP id WAA02077;
Mon, 31 Jan 2000 22:20:03 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: The Hermit Hacker <scrappy@hub.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
Date: Mon, 31 Jan 2000 22:17:47 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
References: <Pine.BSF.4.21.0001312242590.411-100000@thelab.hub.org>
In-Reply-To: <Pine.BSF.4.21.0001312242590.411-100000@thelab.hub.org>
MIME-Version: 1.0
Message-Id: <00013122260500.00614@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Mon, 31 Jan 2000, The Hermit Hacker wrote:

Personal opinion: I think we are coming across a little harder on Peter
then most of us are intending :( I think we're blowing a few
misconceptions a little out of proportion, which is just fueling things
further ...

And the subject line doesn't help, IMHO. 'Bogosity' is pretty strong --
'bugosity' might be better.....

However, I understand the possessiveness one gets when one has put forth a
great deal of effort into a major project such as this one.

Peter, I agree with Thomas about the work you are doing, I just tend to
come across 'strong' when I disagree with something ...

The 'e-mail effect' strikes again. Isn't it so much easier to be much harsher
by e-mail than intended? I certainly have noticed that in my decade of being
net-connected (first via a slow as molasses uucp link to usenet, then via an
even slower slip link....). However, this is quite tame compared to, say, the
linux-kernel mailing list..... But, then again, I do believe that the
collective net-age of the developers here is higher than on lk, even if the
list itself is possibly younger.

I say 'kudos' to all the developers who have put in long mostly thankless hours
working on this project -- it _is_ worth it!!

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Mon Jan 31 22:25:20 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA04335
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 22:25:00 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA02916;
Mon, 31 Jan 2000 23:24:25 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 23:24:25 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
In-Reply-To: <00013122260500.00614@lorc.wgcr.org>
Message-ID: <Pine.BSF.4.21.0001312321500.411-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 31 Jan 2000, Lamar Owen wrote:

On Mon, 31 Jan 2000, The Hermit Hacker wrote:

Personal opinion: I think we are coming across a little harder on Peter
then most of us are intending :( I think we're blowing a few
misconceptions a little out of proportion, which is just fueling things
further ...

And the subject line doesn't help, IMHO. 'Bogosity' is pretty strong --
'bugosity' might be better.....

Agreed here too ... I think what has been setting off a lot of the 'red
flags' is a larger then normal number of 'buggy commits' ... stuff that
has to be done, but hasn't been as well thought out/discussed as it should
have been ...

Peter is learning ... in some ways, we threw him into the 'commit arena'
alot faster then we normally would have because of how active/busy he was
... normally, we've waited longer to force the person to get used to how
things operate ... Peter has been getting "on the job training" here :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 22:29:20 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA05147
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 22:28:55 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA23553;
Mon, 31 Jan 2000 22:27:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010327.WAA23553@candle.pha.pa.us>
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To: <12420.949374513@sss.pgh.pa.us> from Tom Lane at "Jan 31,
2000 10:08:33 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 31 Jan 2000 22:27:17 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The Hermit Hacker <scrappy@hub.org> writes:

I disagree on _deadcode. While the code is rotted, it does implement
some full functions that have no other history, like verion.c for
versioning and xfunc for expensive functions. Yanking them means we can
never know what they did.

even 'yanked' code is still in the cvs repository ...

Precisely. Seems to me we ought to think about our code maintenance
methods with knowledge that back versions will be available from CVS.
Keeping stuff in the current tree has some advantages if it's stuff
you think you might want again in the near term, but I think it's
the wrong way to deal with stuff that we're only keeping for historical
purposes. For example, if I wanted to try to understand the xfunc
code, I'd really have to go back to the last version where it worked;
the partially-patched files sitting in _deadcode would most likely be
more confusing than helpful...

Personally, I am willing to yank it all now. I think we understand the
code base well enough that someone who knows the code can go through and
quickly identify the 90% of NOT_USED that is just junk and remove it.
Tom Lane, you are the only person I know who can do this. Sorry.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 22:31:20 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id WAA06954
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 22:30:39 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 29155 invoked by uid 1001); 1 Feb 2000 03:30:34 -0000
Message-ID: <XFMail.000131223034.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.BSF.4.21.0001312309380.411-100000@thelab.hub.org>
Date: Mon, 31 Jan 2000 22:30:34 -0500 (EST)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: The Hermit Hacker <scrappy@hub.org>
Subject: RE: [HACKERS] reduce pg_hba.conf restrictions ...
Cc: pgsql-hackers@postgreSQL.org

On 01-Feb-00 The Hermit Hacker wrote:

is there any reason why we can't make the permissions on pg_hba.conf 600
vs 400? the data directory itself is only readable by the 'superuser'...

Depends on what you edit with. If you use vi you can override the perms,
if you use ee (like I do) you swear alot then change them yourself :)

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Mon Jan 31 22:35:20 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA10044
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 22:34:25 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA03041;
Mon, 31 Jan 2000 23:34:07 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 31 Jan 2000 23:34:07 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Vince Vielhaber <vev@michvhf.com>
cc: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] reduce pg_hba.conf restrictions ...
In-Reply-To: <XFMail.000131223034.vev@michvhf.com>
Message-ID: <Pine.BSF.4.21.0001312333400.411-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 31 Jan 2000, Vince Vielhaber wrote:

On 01-Feb-00 The Hermit Hacker wrote:

is there any reason why we can't make the permissions on pg_hba.conf 600
vs 400? the data directory itself is only readable by the 'superuser'...

Depends on what you edit with. If you use vi you can override the perms,
if you use ee (like I do) you swear alot then change them yourself :)

I use vi and "swear alot then change them yourself" :)

but, why are we bothering to swear instead of just changing them, is my
question :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Jan 31 22:39:20 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA11216
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 22:38:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA23707;
Mon, 31 Jan 2000 22:37:19 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010337.WAA23707@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
In-Reply-To: <12450.949374878@sss.pgh.pa.us> from Tom Lane at "Jan 31,
2000 10:14:38 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 31 Jan 2000 22:37:19 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

OK, an overdue comment: the new psql is great (current and future
discrepencies excepted of course ;)

Agreed. Peter, you've done a really nice job. We're just holding
you to the standards you've proven yourself capable of meeting ;-)

Seriously, it seems like the culture on this list is mostly that
you can expect to hear about it when you break something, but if
you did good you will know it because no one complains...

That should not be the case. How hard is it to e-mail nice things? We
need to do better in this area.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 22:40:20 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA11520
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 22:40:11 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA23723;
Mon, 31 Jan 2000 22:38:03 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002010338.WAA23723@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
In-Reply-To: <Pine.BSF.4.21.0001312321500.411-100000@thelab.hub.org> from The
Hermit Hacker at "Jan 31, 2000 11:24:25 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 31 Jan 2000 22:38:02 -0500 (EST)
CC: Lamar Owen <lamar.owen@wgcr.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Peter is learning ... in some ways, we threw him into the 'commit arena'
alot faster then we normally would have because of how active/busy he was
... normally, we've waited longer to force the person to get used to how
things operate ... Peter has been getting "on the job training" here :)

Agreed. Stick it out, Peter.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Jan 31 22:44:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA12460
for <pgsql-hackers@postgresql.org>;
Mon, 31 Jan 2000 22:43:37 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA12635;
Mon, 31 Jan 2000 22:43:24 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] reduce pg_hba.conf restrictions ...
In-reply-to: <Pine.BSF.4.21.0001312309380.411-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001312309380.411-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Mon, 31 Jan 2000 23:10:34 -0400"
Date: Mon, 31 Jan 2000 22:43:24 -0500
Message-ID: <12632.949376604@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

The Hermit Hacker <scrappy@hub.org> writes:

is there any reason why we can't make the permissions on pg_hba.conf 600
vs 400? the data directory itself is only readable by the 'superuser'...

I think the motivation may have been to prevent an attacker who manages
to connect as superuser from overwriting the pg_hba.conf file with
something more liberal (using backend-side COPY). However, if he's
already managed to connect as superuser, it's difficult to see what
he needs more-liberal connection privileges for.

600 does seem a lot more convenient for the admin. 400 might save
the admin from some simple kinds of human error --- but not if he's
already in the habit of overriding the protection whenever he updates
the file.

In short, I agree. Does anyone else see any real security gain from
making it 400?

regards, tom lane

From bouncefilter Mon Jan 31 22:53:21 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA14889
for <pgsql-hackers@postgreSQL.org>;
Mon, 31 Jan 2000 22:53:12 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA12672;
Mon, 31 Jan 2000 22:52:38 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
In-reply-to: <200002010327.WAA23553@candle.pha.pa.us>
References: <200002010327.WAA23553@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 31 Jan 2000 22:27:17 -0500"
Date: Mon, 31 Jan 2000 22:52:37 -0500
Message-ID: <12669.949377157@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Personally, I am willing to yank it all now. I think we understand the
code base well enough that someone who knows the code can go through and
quickly identify the 90% of NOT_USED that is just junk and remove it.
Tom Lane, you are the only person I know who can do this. Sorry.

Moi? There are parts I understand well, and other parts not.
In any case I don't have time now to make such a sweep.

What I'd suggest is that we all just modify our operating procedures
a little. Any time you have studied a bit of code long enough to be
pretty sure you understand how it works, feel free to cut out any
NOT_USED segments that you can't see any prospect of wanting again.

I've already been applying this philosophy to some extent in modules
that I've worked on, but I will try to do it on a regular basis from
here on. If we all do it, that should eliminate the useless stuff
over time.

Next question is what to do about the _deadcode subdirectories.
For the most part I don't even know what's in 'em ... do you?

regards, tom lane

From bouncefilter Tue Feb 1 00:23:21 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA41721
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 00:22:38 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA19392;
Mon, 31 Jan 2000 21:21:06 -0800 (PST)
Message-Id: <3.0.1.32.20000131205943.01066c60@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 31 Jan 2000 20:59:43 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
Cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <12450.949374878@sss.pgh.pa.us>
References: <389646EF.6B3724A7@alumni.caltech.edu>
<Pine.GSO.4.02A.10001311625250.12762-100000@Hund.DoCS.UU.SE>
<389646EF.6B3724A7@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:14 PM 1/31/00 -0500, Tom Lane wrote:

Seriously, it seems like the culture on this list is mostly that
you can expect to hear about it when you break something, but if
you did good you will know it because no one complains...

Has it ever been different with any group of talented people?

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Tue Feb 1 00:25:22 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA41783
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 00:23:02 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA19403;
Mon, 31 Jan 2000 21:21:07 -0800 (PST)
Message-Id: <3.0.1.32.20000131210928.0106fc90@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 31 Jan 2000 21:09:28 -0800
To: The Hermit Hacker <scrappy@hub.org>, Lamar Owen <lamar.owen@wgcr.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <Pine.BSF.4.21.0001312321500.411-100000@thelab.hub.org>
References: <00013122260500.00614@lorc.wgcr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:24 PM 1/31/00 -0400, The Hermit Hacker wrote:

On Mon, 31 Jan 2000, Lamar Owen wrote:

Agreed here too ... I think what has been setting off a lot of the 'red
flags' is a larger then normal number of 'buggy commits' ... stuff that
has to be done, but hasn't been as well thought out/discussed as it should
have been ...

I think a LOT of it had to do with its being committed to the 7.0
sources, which at the time were supposedly going to be released on
Feb 1 (tomorrow).

If Peter had waited until 7.0 beta then dumped such changes into a new,
7.1 tree with 7.1 some months off I doubt there would've been anything
like the reaction he saw.

Didn't we all agree recently that this had to do mostly with Peter's
misunderstanding of how stable a beta release should be in this project?

(as opposed to other projects which run with a "release early, release
often" pardigm)?

If so, I think we're done with this topic and should be willing to just
let it drop.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Tue Feb 1 02:50:22 2000
Received: from loopy.berkhirt.com (loopy.berkhirt.com [209.220.85.54])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA75839
for <pgsql-hackers@postgresql.org>; Tue, 1 Feb 2000 02:49:24 -0500 (EST)
(envelope-from bhirt@loopy.berkhirt.com)
Received: (from bhirt@localhost)
by loopy.berkhirt.com (8.9.3/8.8.7) id BAA10296;
Tue, 1 Feb 2000 01:48:54 -0600
Date: Tue, 1 Feb 2000 01:48:54 -0600
From: Brian Hirt <bhirt@mobygames.com>
To: pgsql-hackers@postgresql.org
Cc: Brian Hirt <bhirt@loopy.berkhirt.com>
Subject: union in an in clause and timestamp
Message-ID: <20000201014854.A10211@loopy.berkhirt.com>
Reply-To: bhirt@mobygames.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
X-PC-Gaming: http://www.mobygames.com/

Okay, I'm running into two things that I would expect to work.
I've included a simple test case for both to reproduce the problem.

1) Obviously, the first two work and the third does not.
are these bugs?

2) Cannot create index on timestamp colmun

basement=> select version();
version
-------------------------------------------------------------------
PostgreSQL 6.5.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
(1 row)
basement=> select 'hello' where 1 in (select 1);
?column?
--------
hello
(1 row)
basement=> select 'hello' where 1 in (select 2);
?column?
--------
(0 rows)
basement=> select 'hello' where 1 in (select 2 union select 1);
ERROR: parser: parse error at or near "union"
basement=>

And then, I find that I cannot create an index on a
timestamp column;

basement=> create table ts (t timestamp);
CREATE
basement=> create index ttt on ts(t);
ERROR: Can't find a default operator class for type 1296.
basement=>

--
The world's most ambitious and comprehensive PC game database project.

http://www.mobygames.com

From bouncefilter Tue Feb 1 06:14:25 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA24198
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 06:13:26 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id TAA27381
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 19:36:27 +1100
Sender: chris@tech.com.au
Message-ID: <38969B09.CE50E219@bitmead.com>
Date: Tue, 01 Feb 2000 19:36:25 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: majordomo
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oops, I think my majordomo problems are caused by me. Ignore previous
message.

From bouncefilter Tue Feb 1 05:22:26 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA07804
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 05:22:20 -0500 (EST)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (max05-009.enterprise.net [194.72.197.9])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id JAA09642;
Tue, 1 Feb 2000 09:29:30 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id JAA06616;
Tue, 1 Feb 2000 09:29:31 GMT
Message-Id: <200002010929.JAA06616@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: "Oliver Elphick" <olly@lfix.co.uk>, pgsql-hackers@postgreSQL.org,
olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Recent RI changes have broken something
In-Reply-To: Message from Tom Lane <tgl@sss.pgh.pa.us>
of "Mon, 31 Jan 2000 21:06:45 EST." <12134.949370805@sss.pgh.pa.us>
References: <200001312218.WAA32035@linda.lfix.co.uk>
<12134.949370805@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: multipart/mixed ;
boundary="==_Exmh_7146474070"
Date: Tue, 01 Feb 2000 09:29:31 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>

This is a multipart MIME message.

--==_Exmh_7146474070
Content-Type: text/plain; charset=us-ascii

Tom Lane wrote:

"Oliver Elphick" <olly@lfix.co.uk> writes:

ERROR: RelationClearRelation: relation 21645 modified while in use

This is probably my fault. Can you provide a simple test case?
The two table declarations might be enough.

They seem to need to have the data loaded too. The attached gzipped
tar is the minimum extract that will trigger the bug. It contains
one example script (psql -d template1 -e <example) and 2 data files.
You will have to amend the script to put in the correct path of the
data files for your backend to find them.

--==_Exmh_7146474070
Content-Type: application/x-gzip ; name="example.tar.gz"
Content-Description: example.tar.gz
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="example.tar.gz"

H4sIAHaeljgAA+1aSY/cNhb2lfwVurUNJEbtC4I5UBJLYmmhmqKqLE0GQbtdnhhpdxvt9iDG
YOa3z0dJVaWlOpmLE8xA75C4+D0ub+FbqD78evPx093hxbek0Xg0WsxmL0aj0Xg5HzX/b2g8
Gy1ejJaj2Xw+XiwXGB+Px8vRC2v0TU9V05fPTzePlvXi4e7u62/x/R7+P0q3j4ebp4P17ubp
5u3N54P19vHm6w/0x9uH+/vD7VP5k9KaCSx3B+v2y+Pj4f72K31JyeevH98+3BFy+/PN48vp
K0I+PX74ePP41frl8PU7Sj58frj/8pGQD/dPE0IwcH/z8UDI0+HXJ0LuH56s+y93dxj+dHdz
e/jp7eH9w+OBvH0wKx5RSgy9O7y/+XL3ZF09XYH93eEWu9x9Nus+xzmpft7+fLj9xXp5nGH9
xRpZD49W4/fkFX1Ff+jK+PDl/umxFPHDu1q8SVu81vof3ln/tq7+yr4v/vbPyb+uXj0v6uPh
7x8e7isAP58Od7cP72rG+iAPn74eD2C9f3z4aF3Vv14bK111z3r48vjw6fC7R7Vqejy8Pxj7
HT6fNsHxX1kfb55uf7beV6f8x83TT5/A+eHX84InPZ9PWW1dH7L6cfmM9U4/3VZuU/9snPa/
OhVmN1ytOaV2Setl5ZCdeQ1VWC/r5b+zsFptekr/7Fv451HTtb7VHr8d/8eLsYn5Vfxf4jf4
J8gJQ/z/I4htCNt4PotFqllMWCoYWU8pCwkLbYwywjMlE25xlmoync+pWwDyuALENko4zIql
0j6ZjDEtJSziZjC2UhZJRhLmiI1wLOlwLL9YzShzCYtdqdRp6T03Sy8XlElAngxPK6cyMyvP
MEsYKBMhQMNvidgVPCVjazVaU3YNVDPlaMw6/5MslhPKPDMgvIxZ2NeymbIz9+IiijDlcfDG
7ChGfYI5DhABjbjRiFGS5bDMYWmW4uAA9wAzu73qZL2kLCMsS7VioZlX/avU8WJMma5GRFsR
M6gRKi64spnY1jY5b7dez6idEpv5LIK6+2LYvgEVE/XMSLhuWNtvvZxS2wUeeyFzeepXLGY+
NlqtRtS2idEQc+XFtXNi8xCipm23WM6pzQ3kiSxqm3VC7cIgouBdpY7G1N4Ci81RK4OXcyYT
7BQBUNFlS9ma2H529lezvSS2DMVO9Ey3xi4MYArTlR7gc1VwT+6NmVtSrJbU3oNTp3sWd31w
AXAHMNtxnCYNsdLZ0aitiK1YIcLu7nMqcDIltEj9Ws/VXbA0VxiWKifNYfJjTO0YM7KYC8s1
qk7hMlFlqHLR78vTLowpPWJnocdU75pCRxtgKoCQ1oalsqPgBbWFwTNsfYQcuD7ck0zmSxr4
xGGRLd2juzd2XkEoJzI4V1J2TDddUtxA3H/mni1RBYgxdXZAcMgdVy7vzFvRIAeaR9BEpd5L
DuhsSH1Mq5oeW4onmR3isnfFmC6odonjm4DThSBBCEiEPadcUCc2SFwLXomM0TcYVYiSuHVH
+3eCG4KN4xBHOjK1XgYcPh97r07CXGCWYA5lZPedFhaAhmUkFe5hyz8mC2jBA4ZA2Q2TWDIA
IoPnNl2BQ4EDsd5SZaistz1qZj6CpAIcmlvu1ZXYSaE6lprMqY81lGS663YrqDUjTjcQzqfU
gW3zpBE3qiNPIahTEKfgjn82ZHNNyOQGxOVxxFTQjpNIRVvibgXupD45cTlpgh3diLgyErGR
su9HrjyhDQ/q8+mEmBUtLWCK7k2gHGd1MsRK1Qs6U8o9wr080Z0sOaLpjvAQ6THctWaeTTCl
3jXh1xlDdBDwdKS9mLO2FWYjyhXBTK3OUCU8Ah7nBFyyl77hdFwTrn0hE9GZNh/TTUA2LAyM
65w8qBTIYjo0SdTB6UZ0I8GmJD/xlKKdeSbrFd1syUZsRc/r13QjgMTl/anPVmlmOscsRTaK
xQ5v5xAoZAOAx/ASKIP18zOSYnJiSWSYx9xkhq77w6AnrnImV+dAbKzenoBY7DHiMbsb5WZj
6kUAqqvbuh0j6nHicam8XqWwXsNlDagQ5PK2M6+p5xNTh3XWM7IL4glklxDJpq2XOTZTxFOc
nzVWXywgYYlUmu5ZCPu5Bi/jdN/vvYSgYHJ5KLOEty/zGktnBo16xoVWtEE0j1jYs9FoQr2Y
XHLmyYx6+xr53hbIeFlH33Pq5WDIL5l+Qn1NfIYU2z4oxPAj4nOm3DLvR47lypiFHd82LnAy
tx8TX8Zups6V7On4M+oHBvWsAP9pZoc5jpARP4uRivP2jVtQgQDu8EtWmKKsROlThvdWIYYb
LFwzLis37uX+CRWKCMUulXgrKq4Ndn0BW2BDDpA3r1/tS1OK6kWkivHwUuGILTURmoV5x9PW
dBuRLYrRy5F2mwBMjiet9DWmW0m2UrkXBYB0QUECVrDAPzclyIicBDzOu2FrRgNBAqGEjYTU
u/ELGiS13gNZhsqG2UY0UHWA64E4xJ4E2R5+demMcxp4JMiVlxfNM8LrQyathMsk5FdXqeXy
SDoKJ3MahUqvoFrQcIeJencO2HVQxJ0KbRJylOzyorKAp8BTqf1uPbDAsoqEwm42a3VYwbTc
QLhRFlPMtowFfWgx77V1KxoKsCJFax6nmsNlW6FrbKH+DjVYtJ81W8ajCCMaZiTM3nAUlJny
On43oZEkEXPMnW/YZkqjwAxzt5nGap9DII88oC7zWOogLHZKpDGN9sTEoL3o6mROo7yE8os3
a0SjnYFdseOdymttwNCAohO+cFZtxnX3nDBs5ANRqc/C8LmqDBEsujZc6DzFddaNt1hDAc2Q
pErtts0zweSshkXWLRaRB3JztFxqzfuFZPSGRPyNQCHaq0ImdBORSKDOu5hKEaIil0QydOWu
W2RAHQ6gmGHddh63UBdFscHQ5YvmfVuj/Y9Sg+gU+Ri9cT+URIyYgthxZNdFoYMCWGESslFg
2+YoLCLIAlePWK+II0jKSCoxi0QjmR+9ZUZjBQyNUi/ZAUJk4QkLj13oksYhRkxKqezcEh4N
f9xELZMEQtzcjrnXNHbAt0fdENbO3w1q2KgoWQrOqka0+bKAgwliKlvFkIsv1JcQmIMBdUjH
j7GuVwG9eIFFM0DQbfcwUxpvTITdyDB4vjGK6ihssm1kGlb0pc91RiMaS8O9Z3k7lMyWVEZE
RpfTxoomAdYKzi9Zp3w6ockeUMh6ZlyNaGIUDPtfUtWSJh7QJIOvQd/H4qWpbgS/JAdPqe28
V50Ahc44HKiDjGnikwQtqEgSrNpTw5QmMUmEdphQcRdEvZiEBIVuI49X/RK0oAEonXmQoB1q
saUiScaVlqb9kxfu2DUj10wfr0m7BJhR9IKKZ7GQcTeWTKiSRBnTdHoONCqQ3TxjGPYNd7nJ
hjJuMS2p2hPYO3ZZ/zUCWTomKROxtgKhdVoWczHfiUsPBKFTs4aZIy7VI7sjw07EZo9yNfil
VRXDpSX6s/YoFi++Z85pGgGqnDqWnfi/XFFIl6Ii0DLi5VYJ2ByRdJ8/1jRlYMxcUabjY2xs
e/iCptAEj7kxbfvqjmkKwXju+LyMKW3zwCvSkKTCRFYr5Ajpne0nNPWAo4CF6/B+WoSYAUlD
xPqga19MFSXEe+0mqq/URoEVSsT1Z6/7kqYSTFH1Rtqq7Sa0YMcOdFM9WLTi85J6xw61brlO
5qxGYRl3L9DtPdPOouSHstKEdYoaxLsQAithgTHoVOczmvok1a8t6Bo+011zgg4piUqGxGi8
sntkElMIv+80AfMRbOOSNCuL4ab0uOMpylMkdgSn3jvVGmrbknRnnunrBmdbumHOz6quXicr
TdO0IOnevFGWGaOd53AGDhS3M+6E3AV1IOxe6KLKW53aj6Y5SXMTz6sysl3ktt13SvWeaCb2
7W4AXqK3GN+KRuhGSNAFBuOiWfPUbjGnOJlGy1eJ0nVWrOcRLb3uo+eK6gDjAe/lAaolAHh/
zzmxliYaJhAuq7Sspc28S6FTx0QjNqb9DyNYRAFTAc+r0yKJqForI6qjEjPfFlriO+VwFe6Q
BMyr4vMPo3oHbjhDP8GtaOYRJINGbK3VuKAoD7LAfCrgnYs7oowTCKO5W9mVR2gpNba7kBfQ
9ttH5gAxxJXtbwCzGUVhWjNAxHKZztNwlhMUWRczKAQoSFbYvO0eu4zsWJwx3S/NVhQ16c40
XXBLR+h+y7rjBPGKF7iSvQcFzI7JTnBtxRfe3VczuvMAI9ic7pn1sn7hf9W3jIVrvBO9Cdnr
9PUFbrrfkD1aBVGZfZPBo54tlNBHc79cw1RVKfNhqZbr0ZyTnMOxLt3GJc0zkmeexOK7XuQe
00KRgjVef08JeTalRUSK1uPXCUSPVOxJISKb2ftuIY4I8Gd/7xyoTY2/2vhme/zO33+ZPwDr
fP8fLyfT4fv/H0FotIui+nhr3qZdXn5uCUxVxFPzVg+0fJU3Md6zzXszD8tHRF49CFZvO6bj
B6fpf8OyAdGmoMDIny3fQAMNNNBAAw000EADDTTQQAMNNNBAAw000EADDTTQQAMNNNBAAw00
0EADDTTQQAP9P9J/ACzeRLQAUAAA

--==_Exmh_7146474070
Content-Type: text/plain; charset=us-ascii

Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"And be not conformed to this world; but be ye
transformed by the renewing of your mind, that ye may
prove what is that good, and acceptable, and perfect,
will of God." Romans 12:2

--==_Exmh_7146474070--

From bouncefilter Tue Feb 1 07:15:25 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA39107
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 07:14:40 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id XAA03816
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 23:14:33 +1100
Sender: chris@tech.com.au
Message-ID: <3896CE29.BFAB1547@bitmead.com>
Date: Tue, 01 Feb 2000 23:14:33 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Problem in current CVS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Just downloaded a completely fresh cvs copy. When I
do initdb...

This user will own all the files and must also own the server process.

Creating Postgres database system directory /home/pghack/pgsql/data

Creating Postgres database system directory /home/pghack/pgsql/data/base

Creating template database in /home/pghack/pgsql/data/base/template1
ERROR: Error: unknown type 'oidvector'.

ERROR: Error: unknown type 'oidvector'.

syntax error 12 : parse errorinitdb: could not create template
database

From bouncefilter Tue Feb 1 08:23:29 2000
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA56592
for <pgsql-hackers@postgresql.org>; Tue, 1 Feb 2000 08:22:37 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id OAA00933;
Tue, 1 Feb 2000 14:21:00 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 12Fe5k-00013B-00; Tue, 1 Feb 2000 14:15:40 +0000
Message-ID: <3896DD49.26143978@sferacarta.com>
Date: Tue, 01 Feb 2000 14:19:05 +0100
From: Jose Soares <jose@sferacarta.com>
Organization: Sfera Carta
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Jan Wieck <wieck@debis.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] END/ABORT
References: <200001281837.NAA01003@candle.pha.pa.us>
<3.0.1.32.20000131094558.00f068ac@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

At 09:41 AM 1/31/00 +0100, Jan Wieck wrote:

Of course, removing END/ABORT will touch many applications
using transactions, but I would vote for it anyway, since
it's standard.

Does it make all that much sense to worry about the actual word
used when the need to use "begin" is non-standard to begin with?

There is no explicit "BEGIN WORK" on SQL92, transaction initiation
is always implicit and it terminates either with a COMMIT or a
ROLLBACK
statement.

Of course, removing that would REALLY impact current applications...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

************

--
Jose' Soares
Bologna, Italy Jose@sferacarta.com

From bouncefilter Tue Feb 1 08:54:27 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA66460
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 08:54:18 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
IAA15802;
Tue, 1 Feb 2000 08:47:43 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002011347.IAA15802@candle.pha.pa.us>
Subject: Re: [HACKERS] Problem in current CVS
In-Reply-To: <3896CE29.BFAB1547@bitmead.com> from Chris at "Feb 1,
2000 11:14:33 pm"
To: Chris <chris@bitmead.com>
Date: Tue, 1 Feb 2000 08:47:43 -0500 (EST)
CC: Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Did you do a 'make clean'?

Just downloaded a completely fresh cvs copy. When I
do initdb...

This user will own all the files and must also own the server process.

Creating Postgres database system directory /home/pghack/pgsql/data

Creating Postgres database system directory /home/pghack/pgsql/data/base

Creating template database in /home/pghack/pgsql/data/base/template1
ERROR: Error: unknown type 'oidvector'.

ERROR: Error: unknown type 'oidvector'.

syntax error 12 : parse errorinitdb: could not create template
database

************

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 1 09:07:27 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA72539
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 09:07:04 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id BAA05575
for <hackers@postgreSQL.org>; Wed, 2 Feb 2000 01:06:55 +1100
Sender: chris@tech.com.au
Message-ID: <3896E87A.37F6C600@bitmead.com>
Date: Wed, 02 Feb 2000 01:06:50 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Problem in current CVS
References: <200002011347.IAA15802@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Did you do a 'make clean'?

Oops, my different installations are getting mixed up. My fault.

Just downloaded a completely fresh cvs copy. When I
do initdb...

This user will own all the files and must also own the server process.

Creating Postgres database system directory /home/pghack/pgsql/data

Creating Postgres database system directory /home/pghack/pgsql/data/base

Creating template database in /home/pghack/pgsql/data/base/template1
ERROR: Error: unknown type 'oidvector'.

ERROR: Error: unknown type 'oidvector'.

syntax error 12 : parse errorinitdb: could not create template
database

************

--
Bruce Momjian                        |  http://www.op.net/~candle
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

--
Chris Bitmead
mailto:chris@bitmead.com
http://www.techphoto.org - Photography News, Stuff that Matters

From bouncefilter Tue Feb 1 10:05:28 2000
Received: from redbox.venux.net (redbox.venux.net [216.47.238.10])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90455
for <hackers@postgresql.org>; Tue, 1 Feb 2000 10:04:54 -0500 (EST)
(envelope-from mitch@venux.net)
Received: from inky (inky.venux.net [216.47.238.64])
by redbox.venux.net (Postfix) with SMTP id C5E442E20B
for <hackers@postgresql.org>; Tue, 1 Feb 2000 09:56:05 -0500 (EST)
Message-ID: <022201bf6cc6$20e3fd00$40ee2fd8@venux.net>
From: "Mitch Vincent" <mitch@venux.net>
To: "Postgres Hackers List" <hackers@postgresql.org>
References: <200002011347.IAA15802@candle.pha.pa.us>
Subject: plpgsql problem..
Date: Tue, 1 Feb 2000 10:07:59 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

The strangest thing started happening on one of my boxes today running
Postgre.

I'm using a function to total up values in a table.. The exact same code is
on our development and live server yet on the live server I get :

ERROR: stat failed on file '${exec_prefix}/lib/plpgsql.so': No such file or
directory

Anytime the function is called.

The plpgsql.so library is in the exact same place on both machine with the
exact same permissions.

I can't find any reference to the $exec_prefix variable on either machine,
yet it works on the development server and not on the live server.

Thanks for *any* hints, help or ideas.

-Mitch

From bouncefilter Tue Feb 1 10:24:28 2000
Received: from andie.ip23.net (andie.ip23.net [212.83.32.23])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA94212
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 10:24:06 -0500 (EST)
(envelope-from sevo@ip23.net)
Received: from imap1.ip23.net (imap1.ip23.net [212.83.32.35])
by andie.ip23.net (8.9.3/8.9.3) with ESMTP id QAA16690;
Tue, 1 Feb 2000 16:23:31 +0100 (CET)
Received: from ip23.net (spc.ip23.net [212.83.32.122])
by imap1.ip23.net (8.9.3/8.9.3) with ESMTP id QAA09769;
Tue, 1 Feb 2000 16:24:55 +0100 (CET)
Sender: sevo@imap1.ip23.net
Message-ID: <3896FBA1.38A5F87@ip23.net>
Date: Tue, 01 Feb 2000 16:28:33 +0100
From: Sevo Stille <sevo@ip23.net>
Organization: IP23
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Mitch Vincent <mitch@venux.net>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] plpgsql problem..
References: <200002011347.IAA15802@candle.pha.pa.us>
<022201bf6cc6$20e3fd00$40ee2fd8@venux.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mitch Vincent wrote:

ERROR: stat failed on file '${exec_prefix}/lib/plpgsql.so': No such file or
directory

I can't find any reference to the $exec_prefix variable on either machine,
yet it works on the development server and not on the live server.

PostgreSQL does not expand environment variables when looking for
function code. Presumably your installer is broken and did not
substitute the variable at install time on the affected system. You
might dump your function catalog on both systems to compare - if the
function path on the sane system contains a variable as well, there is
some strange magic going on there.

Sevo

From bouncefilter Tue Feb 1 10:28:28 2000
Received: from redbox.venux.net (redbox.venux.net [216.47.238.10])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA94957
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 10:28:02 -0500 (EST)
(envelope-from mitch@venux.net)
Received: from inky (inky.venux.net [216.47.238.64])
by redbox.venux.net (Postfix) with SMTP
id 6182F2E20B; Tue, 1 Feb 2000 10:19:14 -0500 (EST)
Message-ID: <023201bf6cc9$5c941c60$40ee2fd8@venux.net>
From: "Mitch Vincent" <mitch@venux.net>
To: <hackers@postgreSQL.org>
Cc: <sevo@ip23.net>
References: <200002011347.IAA15802@candle.pha.pa.us>
<022201bf6cc6$20e3fd00$40ee2fd8@venux.net>
<3896FBA1.38A5F87@ip23.net>
Subject: Re: [HACKERS] plpgsql problem..
Date: Tue, 1 Feb 2000 10:31:08 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

This might sound like an ignorant question but how does one dump the
function catalog?

----- Original Message -----
From: Sevo Stille <sevo@ip23.net>
To: Mitch Vincent <mitch@venux.net>
Cc: Postgres Hackers List <hackers@postgreSQL.org>
Sent: Tuesday, February 01, 2000 10:28 AM
Subject: Re: [HACKERS] plpgsql problem..

Mitch Vincent wrote:

ERROR: stat failed on file '${exec_prefix}/lib/plpgsql.so': No such

file or

directory

I can't find any reference to the $exec_prefix variable on either

machine,

yet it works on the development server and not on the live server.

PostgreSQL does not expand environment variables when looking for
function code. Presumably your installer is broken and did not
substitute the variable at install time on the affected system. You
might dump your function catalog on both systems to compare - if the
function path on the sane system contains a variable as well, there is
some strange magic going on there.

Sevo

From bouncefilter Tue Feb 1 10:43:30 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA01968
for <pgsql-hackers@postgresql.org>; Tue, 1 Feb 2000 10:42:38 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Tue, 1 Feb 2000 09:32:57 -0600
Sender: ed
Message-ID: <3896FF37.457BC106@austin.rr.com>
Date: Tue, 01 Feb 2000 09:43:51 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pghackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] float4 confused as int??
References: <3894B51F.A9D35D2D@austin.rr.com> <38951455.28A436A@austin.rr.com>
<3895EB10.CC9EC4A9@austin.rr.com> <12115.949370671@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Ed Loehr <eloehr@austin.rr.com> writes:

The problem is occurring with a database that was restored with psql
from a pg_dump (6.5.2).

If I dump the problem table, then drop/recreate it with my original
table creation commands, and then reload with only the insert commands
from the pg_dump'ed file, it reloads and allows updating of the float
field without a problem.

OK. Almost certainly, the data in the table is of no consequence;
the table schema is what matters. What are your original table
creation commands, and what does pg_dump emit?

I'd hoped to spot an erroneous integer type redefinition of the column
in the pg_dump output, but no such luck.

------------ Original table creation commands: ----------------------
CREATE TABLE contract_activity_type (
id SERIAL,
contract_id INTEGER NOT NULL, -- default frequency for
planning
activity_type_id INTEGER NOT NULL,-- Ex: "Interviews",
"Coaching", ...
travel_required INTEGER NOT NULL, -- bool: yes/no
billable INTEGER NOT NULL, -- bool: yes/no
duration FLOAT4 NOT NULL, -- how long is the activity
in days
participants INTEGER NOT NULL, -- # of expected
participants
frequency_id INTEGER NOT NULL, -- default frequency for
planning
cloned INTEGER NOT NULL DEFAULT 0, -- bool: yes/no
creator_id INTEGER NOT NULL DEFAULT 0, -- person id
creation_time DATETIME NOT NULL DEFAULT now(),
updater_id INTEGER NOT NULL DEFAULT 0, -- person id
last_update DATETIME NOT NULL DEFAULT now(),
record_status INTEGER NOT NULL DEFAULT 1,
PRIMARY KEY (contract_id,activity_type_id)
);
CREATE INDEX contract_activity_type_aid ON
contract_activity_type(activity_type_id);
CREATE INDEX contract_activity_type_cid ON
contract_activity_type(contract_id);

------------ pg_dump output: -----------------------------------------
CREATE SEQUENCE "contract_activity_type_id_seq" start 214 increment 1
maxvalue 2147483647 minvalue 1 cache 1 ;
SELECT nextval ('contract_activity_type_id_seq');
CREATE SEQUENCE "contract_activity_type_e_id_seq" start 1386 increment
1 maxvalue 2147483647 minvalue 1 cache 1 ;
SELECT nextval ('contract_activity_type_e_id_seq');
CREATE TABLE "contract_activity_type" (
"id" int4 DEFAULT nextval ( '"contract_activity_type_id_seq"'
) NOT NULL,
"contract_id" int4 NOT NULL,
"activity_type_id" int4 NOT NULL,
"travel_required" int4 NOT NULL,
"billable" int4 NOT NULL,
"duration" float4 NOT NULL,
"participants" int4 NOT NULL,
"frequency_id" int4 NOT NULL,
"cloned" int4 DEFAULT 0 NOT NULL,
"creator_id" int4 DEFAULT 0 NOT NULL,
"creation_time" datetime DEFAULT now ( ) NOT NULL,
"updater_id" int4 DEFAULT 0 NOT NULL,
"last_update" datetime DEFAULT now ( ) NOT NULL,
"record_status" int4 DEFAULT 1 NOT NULL);

From bouncefilter Tue Feb 1 10:56:28 2000
Received: from redbox.venux.net (redbox.venux.net [216.47.238.10])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA05141
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 10:55:44 -0500 (EST)
(envelope-from mitch@venux.net)
Received: from inky (inky.venux.net [216.47.238.64])
by redbox.venux.net (Postfix) with SMTP
id CA46B2E20B; Tue, 1 Feb 2000 10:46:56 -0500 (EST)
Message-ID: <028b01bf6ccd$3b6da480$40ee2fd8@venux.net>
From: "Mitch Vincent" <mitch@venux.net>
To: "Sevo Stille" <sevo@ip23.net>
Cc: "Postgres Hackers List" <hackers@postgreSQL.org>
References: <200002011347.IAA15802@candle.pha.pa.us>
<022201bf6cc6$20e3fd00$40ee2fd8@venux.net>
<3896FBA1.38A5F87@ip23.net>
Subject: Re: [HACKERS] plpgsql problem..
Date: Tue, 1 Feb 2000 10:58:50 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

Just an additional comment.

I re-configured and re-installed Postgre and there is no change...

I'm baffled....

----- Original Message -----
From: Sevo Stille <sevo@ip23.net>
To: Mitch Vincent <mitch@venux.net>
Cc: Postgres Hackers List <hackers@postgreSQL.org>
Sent: Tuesday, February 01, 2000 10:28 AM
Subject: Re: [HACKERS] plpgsql problem..

Mitch Vincent wrote:

ERROR: stat failed on file '${exec_prefix}/lib/plpgsql.so': No such

file or

directory

I can't find any reference to the $exec_prefix variable on either

machine,

yet it works on the development server and not on the live server.

PostgreSQL does not expand environment variables when looking for
function code. Presumably your installer is broken and did not
substitute the variable at install time on the affected system. You
might dump your function catalog on both systems to compare - if the
function path on the sane system contains a variable as well, there is
some strange magic going on there.

Sevo

From bouncefilter Tue Feb 1 11:08:28 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA11529
for <pgsql-hackers@postgresql.org>; Tue, 1 Feb 2000 11:08:09 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA03004;
Tue, 1 Feb 2000 08:06:55 -0800 (PST)
Message-Id: <3.0.1.32.20000201080344.0106e030@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 01 Feb 2000 08:03:44 -0800
To: Jose Soares <jose@sferacarta.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] END/ABORT
Cc: Jan Wieck <wieck@debis.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
In-Reply-To: <3896DD49.26143978@sferacarta.com>
References: <200001281837.NAA01003@candle.pha.pa.us>
<3.0.1.32.20000131094558.00f068ac@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:19 PM 2/1/00 +0100, Jose Soares wrote:

Don Baccus wrote:

Does it make all that much sense to worry about the actual word
used when the need to use "begin" is non-standard to begin with?

There is no explicit "BEGIN WORK" on SQL92, transaction initiation
is always implicit and it terminates either with a COMMIT or a
ROLLBACK
statement.

That was my point, of course...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Tue Feb 1 12:04:29 2000
Received: from feivel.fam-meskes.de (postfix@h-62.96.161.19.host.de.colt.net
[62.96.161.19]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA29830
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 12:04:05 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 7B9382BBA1; Tue, 1 Feb 2000 17:07:05 +0100 (CET)
Date: Tue, 1 Feb 2000 17:07:05 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PCLabs Survey, Part V: Programmability
Message-ID: <20000201170705.A1144@fam-meskes.de>
Mail-Followup-To: pgsql-hackers@postgreSQL.org
References: <Pine.BSF.4.21.0001311736500.480-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.BSF.4.21.0001311736500.480-100000@thelab.hub.org>;
from scrappy@hub.org on Mon, Jan 31, 2000 at 05:37:28PM -0400
Sender: michael@fam-meskes.de

On Mon, Jan 31, 2000 at 05:37:28PM -0400, The Hermit Hacker wrote:

- precompilers supplied for which languages:

Are there more than C?

Michael

--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Tue Feb 1 12:04:29 2000
Received: from feivel.fam-meskes.de (postfix@h-62.96.161.19.host.de.colt.net
[62.96.161.19]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA29831
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 12:04:05 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 10FF02BBA2; Tue, 1 Feb 2000 17:08:29 +0100 (CET)
Date: Tue, 1 Feb 2000 17:08:29 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PCLabs Survey,
Part VII: Embedded Database / Branch Office Support
Message-ID: <20000201170829.B1144@fam-meskes.de>
Mail-Followup-To: pgsql-hackers@postgreSQL.org
References: <Pine.BSF.4.21.0001311738580.480-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.BSF.4.21.0001311738580.480-100000@thelab.hub.org>;
from scrappy@hub.org on Mon, Jan 31, 2000 at 05:39:33PM -0400
Sender: michael@fam-meskes.de

On Mon, Jan 31, 2000 at 05:39:33PM -0400, The Hermit Hacker wrote:

- can run on a laptop running Windows 95 with 32MB of RAM

Why just Win95? How about a real operating system. :-)

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Tue Feb 1 11:09:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA11727
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 11:09:04 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA14383;
Tue, 1 Feb 2000 11:08:55 -0500 (EST)
To: "Mitch Vincent" <mitch@venux.net>
cc: hackers@postgreSQL.org, sevo@ip23.net
Subject: Re: [HACKERS] plpgsql problem..
In-reply-to: <023201bf6cc9$5c941c60$40ee2fd8@venux.net>
References: <200002011347.IAA15802@candle.pha.pa.us>
<022201bf6cc6$20e3fd00$40ee2fd8@venux.net>
<3896FBA1.38A5F87@ip23.net>
<023201bf6cc9$5c941c60$40ee2fd8@venux.net>
Comments: In-reply-to "Mitch Vincent" <mitch@venux.net>
message dated "Tue, 01 Feb 2000 10:31:08 -0500"
Date: Tue, 01 Feb 2000 11:08:55 -0500
Message-ID: <14380.949421335@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Mitch Vincent" <mitch@venux.net> writes:

This might sound like an ignorant question but how does one dump the
function catalog?

Try
select * from pg_proc where proname = 'functionOfInterest';

I think Sevo has identified the problem though: the CREATE FUNCTION
command for the plpgsql_call_handler function needs to give an exact
path name. What you are showing looks like the command tried to use an
environment variable and the substitution didn't happen. Better review
the procedure you used to install plpgsql. I'd recommend using the
createlang script, btw, not doing it by hand.

regards, tom lane

From bouncefilter Tue Feb 1 11:17:28 2000
Received: from andie.ip23.net (andie.ip23.net [212.83.32.23])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA13421
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 11:16:41 -0500 (EST)
(envelope-from sevo@ip23.net)
Received: from imap1.ip23.net (imap1.ip23.net [212.83.32.35])
by andie.ip23.net (8.9.3/8.9.3) with ESMTP id RAA16744;
Tue, 1 Feb 2000 17:16:10 +0100 (CET)
Received: from ip23.net (spc.ip23.net [212.83.32.122])
by imap1.ip23.net (8.9.3/8.9.3) with ESMTP id RAA09834;
Tue, 1 Feb 2000 17:17:34 +0100 (CET)
Sender: sevo@imap1.ip23.net
Message-ID: <389707F8.175B362F@ip23.net>
Date: Tue, 01 Feb 2000 17:21:12 +0100
From: Sevo Stille <sevo@ip23.net>
Organization: IP23
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Mitch Vincent <mitch@venux.net>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] plpgsql problem..
References: <200002011347.IAA15802@candle.pha.pa.us>
<022201bf6cc6$20e3fd00$40ee2fd8@venux.net>
<3896FBA1.38A5F87@ip23.net>
<023201bf6cc9$5c941c60$40ee2fd8@venux.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mitch Vincent wrote:

This might sound like an ignorant question but how does one dump the
function catalog?

The functions are in pg_proc. So generally, it would be "select * from
pg_proc". For the given problem, "select proname,probin from pg_proc;"
would be sufficient. Dump to a importable set of SQL statements, as in
pg_dump, can't be done - restoring a system table would hose the id
references, so exporting to a restorable format is of no use.

Sevo

From bouncefilter Tue Feb 1 11:27:29 2000
Received: from redbox.venux.net (redbox.venux.net [216.47.238.10])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA15804
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 11:26:48 -0500 (EST)
(envelope-from mitch@venux.net)
Received: from inky (inky.venux.net [216.47.238.64])
by redbox.venux.net (Postfix) with SMTP
id 5E4672E20B; Tue, 1 Feb 2000 11:18:00 -0500 (EST)
Message-ID: <02b701bf6cd1$9219eb00$40ee2fd8@venux.net>
From: "Mitch Vincent" <mitch@venux.net>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <hackers@postgreSQL.org>
References: <200002011347.IAA15802@candle.pha.pa.us>
<022201bf6cc6$20e3fd00$40ee2fd8@venux.net>
<3896FBA1.38A5F87@ip23.net>
<023201bf6cc9$5c941c60$40ee2fd8@venux.net>
<14380.949421335@sss.pgh.pa.us>
Subject: Re: [HACKERS] plpgsql problem..
Date: Tue, 1 Feb 2000 11:29:54 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

I used mklang.sql in the plpgsql directory to install the language.. It's
the same thing I used on the working devel server..

--
-- PL/pgSQL language declaration
--
-- $Header: /usr/local/cvsroot/pgsql/src/pl/plpgsql/src/mklang.sql.in,v 1.4
1999/05/11 22:57:50 tgl Exp $
--

create function plpgsql_call_handler() returns opaque
as '/usr/local/pgsql/plpgsql.so'
lib/language 'C';

create trusted procedural language 'plpgsql'
handler plpgsql_call_handler
lancompiler 'PL/pgSQL';

That's the contents of that file and /usr/local/pgsql/plpgsql.so is exactly
where plpgsql.so is.

----- Original Message -----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mitch Vincent <mitch@venux.net>
Cc: <hackers@postgreSQL.org>; <sevo@ip23.net>
Sent: Tuesday, February 01, 2000 11:08 AM
Subject: Re: [HACKERS] plpgsql problem..

"Mitch Vincent" <mitch@venux.net> writes:

This might sound like an ignorant question but how does one dump the
function catalog?

Try
select * from pg_proc where proname = 'functionOfInterest';

I think Sevo has identified the problem though: the CREATE FUNCTION
command for the plpgsql_call_handler function needs to give an exact
path name. What you are showing looks like the command tried to use an
environment variable and the substitution didn't happen. Better review
the procedure you used to install plpgsql. I'd recommend using the
createlang script, btw, not doing it by hand.

regards, tom lane

From bouncefilter Tue Feb 1 11:38:29 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA21683
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 11:38:21 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA14464;
Tue, 1 Feb 2000 11:38:02 -0500 (EST)
To: "Mitch Vincent" <mitch@venux.net>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] plpgsql problem..
In-reply-to: <02b701bf6cd1$9219eb00$40ee2fd8@venux.net>
References: <200002011347.IAA15802@candle.pha.pa.us>
<022201bf6cc6$20e3fd00$40ee2fd8@venux.net>
<3896FBA1.38A5F87@ip23.net>
<023201bf6cc9$5c941c60$40ee2fd8@venux.net>
<14380.949421335@sss.pgh.pa.us>
<02b701bf6cd1$9219eb00$40ee2fd8@venux.net>
Comments: In-reply-to "Mitch Vincent" <mitch@venux.net>
message dated "Tue, 01 Feb 2000 11:29:54 -0500"
Date: Tue, 01 Feb 2000 11:38:02 -0500
Message-ID: <14461.949423082@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Mitch Vincent" <mitch@venux.net> writes:

I used mklang.sql in the plpgsql directory to install the language.. It's
the same thing I used on the working devel server..

Odd. So what is in pg_proc for plpgsql_call_handler?

regards, tom lane

From bouncefilter Tue Feb 1 12:02:29 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id MAA28020
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 12:01:41 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m12FgW5-0003kgC; Tue, 1 Feb 100 17:51 MET
Message-Id: <m12FgW5-0003kgC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] plpgsql problem..
In-Reply-To: <028b01bf6ccd$3b6da480$40ee2fd8@venux.net> from Mitch Vincent at
"Feb 1, 2000 10:58:50 am"
To: Mitch Vincent <mitch@venux.net>
Date: Tue, 1 Feb 2000 17:51:01 +0100 (CET)
CC: Sevo Stille <sevo@ip23.net>,
Postgres Hackers List <hackers@postgreSQL.org>
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Just an additional comment.

I re-configured and re-installed Postgre and there is no change...

I'm baffled....

Which version of PostgreSQL and how do you install the
PL/pgSQL language in the database?

In either case, the support script you're using issues a
damaged CREATE FUNCTION command for the PL handler. Somehow
the build/install did not replace it with the actual
installation path.

After that, initdb again and anything should be fine.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 1 12:47:29 2000
Received: from redbox.venux.net (redbox.venux.net [216.47.238.10])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA40187
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 12:46:41 -0500 (EST)
(envelope-from mitch@venux.net)
Received: from inky (inky.venux.net [216.47.238.64])
by redbox.venux.net (Postfix) with SMTP id 57C652E20B
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 12:37:53 -0500 (EST)
Message-ID: <034f01bf6cdc$b99f6820$40ee2fd8@venux.net>
From: "Mitch Vincent" <mitch@venux.net>
To: "Postgres Hackers List" <hackers@postgreSQL.org>
References: <200002011347.IAA15802@candle.pha.pa.us>
<022201bf6cc6$20e3fd00$40ee2fd8@venux.net>
<3896FBA1.38A5F87@ip23.net>
<023201bf6cc9$5c941c60$40ee2fd8@venux.net>
<14380.949421335@sss.pgh.pa.us>
<02b701bf6cd1$9219eb00$40ee2fd8@venux.net>
<14461.949423082@sss.pgh.pa.us>
<02d701bf6cd3$b35bcb60$40ee2fd8@venux.net>
<14662.949423764@sss.pgh.pa.us>
Subject: Re: [HACKERS] plpgsql problem..
Date: Tue, 1 Feb 2000 12:49:45 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

Ok guys, brand new problem!

Now the backend segfaults.

query: begin transaction
ProcessUtility: begin transaction
CommitTransactionCommand
StartTransactionCommand
query: insert into
agencys(agency_id,created,createdby,updated,updatedby,loginallow,memberdate,
agencycode,agencyowner,agencyname,address1,address2,city,state,postal,countr
y,fed_taxid,naps_member,email,url,fee_sched,refund_policy,membership_type,up
s_type,invoice_hard_copy,zerodate,balance) values
(487,'now',291,'now',291,0,'02-01-2000','TEST-123','Mitch Vincent','Test
INC','knkln','lknlkn','lknlkn','ky','41101','US','','f','mitch@lala.com','ww
w.mitch.com','','jnblj','trac','f','f','12-01-1999',0)
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: update agencys set specialization='dfdf' where agency_id=487
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: update agencys set background='fdf' where agency_id=487
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: delete from agencys_phones where agency_id=487
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: insert into agencys_logins (agency_id,month,maxallowed) values
(487,'02-01-2000',0)
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: insert into accounting(agency_id,month,totaljobs,totalapps) values
(487,'02-01-2000',0,0)
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: insert into invoice
(invoice_number,agencycode,invoice_date,fee_membership,fee_logins,fee_conven
tion,fee_prints_jobs,fee_prints_apps,fee_hotlines,fee_postage,fee_ups,fee_la
te,fee_other1,other_desc1,fee_other2,other_desc2,fee_other3,other_desc3,fee_
pastdue,amount_paid,paid,total)
values(1,'TEST-123','02-01-2000',193.33333333333,0,0,0,0,0,0,0,0,0,'',0,'',0
,'',0,0,'f',0)
ProcessQuery
query: SELECT $1 + $2 + $3 + $4 + $5 + $6 + $7 + $8 + $9 + $10 + $11 + $12 +
$13 - $14
CommitTransactionCommand
StartTransactionCommand
query: select * from invoice where invoice_number=1
ProcessQuery
CommitTransactionCommand
pq_recvbuf: unexpected EOF on client connection
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
/usr/local/pgsql/bin/postmaster: reaping dead processes...
/usr/local/pgsql/bin/postmaster: CleanupProc: pid 75928 exited with status 0

I get that in the log file.... Can anyone see anything that might point to
the reason behind the segfault?

You guys have no idea how much I appreciate your help.. Thanks one and all.

-Mitch

----- Original Message -----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mitch Vincent <mitch@venux.net>
Sent: Tuesday, February 01, 2000 11:49 AM
Subject: Re: [HACKERS] plpgsql problem..

"Mitch Vincent" <mitch@venux.net> writes:

plpgsql_call_handler| 1002| 13|f |t |f

|

0|f | 0|0 0 0 0 0 0 0 0| 100| 0|
0| 100|- |/usr/local/pgsql/lib/plpgsql.so
(1 row)

That looks like it should work now...

Hmm, get this, now I have another error after droping and re-creating

the

language and function.

ERROR: fmgr_info: Cache lookup for language failed 4427969

It sounds like your language entry is still pointing at the old
function. (There's no interlock to keep you from dropping a function
that things still depend on ... probably there should be ...)

Try recreating the language entry now that you've remade the function.

regards, tom lane

From bouncefilter Tue Feb 1 13:59:30 2000
Received: from rage.hub.org (root@nat194.27.mpoweredpc.net [142.177.194.27])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA59046
for <pgsql-hackers@postgresql.org>; Tue, 1 Feb 2000 13:59:11 -0500 (EST)
(envelope-from jeffm@pgsql.com)
Received: from localhost (jeffm@localhost)
by rage.hub.org (8.9.3/8.9.3) with ESMTP id OAA30974
for <pgsql-hackers@postgresql.org>; Tue, 1 Feb 2000 14:59:29 -0400 (AST)
(envelope-from jeffm@pgsql.com)
X-Authentication-Warning: rage.hub.org: jeffm owned process doing -bs
Date: Tue, 1 Feb 2000 14:59:29 -0400 (AST)
From: "Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com>
X-Sender: jeffm@rage.hub.org
Reply-To: Jeff MacDonald <jeff@pgsql.com>
To: pgsql-hackers@postgresql.org
Subject: Win NT Binary
Message-ID: <Pine.BSF.4.10.10002011458020.10395-100000@rage.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Folks,

I'm trying to build an NT Binary, but the site
with Ludovic Lange's IPC package

http://www.multione.capgemini.fr/tools/pack_ipc/

seems to be down. very crapulent. does anyone
know where else i could get the IPC package ?

======================================================
Jeff MacDonald
jeff@pgsql.com irc: bignose on EFnet
======================================================

From bouncefilter Tue Feb 1 16:22:42 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA12919;
Tue, 1 Feb 2000 16:22:20 -0500 (EST) (envelope-from dms@wplus.net)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: from wplus.net (ppdms.dialup.wplus.net [195.131.52.71])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id AAA76915;
Wed, 2 Feb 2000 00:17:35 +0300 (MSK)
Message-ID: <38974E39.A5AE602@wplus.net>
Date: Wed, 02 Feb 2000 00:20:57 +0300
From: Dmitry Samersoff <dms@wplus.net>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Michael Meskes <meskes@postgreSQL.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PCLabs Survey,
Part VII: Embedded Database / Branch Office Support
References: <Pine.BSF.4.21.0001311738580.480-100000@thelab.hub.org>
<20000201170829.B1144@fam-meskes.de>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit

Michael Meskes wrote:

On Mon, Jan 31, 2000 at 05:39:33PM -0400, The Hermit Hacker wrote:

- can run on a laptop running Windows 95 with 32MB of RAM

Why just Win95? How about a real operating system. :-)

IMHO, answer should be: Can run on laptop with 8m of RAM ;-))
(i.e just skip win95)

I have such experience, OS - FreeBSD 2.2.6

From bouncefilter Tue Feb 1 19:15:34 2000
Received: from malgate.marin.or.jp ([210.252.139.5])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA63037
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 19:15:17 -0500 (EST)
(envelope-from yutaka@marin.or.jp)
Received: from main (210.252.139.70) by malgate.marin.or.jp
with SMTP (Eudora Internet Mail Server 1.2);
Tue, 1 Feb 2000 21:16:19 +0000
Date: Wed, 02 Feb 2000 09:12:20 +0900
From: Yutaka tanida <yutaka@marin.or.jp>
To: Jeff MacDonald <jeff@pgsql.com>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Win NT Binary
In-Reply-To: <Pine.BSF.4.10.10002011458020.10395-100000@rage.hub.org>
References: <Pine.BSF.4.10.10002011458020.10395-100000@rage.hub.org>
Message-Id: <38977664370.A07BYUTAKA@malgate.marin.or.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.04

Hi,

On Tue, 1 Feb 2000 14:59:29 -0400 (AST)
"Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com> wrote:

Folks,

I'm trying to build an NT Binary, but the site
with Ludovic Lange's IPC package

http://www.multione.capgemini.fr/tools/pack_ipc/

seems to be down. very crapulent. does anyone
know where else i could get the IPC package ?

I have a mirror on following URL.

http://www.s34.co.jp/~luster/pgsql/require/cygwin32_ipc-1.03.tgz

Precompiled binary with patch is ready on following URL.

http://www.s34.co.jp/~luster/pgsql/cygwin32_ipc-1.03-bin-patched.tar.bz2

-----
Yutaka Tanida<yutaka@emeraldshell.com>

From bouncefilter Tue Feb 1 21:25:35 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA01774
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 21:25:28 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id LAA10486 for <pgsql-hackers@postgreSQL.org>;
Wed, 02 Feb 2000 11:25:26 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: cvs-commit-digest V1 #856
Date: Wed, 2 Feb 2000 11:31:19 +0900
Message-ID: <001201bf6d25$963f1f80$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <200001300400.XAA39751@hub.org>
Importance: Normal

-----Original Message-----
From: owner-cvs-commit-digest@hub.org
[mailto:owner-cvs-commit-digest@hub.org]
Sent: Sunday, January 30, 2000 1:01 PM
To: committers-digest@hub.org
Subject: cvs-commit-digest V1 #856

------------------------------

Date: Sat, 29 Jan 2000 11:58:52 -0500 (EST)
From: Peter Eisentraut - PostgreSQL <petere>
Subject: [COMMITTERS] pgsql/src/interfaces/libpq (fe-misc.c
fe-print.c libpq-fe.h)

Date: Saturday, January 29, 2000 @ 11:58:51
Author: petere

Update of /usr/local/cvsroot/pgsql/src/interfaces/libpq
from hub.org:/home/tmp/cvs-serv53967/src/interfaces/libpq

Modified Files:
fe-misc.c fe-print.c libpq-fe.h

- ----------------------------- Log Message
-----------------------------

A few minor psql enhancements
Initdb help correction
Changed end/abort to commit/rollback and changed related notices
Commented out way old printing functions in libpq
Fixed a typo in alter table / alter column

pqbool is removed from libpq-fe.h.
Couldn't compile interfaces/perl5 now.

In addition,this seems to change external interface of PQprint().
Is it OK ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Feb 1 22:03:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA15756
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 22:03:14 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA16732
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 22:03:06 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: SELECT FOR UPDATE leaks relation refcounts
Date: Tue, 01 Feb 2000 22:03:06 -0500
Message-ID: <16729.949460586@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Poking into Oliver's report of "RelationClearRelation: relation 21645
modified while in use", I find that the culprit is the following
code in execMain.c's InitPlan():

foreach(l, parseTree->rowMark)
{
rm = lfirst(l);
relid = rt_fetch(rm->rti, rangeTable)->relid;
relation = heap_open(relid, RowShareLock);
if (!(rm->info & ROW_MARK_FOR_UPDATE))
continue;
erm = (execRowMark *) palloc(sizeof(execRowMark));
erm->relation = relation;
erm->rti = rm->rti;
sprintf(erm->resname, "ctid%u", rm->rti);
estate->es_rowMark = lappend(estate->es_rowMark, erm);
}

That heap_open() call has no corresponding heap_close() anywhere,
so every SELECT FOR UPDATE leaves the relation's refcount one higher
than it was. This didn't use to be a huge problem, other than that the
rel would be permanently locked into the backend's relcache. (I think
an attempt to DROP the table later in the session would have caused
trouble, though.) However, I just committed changes in the relcache
that assume that zero refcount is trustworthy, and it's those changes
that are spitting up.

It's easy enough to add code to EndPlan that goes through the
estate->es_rowMark list to close the rels that had ROW_MARK_FOR_UPDATE
set. But if that bit wasn't set, the above code opens the rel and then
forgets about it completely. Is that a bug? If not, I guess we need
another data structure to keep track of the non-ROW_MARK_FOR_UPDATE
rels through execution. (EndPlan doesn't currently get the parsetree
as a parameter, so it can't just duplicate the above loop --- though
passing it the parsetree might be one possible solution.)

I don't understand SELECT FOR UPDATE enough to know what is going on
here. But it seems darn peculiar to open a rel and then not keep any
reference to the rel for later use. Anybody know how this works?

regards, tom lane

From bouncefilter Tue Feb 1 22:53:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA24580
for <pgsql-hackers@postgreSQL.org>; Tue, 1 Feb 2000 22:53:16 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA16860;
Tue, 1 Feb 2000 22:52:56 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: "Hiroshi Inoue" <Inoue@tpf.co.jp>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
In-reply-to: <001201bf6d25$963f1f80$2801007e@tpf.co.jp>
References: <001201bf6d25$963f1f80$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Wed, 02 Feb 2000 11:31:19 +0900"
Date: Tue, 01 Feb 2000 22:52:56 -0500
Message-ID: <16857.949463576@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

From: Peter Eisentraut - PostgreSQL <petere>
Commented out way old printing functions in libpq

pqbool is removed from libpq-fe.h.
Couldn't compile interfaces/perl5 now.

In addition,this seems to change external interface of PQprint().
Is it OK ?

Not IMHO. It looks like Peter has removed typedef pqbool (potentially
breaking application sources, not just perl5) and changed what were
pqbool == char fields into int fields (thereby breaking binaries that
depend on shared libraries of libpq). Not to mention the advertised
change of removing documented API entry points.

Peter, you need to have a little more respect for stability of
library APIs. Gratuitous breaking of backwards compatibility
is not the done thing around here. It's especially not done
without any discussion.

regards, tom lane

From bouncefilter Tue Feb 1 23:10:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA30431
for <hackers@postgreSQL.org>; Tue, 1 Feb 2000 23:09:55 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA16945;
Tue, 1 Feb 2000 23:09:37 -0500 (EST)
To: "Mitch Vincent" <mitch@venux.net>
cc: "Postgres Hackers List" <hackers@postgreSQL.org>
Subject: Re: [HACKERS] plpgsql problem..
In-reply-to: <034f01bf6cdc$b99f6820$40ee2fd8@venux.net>
References: <200002011347.IAA15802@candle.pha.pa.us>
<022201bf6cc6$20e3fd00$40ee2fd8@venux.net>
<3896FBA1.38A5F87@ip23.net>
<023201bf6cc9$5c941c60$40ee2fd8@venux.net>
<14380.949421335@sss.pgh.pa.us>
<02b701bf6cd1$9219eb00$40ee2fd8@venux.net>
<14461.949423082@sss.pgh.pa.us>
<02d701bf6cd3$b35bcb60$40ee2fd8@venux.net>
<14662.949423764@sss.pgh.pa.us>
<034f01bf6cdc$b99f6820$40ee2fd8@venux.net>
Comments: In-reply-to "Mitch Vincent" <mitch@venux.net>
message dated "Tue, 01 Feb 2000 12:49:45 -0500"
Date: Tue, 01 Feb 2000 23:09:37 -0500
Message-ID: <16942.949464577@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Mitch Vincent" <mitch@venux.net> writes:

Ok guys, brand new problem!
Now the backend segfaults.

StartTransactionCommand
query: select * from invoice where invoice_number=1
ProcessQuery
CommitTransactionCommand
pq_recvbuf: unexpected EOF on client connection
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
/usr/local/pgsql/bin/postmaster: reaping dead processes...
/usr/local/pgsql/bin/postmaster: CleanupProc: pid 75928 exited with status 0

I get that in the log file.... Can anyone see anything that might point to
the reason behind the segfault?

Um, I see no backend segfault there --- I see a backend exiting in a
perfectly orderly fashion after detecting that the client closed the
channel. The client didn't send the expected "quit" (X) message,
which might or might not be normal behavior for that client. But if
you've got a backend segfault problem, this doesn't document it...

regards, tom lane

From bouncefilter Wed Feb 2 00:54:38 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA58015
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 00:53:42 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA22117;
Tue, 1 Feb 2000 21:52:54 -0800 (PST)
Message-Id: <3.0.1.32.20000201213417.00f906e0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 01 Feb 2000 21:34:17 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
Cc: "Hiroshi Inoue" <Inoue@tpf.co.jp>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
In-Reply-To: <16857.949463576@sss.pgh.pa.us>
References: <001201bf6d25$963f1f80$2801007e@tpf.co.jp>
<001201bf6d25$963f1f80$2801007e@tpf.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:52 PM 2/1/00 -0500, Tom Lane wrote:

Peter, you need to have a little more respect for stability of
library APIs. Gratuitous breaking of backwards compatibility
is not the done thing around here. It's especially not done
without any discussion.

I thought we went over this a week ago...was I dreaming?

PG is intended to be a PROFESSIONAL product. You don't arbitrarily
break things for the hell of it.

PG has CUSTOMERS. Not in the formal "we bought it" sense, but in
the moral and professional engineering sense.

You don't screw your customers without good reason, and when you
do you at least provide them cushions and soft mattresses and
advance notice. Especially advance notice. And if you do screw
them, you do so after you explore alternatives and come to realize
that there is no other course open to you. And you offer them
a condom (i.e. an upgrade path).

Because they depend on you.

Is professionalism so hard to understand?

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Wed Feb 2 01:10:38 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA67411
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 01:10:15 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id CAA17869;
Wed, 2 Feb 2000 02:07:50 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 2 Feb 2000 02:07:50 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
In-Reply-To: <3.0.1.32.20000201213417.00f906e0@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0002020204400.411-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 1 Feb 2000, Don Baccus wrote:

At 10:52 PM 2/1/00 -0500, Tom Lane wrote:

Peter, you need to have a little more respect for stability of
library APIs. Gratuitous breaking of backwards compatibility
is not the done thing around here. It's especially not done
without any discussion.

I thought we went over this a week ago...was I dreaming?

PG is intended to be a PROFESSIONAL product. You don't arbitrarily
break things for the hell of it.

PG has CUSTOMERS. Not in the formal "we bought it" sense, but in
the moral and professional engineering sense.

You don't screw your customers without good reason, and when you
do you at least provide them cushions and soft mattresses and
advance notice. Especially advance notice. And if you do screw
them, you do so after you explore alternatives and come to realize
that there is no other course open to you. And you offer them
a condom (i.e. an upgrade path).

Because they depend on you.

Is professionalism so hard to understand?

Don ... I try to stay out of stuff like this but ... TONE IT DOWN!

Peter is making mistakes, granted, but he is making them in a *NONE
PRODUCTION RELEASE* code tree ... if he messes with a -STABLE release in
this way, fine, your responses are justified, but, right now, I don't
think they are ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Wed Feb 2 01:21:38 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA69044
for <pgsql-hackers@postgresql.org>; Wed, 2 Feb 2000 01:21:28 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12FtAH-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Wed, 2 Feb 2000 00:21:21 -0600 (CST)
Date: Wed, 2 Feb 2000 00:21:21 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Don Baccus <dhogaza@pacifier.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
Message-ID: <20000202002121.A13476@rice.edu>
References: <001201bf6d25$963f1f80$2801007e@tpf.co.jp>
<001201bf6d25$963f1f80$2801007e@tpf.co.jp>
<16857.949463576@sss.pgh.pa.us>
<3.0.1.32.20000201213417.00f906e0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <3.0.1.32.20000201213417.00f906e0@mail.pacifier.com>;
from dhogaza@pacifier.com on Tue, Feb 01, 2000 at 09:34:17PM -0800

On Tue, Feb 01, 2000 at 09:34:17PM -0800, Don Baccus wrote:

At 10:52 PM 2/1/00 -0500, Tom Lane wrote:

<deleted to save having to read that again>

Ah Don, that's a little harsh, isn't it? Did Peter's actions in checking in
code lose you one minutes work, either time? I seem to recall that your not
tracking the CVS (which you shouldn't). So your basically bitching about
_theoretical_ problems? Tom, as a core developer, is directly affected,
and has earned the right to chew out Peter. You, on the other hand, are
a kibitzer here, as am I. Your comments in technical discussions lead
me to believe that you are a professional developer, but you haven't
stepped up to the plate for postgresql, yet, and submitted code. Let the
current core developers deal with this: we all know your position!

Ross

--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Wed Feb 2 01:26:38 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA69568
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 01:26:01 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA17412;
Wed, 2 Feb 2000 01:23:32 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002020623.BAA17412@candle.pha.pa.us>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
In-Reply-To: <Pine.BSF.4.21.0002020204400.411-100000@thelab.hub.org> from The
Hermit Hacker at "Feb 2, 2000 02:07:50 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Wed, 2 Feb 2000 01:23:32 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter_e@gmx.net>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Is professionalism so hard to understand?

Don ... I try to stay out of stuff like this but ... TONE IT DOWN!

Peter is making mistakes, granted, but he is making them in a *NONE
PRODUCTION RELEASE* code tree ... if he messes with a -STABLE release in
this way, fine, your responses are justified, but, right now, I don't
think they are ...

I also told Peter that 7.0 was a good time to remove routines that were
no longer needed. Yes, it is a migration problem, but why drag around
functions forever that are useless. Maybe he pulled one too many?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 2 01:32:38 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA72471
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 01:32:31 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA17577;
Wed, 2 Feb 2000 01:31:10 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002020631.BAA17577@candle.pha.pa.us>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
In-Reply-To: <20000202002121.A13476@rice.edu> from "Ross J. Reedstrom" at "Feb
2, 2000 00:21:21 am"
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Date: Wed, 2 Feb 2000 01:31:10 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, Feb 01, 2000 at 09:34:17PM -0800, Don Baccus wrote:

At 10:52 PM 2/1/00 -0500, Tom Lane wrote:

<deleted to save having to read that again>

Ah Don, that's a little harsh, isn't it? Did Peter's actions in checking in
code lose you one minutes work, either time? I seem to recall that your not
tracking the CVS (which you shouldn't). So your basically bitching about
_theoretical_ problems? Tom, as a core developer, is directly affected,
and has earned the right to chew out Peter. You, on the other hand, are
a kibitzer here, as am I. Your comments in technical discussions lead
me to believe that you are a professional developer, but you haven't
stepped up to the plate for postgresql, yet, and submitted code. Let the
current core developers deal with this: we all know your position!

This is excellent advise.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 2 01:58:38 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA76608
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 01:57:38 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA17425;
Wed, 2 Feb 2000 01:57:11 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, Don Baccus <dhogaza@pacifier.com>,
Peter Eisentraut <peter_e@gmx.net>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
In-reply-to: <200002020623.BAA17412@candle.pha.pa.us>
References: <200002020623.BAA17412@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Wed, 02 Feb 2000 01:23:32 -0500"
Date: Wed, 02 Feb 2000 01:57:10 -0500
Message-ID: <17422.949474630@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I also told Peter that 7.0 was a good time to remove routines that were
no longer needed. Yes, it is a migration problem, but why drag around
functions forever that are useless. Maybe he pulled one too many?

We have in fact talked about removing some of the older-generation
print functions (though I was envisioning a slow process of labeling
them deprecated for a few releases...). It was the quite unnecessary
modification of the exported PQprintOpt struct that got my Irish up.
I've fought way too many hard-to-debug crashes caused by that sort
of change.

regards, tom lane

From bouncefilter Wed Feb 2 02:47:39 2000
Received: from feivel.fam-meskes.de (postfix@h-62.96.159.158.host.de.colt.net
[62.96.159.158]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA89327
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 02:46:53 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 623CF2BBA5; Wed, 2 Feb 2000 08:42:26 +0100 (CET)
Date: Wed, 2 Feb 2000 08:42:26 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PCLabs Survey,
Part VII: Embedded Database / Branch Office Support
Message-ID: <20000202084226.A1927@fam-meskes.de>
Mail-Followup-To: pgsql-hackers@postgreSQL.org
References: <Pine.BSF.4.21.0001311738580.480-100000@thelab.hub.org>
<20000201170829.B1144@fam-meskes.de> <38974E39.A5AE602@wplus.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <38974E39.A5AE602@wplus.net>;
from dms@wplus.net on Wed, Feb 02, 2000 at 12:20:57AM +0300
Sender: michael@fam-meskes.de

On Wed, Feb 02, 2000 at 12:20:57AM +0300, Dmitry Samersoff wrote:

IMHO, answer should be: Can run on laptop with 8m of RAM ;-))
(i.e just skip win95)

I did the same (okay it wasn't a laptop) with my old 486DX40 with 8MB until
the motherboard gave up. It even ran well when X was up and running. :-)

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Wed Feb 2 03:49:40 2000
Received: from gandalf.telecom.at (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA06910
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 03:49:38 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id JAA149732
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 09:49:32 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALPXXS>; Wed, 2 Feb 2000 09:49:31 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC237@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] freefuncs.c is never called from anywhere!?
Date: Wed, 2 Feb 2000 09:49:25 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

(In the same spirit it would also be nice to tag NOT_USED

sections with a

version number, so it could be yanked two or three releases past.)

Why not just yank it period? 'cvs diff' will show what was
yanked, and
the log message could say just 'yanked NOT_USED code from
source tree'...

Once GetAttributeBy[Num|Name] was yanked, because it was not referenced
inside the code. It is heavily used in extensions though.

For me it was relatively easy to find the problem, because it was ifdef'd
NOT_USED.
I am not sure if I had found it that easily, if the "old" code would have
only been in cvs.

Andreas

From bouncefilter Wed Feb 2 04:45:40 2000
Received: from flex.flex.ro ([193.230.255.4])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA20116
for <pgsql-interfaces@postgreSQL.org>;
Wed, 2 Feb 2000 04:44:07 -0500 (EST) (envelope-from teo@flex.ro)
Received: from flex.ro (IDENT:teo@teo.flex.ro [193.230.255.3])
by flex.flex.ro (8.9.3/8.9.3) with ESMTP id MAA00401;
Wed, 2 Feb 2000 12:40:28 +0200
Sender: teo@flex.flex.ro
Message-ID: <3897FADD.7C459CC7@flex.ro>
Date: Wed, 02 Feb 2000 11:37:33 +0200
From: Constantin Teodorescu <teo@flex.ro>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] PClabs Survey, Part I: Administration
References: <Pine.BSF.4.21.0001311730410.480-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The Hermit Hacker wrote:

Also, marked with * the options available in PgAccess

Administration
- graphical tools for
- database administration
- installing the database server
- creating and managing databases
- creating and managing disk devices
* - creating and managing users
* - creating and managing indicies
* - creating and managing stored procedures
* - backup and restore operations
- creating and managing replication links
- Web publishing
- database diagramming tools
- viewing and entering data into database tables
- submitting SQL commands and viewing results
- send a message to all logged-in database users
- database perforformance tuning
- configuring server engine options
* - viewing the SQL commands currently executing
- detecting resource-intensive queries
- killing selected queries
- graphing overall server engine statistics
- single statement graphical execution plan display
- SQL rewrite suggestions for a single SQL statement
- index suggestions for a single SQL statement
- index suggestions for overall server (based on actual usage)
- pre-calculation (summary table) suggestions (based on actual usage)
- baselining and then tracking server performance over time

In PgAccess there are also a couple of goodies that are not listed above
as:

- visual query builder
- schema designer

Constantin Teodorescu
FLEX Consulting Braila, ROMANIA

From bouncefilter Wed Feb 2 04:44:40 2000
Received: from gate.plzen-city.cz (gate.plzen-city.cz [194.212.191.10])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA20117
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 04:44:11 -0500 (EST)
(envelope-from horak@sit.plzen-city.cz)
Received: (from mail@localhost) by gate.plzen-city.cz (8.9.3/8.9.1) id
KAA32135
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 10:44:01 +0100
Received: from EXCHANGE.mmp.plzen-city.cz(s5srvr2.mmp.plzen-city.cz
192.168.4.22) by gate.plzen-city.cz via smap (v1.3-ps12tp)
id sma032129; Wed Feb 2 10:43:57 2000
Received: by exchange.mmp.plzen-city.cz with Internet Mail Service
(5.5.2650.21) id <114TT4L2>; Wed, 2 Feb 2000 10:43:56 +0100
Message-ID:
<F4A9A276019AD311B08C00A024B2517005884F@exchange.mmp.plzen-city.cz>
From: =?iso-8859-1?Q?Hor=E1k_Daniel?= <horak@sit.plzen-city.cz>
To: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] PCLabs Survey, Part VII: Embedded Database / Branch
Office Support
Date: Wed, 2 Feb 2000 10:43:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"

- can run on a laptop running Windows 95 with 32MB of RAM

Why just Win95? How about a real operating system. :-)

We don't support Win95, only WinNT

Dan

From bouncefilter Wed Feb 2 06:38:13 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA14462
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 06:38:07 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Kamel.DoCS.UU.SE (e99re41@Kamel.DoCS.UU.SE [130.238.9.189])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA24827;
Wed, 2 Feb 2000 12:37:51 +0100 (MET)
Received: from localhost (e99re41@localhost) by Kamel.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA10562; Wed, 2 Feb 2000 12:37:49 +0100
X-Authentication-Warning: Kamel.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Wed, 2 Feb 2000 12:37:48 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
In-Reply-To: <001201bf6d25$963f1f80$2801007e@tpf.co.jp>
Message-ID: <Pine.GSO.4.02A.10002021232520.10500-100000@Kamel.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 2 Feb 2000, Hiroshi Inoue wrote:

pqbool is removed from libpq-fe.h.
Couldn't compile interfaces/perl5 now.

In addition,this seems to change external interface of PQprint().
Is it OK ?

Darn, seems like I'm doing everything wrong these days. I gotta take some
time off to get my wits together. This is not anyone's fault out there,
maybe I just wasn't ready quite yet. I don't want to be the problem
person. I'll be back. (psql quoting bug will be fixed.)

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Feb 2 08:12:15 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA40243
for <pgsql-hackers@postgresql.org>; Wed, 2 Feb 2000 08:11:17 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA20115;
Wed, 2 Feb 2000 09:11:02 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 2 Feb 2000 09:11:02 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgresql.org>
Subject: Re: AW: [HACKERS] freefuncs.c is never called from anywhere!?
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC237@sdexcsrv1.f000.d0188.sd.spardat.at>
Message-ID: <Pine.BSF.4.21.0002020910320.411-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 2 Feb 2000, Zeugswetter Andreas SB wrote:

(In the same spirit it would also be nice to tag NOT_USED

sections with a

version number, so it could be yanked two or three releases past.)

Why not just yank it period? 'cvs diff' will show what was
yanked, and
the log message could say just 'yanked NOT_USED code from
source tree'...

Once GetAttributeBy[Num|Name] was yanked, because it was not referenced
inside the code. It is heavily used in extensions though.

For me it was relatively easy to find the problem, because it was ifdef'd
NOT_USED.
I am not sure if I had found it that easily, if the "old" code would have
only been in cvs.

Maybe date/release stamp a NOT_USED and if after X releases, yank it as
not being relevant ... at least in cases like this ...

From bouncefilter Wed Feb 2 09:02:15 2000
Received: from rage.hub.org (root@nat194.27.mpoweredpc.net [142.177.194.27])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA53952
for <pgsql-hackers@postgresql.org>; Wed, 2 Feb 2000 09:02:03 -0500 (EST)
(envelope-from jeffm@pgsql.com)
Received: from localhost (jeffm@localhost)
by rage.hub.org (8.9.3/8.9.3) with ESMTP id KAA33928
for <pgsql-hackers@postgresql.org>; Wed, 2 Feb 2000 10:02:16 -0400 (AST)
(envelope-from jeffm@pgsql.com)
X-Authentication-Warning: rage.hub.org: jeffm owned process doing -bs
Date: Wed, 2 Feb 2000 10:02:15 -0400 (AST)
From: "Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com>
X-Sender: jeffm@rage.hub.org
Reply-To: Jeff MacDonald <jeff@pgsql.com>
To: pgsql-hackers@postgresql.org
Subject: WinNT compiling: ongoing
Message-ID: <Pine.BSF.4.10.10002020958270.10395-100000@rage.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Ok, i've managed to get all the files i need, dandy.

* side note, i am aware that there is a pre-compiled
binary on hub. i'm doing this to see how well kevins
instructions work for every one. (from scratch)

lets start here , first 3 steps
1.Download ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/latest/full.exe

done.

2. Run full.exe and install in c:\Unix\Root directory.

afaik this means i should have a c:\Unix\Root\Cygwin
dir ?

3.Run Cygwin, and then run "mount c:/Unix/Root /"
this command will not work. it gives the error
"Device Busy" , which makes perfect sense, since cygwin
is self is running out of a sub-dir of this dir.

any thoughts as to what kevin might have meant ?

======================================================
Jeff MacDonald
jeff@pgsql.com irc: bignose on EFnet
======================================================

From bouncefilter Wed Feb 2 09:08:15 2000
Received: from gate.plzen-city.cz (gate.plzen-city.cz [194.212.191.10])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA56727
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 09:08:10 -0500 (EST)
(envelope-from horak@sit.plzen-city.cz)
Received: (from mail@localhost) by gate.plzen-city.cz (8.9.3/8.9.1) id
PAA05267
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 15:08:04 +0100
Received: from EXCHANGE.mmp.plzen-city.cz(s5srvr2.mmp.plzen-city.cz
192.168.4.22) by gate.plzen-city.cz via smap (v1.3-ps12tp)
id sma005257; Wed Feb 2 15:07:39 2000
Received: by exchange.mmp.plzen-city.cz with Internet Mail Service
(5.5.2650.21) id <114TTVCK>; Wed, 2 Feb 2000 15:07:38 +0100
Message-ID:
<F4A9A276019AD311B08C00A024B25170058852@exchange.mmp.plzen-city.cz>
From: =?iso-8859-1?Q?Hor=E1k_Daniel?= <horak@sit.plzen-city.cz>
To: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] WinNT compiling: ongoing
Date: Wed, 2 Feb 2000 15:07:38 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"

3.Run Cygwin, and then run "mount c:/Unix/Root /"
this command will not work. it gives the error
"Device Busy" , which makes perfect sense, since cygwin
is self is running out of a sub-dir of this dir.

try to do "umount /" before doing mount

Dan

From bouncefilter Wed Feb 2 10:04:16 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA76039
for <pgsql-hackers@postgresql.org>; Wed, 2 Feb 2000 10:03:42 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA11016;
Wed, 2 Feb 2000 07:03:05 -0800 (PST)
Message-Id: <3.0.1.32.20000202063318.00f96a10@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 02 Feb 2000 06:33:18 -0800
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
In-Reply-To: <20000202002121.A13476@rice.edu>
References: <3.0.1.32.20000201213417.00f906e0@mail.pacifier.com>
<001201bf6d25$963f1f80$2801007e@tpf.co.jp>
<001201bf6d25$963f1f80$2801007e@tpf.co.jp>
<16857.949463576@sss.pgh.pa.us>
<3.0.1.32.20000201213417.00f906e0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:21 AM 2/2/00 -0600, Ross J. Reedstrom wrote:

On Tue, Feb 01, 2000 at 09:34:17PM -0800, Don Baccus wrote:

At 10:52 PM 2/1/00 -0500, Tom Lane wrote:

<deleted to save having to read that again>

Ah Don, that's a little harsh, isn't it?

Yes, it is, and I apologize.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Wed Feb 2 13:25:18 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA57594
for <pgsql-hackers@postgresql.org>; Wed, 2 Feb 2000 13:24:50 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id NAA01872;
Wed, 2 Feb 2000 13:24:14 -0500
Message-ID: <38987647.C1C3F865@wgcr.org>
Date: Wed, 02 Feb 2000 13:24:07 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
CC: Don Baccus <dhogaza@pacifier.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
References: <001201bf6d25$963f1f80$2801007e@tpf.co.jp>
<001201bf6d25$963f1f80$2801007e@tpf.co.jp>
<16857.949463576@sss.pgh.pa.us>
<3.0.1.32.20000201213417.00f906e0@mail.pacifier.com>
<20000202002121.A13476@rice.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ross J. Reedstrom" wrote:

Ah Don, that's a little harsh, isn't it?

Yes, it was a little harsh, and Don apologized.

Did Peter's actions in checking in
code lose you one minutes work, either time? I seem to recall that your not
tracking the CVS (which you shouldn't).

Wrong -- Don is one of the core (or lead) developers porting the
ArsDigita Community System from Oracle to PostgreSQL -- and in order to
do this he has indeed been tracking the CVS -- and in fact he is running
the pre-beta PostgreSQL 7 right now on a site with the pre-pre-beta ACS
port to PostgreSQL running on the beta AOLserver 3.0. He also is a
major maintainer of the AOLserver driver for postgresql -- which could
be directly impacted by these changes. So, even though Don hasn't been
a heavy contributor here as yet, I believe that he has a right to let
his position be known -- although a little more gently, perhaps.

Why does he need to do this? Two words: Referential Integrity, which is
heavily used by the ACS.

I also track the current CVS -- but for a totally different reason, as I
want to be able to release RPMs of the beta release the same day as the
beta release -- thus, I am doing trial builds of RPM's against the CVS.
However, this current issue doesn't impact me in the slightest -- which
is why I have not and will not say anything about it.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Wed Feb 2 15:07:19 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA99058
for <pgsql-hackers@postgresql.org>; Wed, 2 Feb 2000 15:06:25 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12G62d-000LEMC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Wed, 2 Feb 2000 14:06:19 -0600 (CST)
Date: Wed, 2 Feb 2000 14:06:19 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] RE: cvs-commit-digest V1 #856
Message-ID: <20000202140619.A18004@rice.edu>
References: <001201bf6d25$963f1f80$2801007e@tpf.co.jp>
<001201bf6d25$963f1f80$2801007e@tpf.co.jp>
<16857.949463576@sss.pgh.pa.us>
<3.0.1.32.20000201213417.00f906e0@mail.pacifier.com>
<20000202002121.A13476@rice.edu> <38987647.C1C3F865@wgcr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <38987647.C1C3F865@wgcr.org>;
from lamar.owen@wgcr.org on Wed, Feb 02, 2000 at 01:24:07PM -0500

On Wed, Feb 02, 2000 at 01:24:07PM -0500, Lamar Owen wrote:

"Ross J. Reedstrom" wrote:

Ah Don, that's a little harsh, isn't it?

Yes, it was a little harsh, and Don apologized.

Did Peter's actions in checking in
code lose you one minutes work, either time? I seem to recall that your not
tracking the CVS (which you shouldn't).

Wrong -- Don is one of the core (or lead) developers porting the

(details of what Don's up to)

Ah, now it's time for me to apologize. As I said, *I'm* the kibitzer
here, so I'll shut up now.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Wed Feb 2 19:05:22 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA78991
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 19:04:48 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA24024;
Wed, 2 Feb 2000 19:04:39 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Recent RI changes have broken something
In-reply-to: <200002010929.JAA06616@linda.lfix.co.uk>
References: <200001312218.WAA32035@linda.lfix.co.uk>
<12134.949370805@sss.pgh.pa.us>
<200002010929.JAA06616@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Tue, 01 Feb 2000 09:29:31 +0000"
Date: Wed, 02 Feb 2000 19:04:39 -0500
Message-ID: <24021.949536279@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Oliver Elphick" <olly@lfix.co.uk> writes:

ERROR: RelationClearRelation: relation 21645 modified while in use

This is probably my fault. Can you provide a simple test case?
The two table declarations might be enough.

I think this is fixed now. Hopefully I didn't break SELECT FOR UPDATE
while I was at it.

regards, tom lane

From bouncefilter Wed Feb 2 19:08:22 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA79560
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 19:08:16 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA10955; Thu, 03 Feb 2000 09:08:05 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
Date: Thu, 3 Feb 2000 09:13:58 +0900
Message-ID: <000601bf6ddb$90b4d9e0$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <16729.949460586@sss.pgh.pa.us>

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane

Poking into Oliver's report of "RelationClearRelation: relation 21645
modified while in use", I find that the culprit is the following
code in execMain.c's InitPlan():

foreach(l, parseTree->rowMark)
{
rm = lfirst(l);
relid = rt_fetch(rm->rti, rangeTable)->relid;
relation = heap_open(relid, RowShareLock);
if (!(rm->info & ROW_MARK_FOR_UPDATE))
continue;
erm = (execRowMark *) palloc(sizeof(execRowMark));
erm->relation = relation;
erm->rti = rm->rti;
sprintf(erm->resname, "ctid%u", rm->rti);
estate->es_rowMark = lappend(estate->es_rowMark, erm);
}

That heap_open() call has no corresponding heap_close() anywhere,
so every SELECT FOR UPDATE leaves the relation's refcount one higher
than it was. This didn't use to be a huge problem, other than that the
rel would be permanently locked into the backend's relcache. (I think
an attempt to DROP the table later in the session would have caused
trouble, though.) However, I just committed changes in the relcache
that assume that zero refcount is trustworthy, and it's those changes
that are spitting up.

It's easy enough to add code to EndPlan that goes through the
estate->es_rowMark list to close the rels that had ROW_MARK_FOR_UPDATE
set. But if that bit wasn't set, the above code opens the rel and then
forgets about it completely. Is that a bug? If not, I guess we need

Seems its a bug though I'm not sure.
Is there anything wrong with inserting heap_close(relation, NoLock)
immediately before 'continue;' ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Feb 2 20:00:23 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA92389
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 20:00:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA24210;
Wed, 2 Feb 2000 20:00:02 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
In-reply-to: <000601bf6ddb$90b4d9e0$2801007e@tpf.co.jp>
References: <000601bf6ddb$90b4d9e0$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Thu, 03 Feb 2000 09:13:58 +0900"
Date: Wed, 02 Feb 2000 20:00:02 -0500
Message-ID: <24207.949539602@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

It's easy enough to add code to EndPlan that goes through the
estate->es_rowMark list to close the rels that had ROW_MARK_FOR_UPDATE
set. But if that bit wasn't set, the above code opens the rel and then
forgets about it completely. Is that a bug? If not, I guess we need

Seems its a bug though I'm not sure.

I looked over the code that works with rowmarks and decided it is a
bug.  There are just two action flag bits for the executor to worry
about, ROW_MARK_FOR_UPDATE and ROW_ACL_FOR_UPDATE.  The first makes
the execution-time stuff actually happen, while the second causes
a suitable permissions check to be applied before execution.  In a
simple SELECT FOR UPDATE situation, both bits will be set.  The only
way that the ROW_MARK_FOR_UPDATE bit can get unset is if the SELECT
FOR UPDATE command references a view --- in that case, the rewriter
clears the ROW_MARK_FOR_UPDATE bit on the view's rowmark entry,
and adds rowmark entries with only ROW_MARK_FOR_UPDATE set for the
tables referenced by the view.  As far as I can see, this is correct
behavior: the permissions check should be applied to the view, not
the referenced tables, but actual execution happens in the referenced
tables and doesn't touch the view at all.  Therefore, it's unnecessary
--- and perhaps actually wrong --- for InitPlan to be grabbing a
RowShareLock on the view.

So, I've rearranged the InitPlan code to not open the rel at all when
ROW_MARK_FOR_UPDATE is clear, and I've added code in EndPlan to
traverse the estate->es_rowMark list and heap_close the opened rels
(specifying NoLock, so that the RowShareLock is held till commit).

This seems to solve Oliver's problem, and the regress tests still pass,
so I committed it a little while ago.

Is there anything wrong with inserting heap_close(relation, NoLock)
immediately before 'continue;' ?

We can do that if it turns out my analysis is wrong and RowShareLock
should indeed be grabbed on views as well as their underlying tables.

regards, tom lane

From bouncefilter Wed Feb 2 20:18:23 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA98547
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 20:17:24 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA24324;
Wed, 2 Feb 2000 20:17:17 -0500 (EST)
To: bhirt@mobygames.com
cc: pgsql-hackers@postgreSQL.org, Brian Hirt <bhirt@loopy.berkhirt.com>
Subject: Re: [HACKERS] union in an in clause and timestamp
In-reply-to: <20000201014854.A10211@loopy.berkhirt.com>
References: <20000201014854.A10211@loopy.berkhirt.com>
Comments: In-reply-to Brian Hirt <bhirt@mobygames.com>
message dated "Tue, 01 Feb 2000 01:48:54 -0600"
Date: Wed, 02 Feb 2000 20:17:17 -0500
Message-ID: <24321.949540637@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Brian Hirt <bhirt@mobygames.com> writes:

Okay, I'm running into two things that I would expect to work.

basement=> select 'hello' where 1 in (select 2 union select 1);
ERROR: parser: parse error at or near "union"

UNION isn't currently supported in sub-selects. Hopefully we can make
it work after the long-threatened querytree redesign. But right now,
the union code is so crufty that no one wants to touch it...

And then, I find that I cannot create an index on a
timestamp column;
basement=> create index ttt on ts(t);
ERROR: Can't find a default operator class for type 1296.

For the moment, use one of the other time-related types instead.
After the dust settles from Thomas' upcoming consolidation of the
date/time datatypes, I expect everything that remains will have a
complete set of operators and index support.

regards, tom lane

From bouncefilter Wed Feb 2 20:34:23 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA04743;
Wed, 2 Feb 2000 20:33:41 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA19488; Thu, 3 Feb 2000 12:33:00 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdMNpBV_;
Thu Feb 3 12:32:28 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA24910; Thu, 3 Feb 2000 12:32:26 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdoXrHC_; Thu Feb 3 12:32:01 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA01940;
Thu, 3 Feb 2000 12:32:00 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
MAA05527; Thu, 3 Feb 2000 12:31:10 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
Date: Thu, 03 Feb 2000 12:30:26 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org,
Chris Bitmead <chris@bitmead.com>
Subject: Proposed Changes to PostgreSQL
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I've been spending a lot of time lately with gdb and tracing the
back-end seeing if I can understand it enough to make some changes.
I'm starting to actually understand a lot of stuff, so in order
to have some possibility of having my changes accepted, I want to
discuss
them here first. Based on that, I'm going to hopefully make an attempt
at implementation. I have a patch for one of these changes already
if I get the go ahead.

THESE CHANGES DON'T AFFECT YOU IF YOU DON'T USE INHERITANCE.

Speak now about these changes or please, forever hold your peace. Of
course you can comment later if I screw up implementation.

The proposed changes are....

1) An imaginary field in every tuple that tells you the class it came
from.
This is useful when you select from table* and want to know which
relation the object actually came from. It wouldn't be stored on disk,
and like oid it wouldn't be displayed when you do SELECT *. The field
would be called classname. So you could have...
SELECT p.classname, p.name FROM person p;
person | Fred
student | Bill
employee | Jim
person | Chris

If you want to know the exact behaviour it is as if every table in the
database had done to it...
ALTER TABLE foo ADD COLUMN classname TEXT;
UPDATE foo SET classname='foo';

Of course this is not how it would be implemented. It is just
reference for how it will appear to work. BTW, this idea was also
in the original berkeley design notes.

2) Changing the sense of the default for getting inherited tuples.
Currently you only get inherited tuples if you specify "tablename*".
This would be changed so that you get all sub-class tuples too by
default unless you specify "ONLY tablename". There are several
rationale for this. Firstly this is what Illustra/Informix have
implemented. Secondly, I believe it is more logical from an OO
perspective as well as giving a more useful default. If a politician
IS a person and I say SELECT * from person, then logically I should
see all the politicians because they are people too (so they claim
:). Thirdly, there are a whole range of SQL statements that should
probably be disallowed without including sub-classes. e.g. an ALTER
TABLE ADD COLUMN that does not include sub-classes is almost certainly
undesirable. It seems ashame to have to resort to non-standard SQL
with the "*" syntax in this case when it is really your only
choice. Basicly, wanting ONLY a classname is a far more unusual
choice, and leaving off the "*" is a common error. Fourthly, it seems
out of character for the SQL language to have this single character
operator. The SQL style is to use wordy descriptions of the operators
meaning. "ONLY" fits well here because it describes its own meaning
perfectly whereas to the unitiated, "*" is harder to guess at. While
this change is an incompatibility I hope for those few people using
inheritance they can accept the need to move forward without
over-burden of backwards compatibility.

3) The ability to return different types of rows from a SELECT. This
is to allow implementation of ODBMS functionality where a query could
be required to instantiate objects of differing types with differing
attributes.

I would propose that that anytime you do a SELECT * from a base table
that you would get back the full rows from those sub tables. Since the
current PQ interface which doesn't support this notion would remain
unchanged this wouldn't affect current users.

It's probably also desirable to have a syntax for getting just the
columns of the base table when this is desired. Say perhaps SELECT %
from table. This would be a performance hack for users of libpq and a
functionality difference for users of psql.

The reason I think the "*" syntax should take on the new functionality
is because it would be more consistent with what the OQL (object query
language) standard specifies, and also because it seems the more
useful default. Also there is no compatibility reason not to do it.

In addition it would be legal to specify columns that only exist in
sub-classes. For example, if we had

CREATE TABLE person (name TEXT);
CREATE TABLE student (studentid TEXT, faculty TEXT) INHERITS (person);

it would be legal to say...

SELECT * FROM person;

NAME
----
Fred
Bill

NAME | STUDENTID | FACULTY
--------------------------
Jim | 23455 | Science
Chris| 45666 | Arts

SELECT *, studentid FROM person;

NAME
----
Fred
Bill

NAME | STUDENTID
----------------
Jim | 23455
Chris| 45666

SELECT *, studentid FROM ONLY person;

ERROR: person does not contain studentid.

SELECT % FROM person;

NAME
----
Fred
Bill
Jim
Chris

As you can see, it is desirable that psql be modified to be able to
print these differing tuple types. Presumably new column headings will
be printed when a tuple is differing to the previous one. Likely it
will be often desirable to do a
SELECT * FROM person p ORDER BY p.classname;
in order to have all the tuples of a particular type grouped together.

In addition some extenions will be done to the PQ interface to support
these differing return types. The current PQ interface will be left
unchanged and backwards compatible for retrieving rows of a single
type.

Also there should be an settable option that specifies that "*" should
also return the normally ignored columns of oid and classname. This is
so that OO programs that embed SQL into them also get back the oid and
classname which are required for the behind the scenes implementation
of an ODMG client. Something like...

SET SHOW_OID TRUE;
SHOW_CLASSNAME TRUE;

SELECT * FROM person;

OID CLASSNAME NAME
-------------------
2344 person Fred
3445 person Bill

OID CLASSNAME NAME | STUDENTID | FACULTY
-----------------------------------------
2355 student Jim | 23455 | Science
5655 student Chris| 45666 | Arts

From bouncefilter Wed Feb 2 21:31:24 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA19688;
Wed, 2 Feb 2000 21:31:02 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA28084;
Wed, 2 Feb 2000 21:08:46 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002030208.VAA28084@candle.pha.pa.us>
Subject: Re: [GENERAL] Proposed Changes to PostgreSQL
In-Reply-To: <3898DA32.793A98BA@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 3, 2000 12:30:26 pm"
To: chris@bitmead.com
Date: Wed, 2 Feb 2000 21:08:46 -0500 (EST)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>,
pgsql-sql@postgresql.org, pgsql-general@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

THESE CHANGES DON'T AFFECT YOU IF YOU DON'T USE INHERITANCE.

Speak now about these changes or please, forever hold your peace. Of
course you can comment later if I screw up implementation.

The proposed changes are....

1) An imaginary field in every tuple that tells you the class it came
from.
This is useful when you select from table* and want to know which
relation the object actually came from. It wouldn't be stored on disk,
and like oid it wouldn't be displayed when you do SELECT *. The field
would be called classname. So you could have...
SELECT p.classname, p.name FROM person p;
person | Fred
student | Bill
employee | Jim
person | Chris

So the field is created on the fly to show what table it came from.
Seems like a good idea, though implementing another usually-invisible
column will be tough. However, because it is not really a column like
the oid is a column, it should be ok. Of course, internally it is
relid.

2) Changing the sense of the default for getting inherited tuples.
Currently you only get inherited tuples if you specify "tablename*".
This would be changed so that you get all sub-class tuples too by
default unless you specify "ONLY tablename". There are several
rationale for this. Firstly this is what Illustra/Informix have
implemented. Secondly, I believe it is more logical from an OO
perspective as well as giving a more useful default. If a politician
IS a person and I say SELECT * from person, then logically I should
see all the politicians because they are people too (so they claim
:). Thirdly, there are a whole range of SQL statements that should
probably be disallowed without including sub-classes. e.g. an ALTER
TABLE ADD COLUMN that does not include sub-classes is almost certainly
undesirable. It seems ashame to have to resort to non-standard SQL
with the "*" syntax in this case when it is really your only
choice. Basicly, wanting ONLY a classname is a far more unusual
choice, and leaving off the "*" is a common error. Fourthly, it seems
out of character for the SQL language to have this single character
operator. The SQL style is to use wordy descriptions of the operators
meaning. "ONLY" fits well here because it describes its own meaning
perfectly whereas to the unitiated, "*" is harder to guess at. While
this change is an incompatibility I hope for those few people using
inheritance they can accept the need to move forward without
over-burden of backwards compatibility.

Sounds fine to me. Just realize you are taking on a long-overdue but
big job here.

3) The ability to return different types of rows from a SELECT. This
is to allow implementation of ODBMS functionality where a query could
be required to instantiate objects of differing types with differing
attributes.

This bothers me. We return relational data, showing the same number of
columns and types for every query. I don't think we want to change
that, even for OO. How are you going to return that info the the client
side?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 2 21:16:24 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA15546
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 21:15:32 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id LAA11041; Thu, 03 Feb 2000 11:14:00 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
Date: Thu, 3 Feb 2000 11:19:52 +0900
Message-ID: <000701bf6ded$27b037c0$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <24207.949539602@sss.pgh.pa.us>

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, February 03, 2000 10:00 AM

This seems to solve Oliver's problem, and the regress tests still pass,
so I committed it a little while ago.

Is there anything wrong with inserting heap_close(relation, NoLock)
immediately before 'continue;' ?

We can do that if it turns out my analysis is wrong and RowShareLock
should indeed be grabbed on views as well as their underlying tables.

I couldn't judge whether the following current behavior has some meaning
or not.

Let v be a view;

Session-1
begin;
lock table v in exclusive mode; (I don't know what this means)

Session-2
begin;
select * from v for update;
(blocked by Session-1)

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Feb 2 21:49:26 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA24573;
Wed, 2 Feb 2000 21:48:40 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
NAA27722; Thu, 3 Feb 2000 13:48:08 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd031IgZ;
Thu Feb 3 13:47:52 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
NAA07529; Thu, 3 Feb 2000 13:47:50 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0RhPSS; Thu Feb 3 13:47:05 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA10100;
Thu, 3 Feb 2000 13:47:05 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
NAA08163; Thu, 3 Feb 2000 13:46:24 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3898EBCA.2ADFE390@nimrod.itg.telecom.com.au>
Date: Thu, 03 Feb 2000 13:45:31 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>,
pgsql-sql@postgresql.org, pgsql-general@postgresql.org
Subject: Re: [GENERAL] Proposed Changes to PostgreSQL
References: <200002030208.VAA28084@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

So the field is created on the fly to show what table it came from.
Seems like a good idea, though implementing another usually-invisible
column will be tough.

What problems do you forsee?

However, because it is not really a column like
the oid is a column, it should be ok. Of course, internally it is
relid.

2) Changing the sense of the default for getting inherited tuples.
Currently you only get inherited tuples if you specify "tablename*".

Sounds fine to me. Just realize you are taking on a long-overdue but
big job here.

I already have a patch for this one. The change is a few pretty simple
changes
to gram.y.

3) The ability to return different types of rows from a SELECT. This
is to allow implementation of ODBMS functionality where a query could
be required to instantiate objects of differing types with differing
attributes.

This bothers me. We return relational data, showing the same number of
columns and types for every query. I don't think we want to change
that, even for OO.

What aspects bother you? This is the fundamental important thing about
object databases.

It's also something that I'm always wanting to do when generating web
pages.
I have web links like http://foo.com/page?id=123. I want to retrieve
the webpage object (which is an inheritance hierarchy) of id=123 which
may
represent a web page of different types. Then process appropriately for
different objects. i.e. typical OO polymorphism.

How are you going to return that info the the client side?

Well the backend <-> frontend protocol that used to be able to return
tuples of different types would be put back in.

Also the berkerly postgres docs had other scenarios where different
tuples
could be returned. One is you could have a field of type postquel called
say
EMP.hobbies which had a value of "retrieve HOBBIES.all where...", and
then "retrieve
EMP.hobbies would return tuples of different types of hobbies.

From bouncefilter Wed Feb 2 21:56:25 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA26130;
Wed, 2 Feb 2000 21:55:48 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA24652;
Wed, 2 Feb 2000 21:55:19 -0500 (EST)
To: chris@bitmead.com
cc: pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [SQL] Proposed Changes to PostgreSQL
In-reply-to: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Thu, 03 Feb 2000 12:30:26 +1100"
Date: Wed, 02 Feb 2000 21:55:19 -0500
Message-ID: <24649.949546519@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

[ I trimmed the cc list a bit ]

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

The proposed changes are....

1) An imaginary field in every tuple that tells you the class it came
from.
This is useful when you select from table* and want to know which
relation the object actually came from. It wouldn't be stored on disk,
and like oid it wouldn't be displayed when you do SELECT *. The field
would be called classname. So you could have...
SELECT p.classname, p.name FROM person p;

This is a good idea, but it seems to me that it'd fit into the system
traditions better if the pseudo-field gave the OID of the source
relation. If you wanted the actual name of the relation, you'd need
to join against pg_class. You could argue it either way I suppose;
a name would be more convenient for simple interactive uses, but an
OID would probably be more convenient and efficient for applications
using this feature. I tend to lean towards the programmatic convenience
side --- far more SQL queries are issued by programs than humans.

2) Changing the sense of the default for getting inherited tuples.
Currently you only get inherited tuples if you specify "tablename*".
This would be changed so that you get all sub-class tuples too by
default unless you specify "ONLY tablename". There are several
rationale for this. Firstly this is what Illustra/Informix have
implemented. Secondly, I believe it is more logical from an OO
perspective as well as giving a more useful default.

Well, mumble. That would be the cleanest choice if we were designing
in a green field, but we aren't. You're talking about breaking every
single extant Postgres application that uses inheritance, and possibly
some that don't use it except as a shorthand for making their schemas
more compact. (That's not a hypothetical case; I have DBs that use
schema inheritance but never do SELECT FROM table*.) I think that's
a mighty high price to pay for achieving a little more logical
cleanliness.

There is also a nontrivial performance penalty that would be paid
for reversing this default, because then every ordinary SQL query
would suffer the overhead of looking to see whether there are
child tables for each table named in the query. That *really*
doesn't strike me as a good idea.

If Illustra were popular enough to have defined an industry standard
about inheritance, I might think we should follow their lead --- but
who else has followed their lead?

In short, I vote for leaving well enough alone. It's not so badly
wrong as to be intolerable, and the pain of changing looks high.

Thirdly, there are a whole range of SQL statements that should
probably be disallowed without including sub-classes. e.g. an ALTER
TABLE ADD COLUMN that does not include sub-classes is almost certainly
undesirable.

This is true. We could either silently add *, or reject it ("hey bozo,
have you forgotten that this table has subclasses?"). The reject
option would be more conservative, just in case the admin *has*
forgotten that the table has subclasses --- as a crude analogy,
Unix "rm" doesn't assume "-r" by default ;-). I agree that allowing
an ALTER to make a parent table inconsistent with its children is
very bad news and should be prevented. (Dropping an inherited column
is another example of something we shouldn't allow.)

I would propose that that anytime you do a SELECT * from a base table
that you would get back the full rows from those sub tables.

Frankly: ugh. This doesn't square with *my* ideas of object
inheritance. When you are dealing with something that ISA person,
you do not really want to hear about any additional properties it may
have; you are dealing with it as a person and not at any finer grain of
detail. That goes double for dealing with whole collections of persons.
If you want to examine a particular member of the collection and
dynamically downcast it to some more-specific type, the proposed
classname/classoid feature will give you the ability to do that;
but I think it's a mistake to assume that this should happen by default.

Since the current PQ interface which doesn't support this notion would
remain unchanged this wouldn't affect current users.

How would you implement this without actually breaking the current
PQ interface?

It's probably also desirable to have a syntax for getting just the
columns of the base table when this is desired. Say perhaps SELECT %
from table. This would be a performance hack for users of libpq and a
functionality difference for users of psql.

Again, I think you've got the default backwards. I remind you also
of something we've been beating on Peter about: psql is an application
scripting tool, so you don't get to redefine its behavior at whim,
anymore than you can change libpq's API at whim.

In addition it would be legal to specify columns that only exist in
sub-classes. For example,
it would be legal to say...

SELECT *, studentid FROM person;

Yipes. I really, really, really DON'T like that one. At the level
of table person, studentid is unequivocally an invalid column name.
If you do this, you couldn't even guarantee that different subtables
that had studentid columns would have compatible datatypes for those
columns.

SELECT * FROM person;

OID CLASSNAME NAME
-------------------
2344 person Fred
3445 person Bill

OID CLASSNAME NAME | STUDENTID | FACULTY
-----------------------------------------
2355 student Jim | 23455 | Science
5655 student Chris| 45666 | Arts

This is not too hard for a person to make sense of, but I think that
it'd be mighty unwieldy for a program to deal with. What would the
libpq-like interface look like, and what would a typical client
routine look like?

regards, tom lane

From bouncefilter Wed Feb 2 21:58:25 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA26686;
Wed, 2 Feb 2000 21:58:05 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA00457;
Wed, 2 Feb 2000 21:57:48 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002030257.VAA00457@candle.pha.pa.us>
Subject: Re: [GENERAL] Proposed Changes to PostgreSQL
In-Reply-To: <3898EBCA.2ADFE390@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 3, 2000 01:45:31 pm"
To: chris@bitmead.com
Date: Wed, 2 Feb 2000 21:57:48 -0500 (EST)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>,
pgsql-sql@postgresql.org, pgsql-general@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

So the field is created on the fly to show what table it came from.
Seems like a good idea, though implementing another usually-invisible
column will be tough.

What problems do you forsee?

Well, it is usually pretty strange to carry around a column that doesn't
exist through all the code and finally contruct it at the end. I would
suspect something in the rewrite system could do that pretty easily,
though. That is the direction I would go with that.

However, because it is not really a column like
the oid is a column, it should be ok. Of course, internally it is
relid.

2) Changing the sense of the default for getting inherited tuples.
Currently you only get inherited tuples if you specify "tablename*".

Sounds fine to me. Just realize you are taking on a long-overdue but
big job here.

I already have a patch for this one. The change is a few pretty simple
changes
to gram.y.

OK, you will have to canvas the general list to make sure this does not
break things for people, though our inheritance system needs an overhaul
badly.

3) The ability to return different types of rows from a SELECT. This
is to allow implementation of ODBMS functionality where a query could
be required to instantiate objects of differing types with differing
attributes.

This bothers me. We return relational data, showing the same number of
columns and types for every query. I don't think we want to change
that, even for OO.

What aspects bother you? This is the fundamental important thing about
object databases.

I fear it is totally against the way our API works. How does someone
see how many columns in the returned row?

How are you going to return that info the the client side?

Well the backend <-> frontend protocol that used to be able to return
tuples of different types would be put back in.

Also the berkerly postgres docs had other scenarios where different
tuples
could be returned. One is you could have a field of type postquel called
say
EMP.hobbies which had a value of "retrieve HOBBIES.all where...", and
then "retrieve
EMP.hobbies would return tuples of different types of hobbies.

Yikes. Strange. Can we just return nulls for the empty fields?

How many new API calls are required?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 2 22:11:24 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA33346
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 22:10:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA24718;
Wed, 2 Feb 2000 22:10:14 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
In-reply-to: <000701bf6ded$27b037c0$2801007e@tpf.co.jp>
References: <000701bf6ded$27b037c0$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Thu, 03 Feb 2000 11:19:52 +0900"
Date: Wed, 02 Feb 2000 22:10:13 -0500
Message-ID: <24715.949547413@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

I couldn't judge whether the following current behavior has some meaning
or not.

Let v be a view;

lock table v in exclusive mode; (I don't know what this means)

Good question ... but it seems to me that it has to mean grabbing
exclusive lock on the table(s) referred to by v. Otherwise, if
client A locks the view and client B locks the underlying table
directly, they'll both pass the lock and be able to access/modify
the underlying table at the same time. That can't be right.

The rewriter correctly passes SELECT FOR UPDATE locking from the
view to the referenced tables, but I'm not sure whether it is
bright enough to do the same for LOCK statements. (Jan?)

regards, tom lane

From bouncefilter Wed Feb 2 22:42:25 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA42861;
Wed, 2 Feb 2000 22:41:30 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA27142;
Wed, 2 Feb 2000 23:38:05 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 2 Feb 2000 23:38:05 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: chris@bitmead.com, pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-Reply-To: <24649.949546519@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0002022334200.25537-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 2 Feb 2000, Tom Lane wrote:

2) Changing the sense of the default for getting inherited tuples.
Currently you only get inherited tuples if you specify "tablename*".
This would be changed so that you get all sub-class tuples too by
default unless you specify "ONLY tablename". There are several
rationale for this. Firstly this is what Illustra/Informix have
implemented. Secondly, I believe it is more logical from an OO
perspective as well as giving a more useful default.

Well, mumble. That would be the cleanest choice if we were designing
in a green field, but we aren't. You're talking about breaking every
single extant Postgres application that uses inheritance, and possibly
some that don't use it except as a shorthand for making their schemas
more compact. (That's not a hypothetical case; I have DBs that use
schema inheritance but never do SELECT FROM table*.) I think that's
a mighty high price to pay for achieving a little more logical
cleanliness.

There is also a nontrivial performance penalty that would be paid
for reversing this default, because then every ordinary SQL query
would suffer the overhead of looking to see whether there are
child tables for each table named in the query. That *really*
doesn't strike me as a good idea.

If Illustra were popular enough to have defined an industry standard
about inheritance, I might think we should follow their lead --- but
who else has followed their lead?

In short, I vote for leaving well enough alone. It's not so badly
wrong as to be intolerable, and the pain of changing looks high.

Could this be implemented/patched in using #ifdef's, so that you could
configure using --old-style-inheritance so that those that require it
still have it, giving applications a chance to catch up?

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Wed Feb 2 22:40:25 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA42625
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 22:40:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA24819;
Wed, 2 Feb 2000 22:39:48 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL
In-reply-to: <200002030257.VAA00457@candle.pha.pa.us>
References: <200002030257.VAA00457@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Wed, 02 Feb 2000 21:57:48 -0500"
Date: Wed, 02 Feb 2000 22:39:48 -0500
Message-ID: <24816.949549188@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

So the field is created on the fly to show what table it came from.
Seems like a good idea, though implementing another usually-invisible
column will be tough.

What problems do you forsee?

Well, it is usually pretty strange to carry around a column that doesn't
exist through all the code and finally contruct it at the end. I would
suspect something in the rewrite system could do that pretty easily,
though. That is the direction I would go with that.

Yeah. In fact, since the field is not required except on specific
user request (explicit SELECT, or if you like Chris' SET SHOW_CLASSNAME
idea, that'd still get translated into a SELECT target item at some
pretty early stage), I don't see any need for it to get added to the
HeapTupleHeader fields. That makes the implementation a *lot* cleaner
because you wouldn't need in-memory HeapTupleHeader to be different from
on-disk headers. I'm visualizing this as a parameterless function (or
maybe a new primitive expression node type) that gets evaluated during
ExecProject's construction of the output tuple for a a bottom-level
seqscan or indexscan plan node. The only trick is to persuade the
planner to push it down to the bottom level; normally anything that
isn't a Var gets evaluated at the top of the plan tree.

This bothers me. We return relational data, showing the same number of
columns and types for every query. I don't think we want to change
that, even for OO.

My thought also. If we had a *real* object orientation, then a returned
column would have an abstract data type that might correspond to an
object supertype. Of course that just pushes the problem down a level:
how does the application know what methods the returned object has?
How can it even invoke those methods --- whatever code might exist
for them would live on the server, presumably, not get shipped around
in query results.

regards, tom lane

From bouncefilter Wed Feb 2 22:45:25 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA43597;
Wed, 2 Feb 2000 22:45:02 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA19723; Thu, 3 Feb 2000 14:44:30 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdL.h0j_;
Thu Feb 3 14:44:05 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA24663; Thu, 3 Feb 2000 14:44:03 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0Bc29n; Thu Feb 3 14:42:49 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA28662;
Thu, 3 Feb 2000 14:42:44 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
OAA10118; Thu, 3 Feb 2000 14:42:04 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3898F8DE.8159BFE7@nimrod.itg.telecom.com.au>
Date: Thu, 03 Feb 2000 14:41:18 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<24649.949546519@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

1) An imaginary field in every tuple that tells you the class it came

This is a good idea, but it seems to me that it'd fit into the system
traditions better if the pseudo-field gave the OID of the source
relation.

This was my initial thought too, but then it occured to me that SQL
doesn't normally deal in oids. For example you don't do a DROP TABLE
oid;

OTOH, oids are probably programmatically useful for things like ODBMSs.

What do you think about having both? I know you can go from one to the
other by joining with pg_class, but that's too inconvenient, and I can't
make up my mind which is the better "system tradition" either.

I'm not overly fussed on this point though.

Well, mumble. That would be the cleanest choice if we were designing
in a green field, but we aren't. You're talking about breaking every
single extant Postgres application that uses inheritance, and possibly
some that don't use it except as a shorthand for making their schemas
more compact. (That's not a hypothetical case; I have DBs that use
schema inheritance but never do SELECT FROM table*.) I think that's
a mighty high price to pay for achieving a little more logical
cleanliness.

Ok, well compatibility is always a contentious thing. But in your case
you are mis-using the inheritance feature.

The question is, are you willing to do the (simple) changes to your
code to cater for the common good? I'm wanting to make postgresql into a
REAL odbms, and this is a stumbling point that will eventually affect
100x
as many users as it does now (I hope :).

We can also leave the old gram.y for people who want to retain
compatibility
for longer.

There is also a nontrivial performance penalty that would be paid
for reversing this default, because then every ordinary SQL query
would suffer the overhead of looking to see whether there are
child tables for each table named in the query. That *really*
doesn't strike me as a good idea.

I can't comment on what the current performance penalty would be, but
I'm sure this can be optimised to be a completely trivial overhead.

If Illustra were popular enough to have defined an industry standard
about inheritance, I might think we should follow their lead --- but
who else has followed their lead?

Well Informix of course, which is not small potatoes.

I would propose that that anytime you do a SELECT * from a base table
that you would get back the full rows from those sub tables.

Frankly: ugh. This doesn't square with *my* ideas of object
inheritance. When you are dealing with something that ISA person,
you do not really want to hear about any additional properties it may
have; you are dealing with it as a person and not at any finer grain of
detail. That goes double for dealing with whole collections of persons.
If you want to examine a particular member of the collection and
dynamically downcast it to some more-specific type, the proposed
classname/classoid feature will give you the ability to do that;
but I think it's a mistake to assume that this should happen by default.

This would be the case if the database were the whole world. But it is
not,
it is a repository for applications written in other languages. How can
you
"dynamically downcast to a more specific type" if the database hasn't
returned
the columns of the more specific type? How can I instantiate a C++
object of
type "Student" if the database has only returned to me the data members
of type
"Person"?

Since the current PQ interface which doesn't support this notion would
remain unchanged this wouldn't affect current users.

How would you implement this without actually breaking the current
PQ interface?

By adding new functions for use when you need to access the extra
columns.

It's probably also desirable to have a syntax for getting just the
columns of the base table when this is desired. Say perhaps SELECT %
from table. This would be a performance hack for users of libpq and a
functionality difference for users of psql.

Again, I think you've got the default backwards. I remind you also
of something we've been beating on Peter about: psql is an application
scripting tool, so you don't get to redefine its behavior at whim,
anymore than you can change libpq's API at whim.

I am less adamant about the default in this scenario than in the "ONLY
table"
scenario. I'm a bit concerned about the fact that this would break
compatibility with OQL standards, but I can live with this.

In addition it would be legal to specify columns that only exist in
sub-classes. For example,
it would be legal to say...

SELECT *, studentid FROM person;

Yipes. I really, really, really DON'T like that one. At the level
of table person, studentid is unequivocally an invalid column name.

The reason for this is you need some kind of compromise between seeing
every single column (which overwhelms you in psql) and not seeing any
sub-type columns at all.

If you do this, you couldn't even guarantee that different subtables
that had studentid columns would have compatible datatypes for those
columns.

I think you can because postgres won't let you create sub-types with
column of the same name with incompatible data types. In fact it is
this very fact about postgres that makes this feature feasible.

SELECT * FROM person;

OID CLASSNAME NAME
-------------------
2344 person Fred
3445 person Bill

OID CLASSNAME NAME | STUDENTID | FACULTY
-----------------------------------------
2355 student Jim | 23455 | Science
5655 student Chris| 45666 | Arts

This is not too hard for a person to make sense of, but I think that
it'd be mighty unwieldy for a program to deal with. What would the
libpq-like interface look like, and what would a typical client
routine look like?

The PQ interface would have a new function something like
PQnfieldsv(PQresult,tuplenum),
so it returns a different number for each tuple.

But the real benefit is not writing "unwieldy" code in C, but ODBMS
style code where you
can go...
List<Shape> l = query("SELECT * FROM shape");
Shape *s;
for (l.begin(); s = l.get(); l.next())
s.display();

Because if the dbms returns ALL the columns, a C++ runtime system can
properly instantiate subtypes and use polymorphism.

From bouncefilter Wed Feb 2 22:52:25 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA45114;
Wed, 2 Feb 2000 22:52:18 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA26467; Thu, 3 Feb 2000 14:51:46 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdTnls1_;
Thu Feb 3 14:51:17 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA04731; Thu, 3 Feb 2000 14:51:16 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0j5jgw; Thu Feb 3 14:50:16 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA06218;
Thu, 3 Feb 2000 14:50:12 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
OAA10470; Thu, 3 Feb 2000 14:49:32 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3898FA9E.22D33715@nimrod.itg.telecom.com.au>
Date: Thu, 03 Feb 2000 14:48:46 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>,
pgsql-sql@postgresql.org, pgsql-general@postgresql.org
Subject: Re: [GENERAL] Proposed Changes to PostgreSQL
References: <200002030257.VAA00457@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

I already have a patch for this one. The change is a few pretty simple
changes
to gram.y.

OK, you will have to canvas the general list to make sure this does not
break things for people, though our inheritance system needs an overhaul
badly.

This is already CCed to the general list.

I fear it is totally against the way our API works. How does someone
see how many columns in the returned row?

A new API PQnfieldsv(PQresult, tupnum) or some such.

Yikes. Strange.

Strange for C code perhaps. Very useful for constructing real objects in
OO application code framework.

Can we just return nulls for the empty fields?

Well, I think we should probably distinguish between a field that is
null,
and a field that simply doesn't exist.

How many new API calls are required?

Perhaps just the one. (above).

From bouncefilter Wed Feb 2 23:04:10 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA46772
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 22:59:34 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA03192; Thu, 3 Feb 2000 14:59:02 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdlF2B6_;
Thu Feb 3 14:58:49 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA14254; Thu, 3 Feb 2000 14:58:48 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdybHvg_; Thu Feb 3 14:57:42 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA12263;
Thu, 3 Feb 2000 14:57:41 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
OAA10797; Thu, 3 Feb 2000 14:57:01 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3898FC60.E4436ED5@nimrod.itg.telecom.com.au>
Date: Thu, 03 Feb 2000 14:56:16 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
Subject: Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL
References: <200002030257.VAA00457@candle.pha.pa.us>
<24816.949549188@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

This bothers me. We return relational data, showing the same number of
columns and types for every query. I don't think we want to change
that, even for OO.

My thought also. If we had a *real* object orientation, then a returned
column would have an abstract data type that might correspond to an
object supertype. Of course that just pushes the problem down a level:
how does the application know what methods the returned object has?
How can it even invoke those methods --- whatever code might exist
for them would live on the server, presumably, not get shipped around
in query results.

In (most) ODBMSes, the code for a class does NOT live in the database
server. (How
would you store a C++ binary in a database?).

What happens is when a query returns an object, some magic behind the
scenes
checks the type of the returned object (thus the need for the
"classname" column
or similar.) The magic behind the scenes then instantiates a C++ object
of
the correct class and populates all the data members from the query
results.

The application code is then free to make polymorphic calls on the
object
because ALL the fields are populated, not just those of the base class.

From bouncefilter Wed Feb 2 23:04:27 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA47180;
Wed, 2 Feb 2000 23:00:25 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA03891; Thu, 3 Feb 2000 14:59:48 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdkS_5A_;
Thu Feb 3 14:59:27 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA15359; Thu, 3 Feb 2000 14:59:26 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdhfzgF_; Thu Feb 3 14:58:38 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA13111;
Thu, 3 Feb 2000 14:58:38 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
OAA10840; Thu, 3 Feb 2000 14:57:57 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3898FC97.8EB813C6@nimrod.itg.telecom.com.au>
Date: Thu, 03 Feb 2000 14:57:12 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com,
pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <Pine.BSF.4.21.0002022334200.25537-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The Hermit Hacker wrote:

Could this be implemented/patched in using #ifdef's, so that you could
configure using --old-style-inheritance so that those that require it
still have it, giving applications a chance to catch up?

Sounds like an excellent idea, although I'm not sure how to ifdef a .y
bison file.

From bouncefilter Wed Feb 2 23:03:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA47997
for <pgsql-hackers@postgreSQL.org>; Wed, 2 Feb 2000 23:01:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA03721;
Wed, 2 Feb 2000 22:58:41 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002030358.WAA03721@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL
In-Reply-To: <24816.949549188@sss.pgh.pa.us> from Tom Lane at "Feb 2,
2000 10:39:48 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 2 Feb 2000 22:58:41 -0500 (EST)
CC: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yeah. In fact, since the field is not required except on specific
user request (explicit SELECT, or if you like Chris' SET SHOW_CLASSNAME
idea, that'd still get translated into a SELECT target item at some
pretty early stage), I don't see any need for it to get added to the
HeapTupleHeader fields. That makes the implementation a *lot* cleaner
because you wouldn't need in-memory HeapTupleHeader to be different from
on-disk headers. I'm visualizing this as a parameterless function (or
maybe a new primitive expression node type) that gets evaluated during
ExecProject's construction of the output tuple for a a bottom-level
seqscan or indexscan plan node. The only trick is to persuade the
planner to push it down to the bottom level; normally anything that
isn't a Var gets evaluated at the top of the plan tree.

Yes, I agree this is a good way to do it.

This bothers me. We return relational data, showing the same number of
columns and types for every query. I don't think we want to change
that, even for OO.

My thought also. If we had a *real* object orientation, then a returned
column would have an abstract data type that might correspond to an
object supertype. Of course that just pushes the problem down a level:
how does the application know what methods the returned object has?
How can it even invoke those methods --- whatever code might exist
for them would live on the server, presumably, not get shipped around
in query results.

Agreed.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 2 23:06:25 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA52159;
Wed, 2 Feb 2000 23:05:29 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA03844;
Wed, 2 Feb 2000 23:02:44 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002030402.XAA03844@candle.pha.pa.us>
Subject: Re: [SQL] Proposed Changes to PostgreSQL
In-Reply-To: <3898F8DE.8159BFE7@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 3, 2000 02:41:18 pm"
To: chris@bitmead.com
Date: Wed, 2 Feb 2000 23:02:44 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

1) An imaginary field in every tuple that tells you the class it came

This is a good idea, but it seems to me that it'd fit into the system
traditions better if the pseudo-field gave the OID of the source
relation.

This was my initial thought too, but then it occured to me that SQL
doesn't normally deal in oids. For example you don't do a DROP TABLE
oid;

OTOH, oids are probably programmatically useful for things like ODBMSs.

What do you think about having both? I know you can go from one to the
other by joining with pg_class, but that's too inconvenient, and I can't
make up my mind which is the better "system tradition" either.

Sure, let them have both. Why not, or you could force them to join to
pg_class for the name. That would work too.

Ok, well compatibility is always a contentious thing. But in your case
you are mis-using the inheritance feature.

The question is, are you willing to do the (simple) changes to your
code to cater for the common good? I'm wanting to make postgresql into a
REAL odbms, and this is a stumbling point that will eventually affect
100x
as many users as it does now (I hope :).

We can also leave the old gram.y for people who want to retain
compatibility
for longer.

I would canvas the list to find out how many people object, and if there
are few, you may be able to get away with something in config.h.in that
they can change if they want the old behavour.

Since the current PQ interface which doesn't support this notion would
remain unchanged this wouldn't affect current users.

How would you implement this without actually breaking the current
PQ interface?

By adding new functions for use when you need to access the extra
columns.

Whatever it is, the API has to be lean and clean.

I saw your PQnfieldsv, and that looks fine to me.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 2 23:04:29 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA50948;
Wed, 2 Feb 2000 23:03:28 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA03857;
Wed, 2 Feb 2000 23:03:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002030403.XAA03857@candle.pha.pa.us>
Subject: Re: [GENERAL] Proposed Changes to PostgreSQL
In-Reply-To: <3898FA9E.22D33715@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 3, 2000 02:48:46 pm"
To: chris@bitmead.com
Date: Wed, 2 Feb 2000 23:03:14 -0500 (EST)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I can live with this. Thanks.

Bruce Momjian wrote:

I already have a patch for this one. The change is a few pretty simple
changes
to gram.y.

OK, you will have to canvas the general list to make sure this does not
break things for people, though our inheritance system needs an overhaul
badly.

This is already CCed to the general list.

I fear it is totally against the way our API works. How does someone
see how many columns in the returned row?

A new API PQnfieldsv(PQresult, tupnum) or some such.

Yikes. Strange.

Strange for C code perhaps. Very useful for constructing real objects in
OO application code framework.

Can we just return nulls for the empty fields?

Well, I think we should probably distinguish between a field that is
null,
and a field that simply doesn't exist.

How many new API calls are required?

Perhaps just the one. (above).

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 2 23:14:25 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA54645;
Wed, 2 Feb 2000 23:14:07 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA16664; Thu, 3 Feb 2000 15:13:35 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd31D_a_;
Thu Feb 3 15:13:15 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA04527; Thu, 3 Feb 2000 15:13:13 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd35KgY_; Thu Feb 3 15:12:32 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA25557;
Thu, 3 Feb 2000 15:12:31 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
PAA11350; Thu, 3 Feb 2000 15:11:47 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <3898FFD5.5D40C507@nimrod.itg.telecom.com.au>
Date: Thu, 03 Feb 2000 15:11:01 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<24649.949546519@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Again, I think you've got the default backwards. I remind you also
of something we've been beating on Peter about: psql is an application
scripting tool, so you don't get to redefine its behavior at whim,
anymore than you can change libpq's API at whim.

If this is the only objection, we could make the old behaviour available
by a SET command, as well as a command-line switch, as well as a
./configure option.

I hope we can get the best design here possible without over-emphasis
on compatibility.

From bouncefilter Wed Feb 2 23:23:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA57198;
Wed, 2 Feb 2000 23:23:03 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA04499;
Wed, 2 Feb 2000 23:22:05 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002030422.XAA04499@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-Reply-To: <3898FFD5.5D40C507@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 3, 2000 03:11:01 pm"
To: chris@bitmead.com
Date: Wed, 2 Feb 2000 23:22:05 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Again, I think you've got the default backwards. I remind you also
of something we've been beating on Peter about: psql is an application
scripting tool, so you don't get to redefine its behavior at whim,
anymore than you can change libpq's API at whim.

If this is the only objection, we could make the old behaviour available
by a SET command, as well as a command-line switch, as well as a
./configure option.

I hope we can get the best design here possible without over-emphasis
on compatibility.

SET command is probably the best.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 3 00:14:35 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA76197;
Thu, 3 Feb 2000 00:13:40 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA13124;
Wed, 2 Feb 2000 21:11:56 -0800 (PST)
Message-Id: <3.0.1.32.20000202210952.0086dd60@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 02 Feb 2000 21:09:52 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Cc: pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
In-Reply-To: <24649.949546519@sss.pgh.pa.us>
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3898DA32.793A98BA@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:55 PM 2/2/00 -0500, Tom Lane wrote:

There is also a nontrivial performance penalty that would be paid
for reversing this default, because then every ordinary SQL query
would suffer the overhead of looking to see whether there are
child tables for each table named in the query. That *really*
doesn't strike me as a good idea.

Thank you for pointing this out, because my first reaction to
the proposal was "what's the overhead for SQL users"?

Given the stated goals of becoming a fast, efficient, reliable
SQL engine, this has to be a crucial consideration.

On the other hand, as someone who once made his living off his
designed and implemented optimizing multi-language, multi-platform
compiler technology...is it entirely out of the question to
consider more greatly abstracting the language (gram.y/analyze.c)
and backend (optimizer and executor) interfaces so more than one
front-end could exist (even if only in experimental and research
environments)? Along with front-end specific versions of libpq?

These front-ends wouldn't necessarily need to be supported by
the mainstream PG development group, except to support a defined
and sufficiently abstract interface to the optimization/planning and
executing guts of the system so that folks could mess around to
their heart's content. And bear the burden of doing so if they
pick up users :)

Just a thought...

I would propose that that anytime you do a SELECT * from a base table
that you would get back the full rows from those sub tables.

Frankly: ugh. This doesn't square with *my* ideas of object
inheritance.

Nor mine, in fact the stuff I've seen about primitive OO in databases
make me thing the folks just don't get it.

Not to mention that I'm not convinced that "getting it" is worth it. OO
fits some paradigms, not others, when programming in the large. And
most database stuff is really programming in the small (the query parts,
the data is often huge, of course). The notion of asking a query, as
in (say) psql is more related to the notion of typing a few lines at
BASIC than the notion of writing a few million lines of integrated
code. In database design, even more so than in conventional programming,
it is the data model that reigns supreme and the actual size tends to
be manageable, though the models themselves can be very complex.

I offer this as a reason why commercial DB users are more concerned
with things like performance, scalability, and the like than with
reworking of the RDBMS paradigm. Complaints about queries seem to
place heavy emphasis on "why they are slow", and the OO paradigm
doesn't help here. I'm not certain that psuedo-OO features help.

One reason I raise the issue of possible multiple front-ends (or making
it easy for folks to make there own by making the parser->optimizer/backend
interface more general) is that this whole area would seem to be one
that begs for RESEARCH and experimentalism.

The reality, AFAIK, is that in the crucible of commercial use, real
OO databases and thinking simply haven't penetrated.

Nor is Postgres written in C++ :) (GOOD decision to abandon that
thought, IMO, though at the moment I'm working on C++ tools for
my current client).

Again, I think you've got the default backwards. I remind you also
of something we've been beating on Peter about: psql is an application
scripting tool, so you don't get to redefine its behavior at whim,
anymore than you can change libpq's API at whim.

Yeah, this is VERY important.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Thu Feb 3 00:40:26 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA84413;
Thu, 3 Feb 2000 00:40:21 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA22075; Thu, 3 Feb 2000 16:39:49 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0uc1aD;
Thu Feb 3 16:39:42 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA10971; Thu, 3 Feb 2000 16:39:41 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0OCs6e; Thu Feb 3 16:39:35 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA29023;
Thu, 3 Feb 2000 16:39:34 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA14377; Thu, 3 Feb 2000 16:38:53 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38991440.6ED3B94@nimrod.itg.telecom.com.au>
Date: Thu, 03 Feb 2000 16:38:08 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3.0.1.32.20000202210952.0086dd60@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

Given the stated goals of becoming a fast, efficient, reliable
SQL engine, this has to be a crucial consideration.

I'm sure this can be made fast.

On the other hand, as someone who once made his living off his
designed and implemented optimizing multi-language, multi-platform
compiler technology...is it entirely out of the question to
consider more greatly abstracting the language (gram.y/analyze.c)
and backend (optimizer and executor) interfaces so more than one
front-end could exist (even if only in experimental and research
environments)? Along with front-end specific versions of libpq?

A good thought, but we still need one good front end that supports
all the features.

I would propose that that anytime you do a SELECT * from a base table
that you would get back the full rows from those sub tables.

Frankly: ugh. This doesn't square with *my* ideas of object
inheritance.

Nor mine, in fact the stuff I've seen about primitive OO in databases
make me thing the folks just don't get it.

Not to mention that I'm not convinced that "getting it" is worth it. OO
fits some paradigms, not others, when programming in the large.

Well, the features I'm talking about don't affect you unless you want
OO.

And
most database stuff is really programming in the small (the query parts,
the data is often huge, of course). The notion of asking a query, as
in (say) psql is more related to the notion of typing a few lines at
BASIC than the notion of writing a few million lines of integrated
code. In database design, even more so than in conventional programming,
it is the data model that reigns supreme and the actual size tends to
be manageable, though the models themselves can be very complex.

And as those models become so complex it is crucial that the data-model
that
"reigns supreme" is properly integrated with the programming language.

For example, in an IBM Java project I'm working on there is 15000 lines
of
code that converts about 10 or so SQL tables into Java objects. Insane
stuff.

I offer this as a reason why commercial DB users are more concerned
with things like performance, scalability, and the like than with
reworking of the RDBMS paradigm.

Actually developers are very interested in supporting the ODBMS paradigm
as you can see from the Sun proposed standard for RDBMS interface which
is an exact copy of the ODMG ODBMS interface standard.

In fact I think about 90% of "stuff" is best solved with an ODBMS
style of interaction. The trouble is that most ODBMS don't do the other
10% very well (i.e. wierd and wonderful queries), which is where
postgresql _could_ be the ultimate at solving both.

Complaints about queries seem to
place heavy emphasis on "why they are slow", and the OO paradigm
doesn't help here.

Huh? The OO paradigm helps heaps here because you can model something
with a far smaller number of tables.

I'm not certain that psuedo-OO features help.

Don't know what a pseudo-OO feature is.

One reason I raise the issue of possible multiple front-ends (or making
it easy for folks to make there own by making the parser->optimizer/backend
interface more general) is that this whole area would seem to be one
that begs for RESEARCH and experimentalism.

No research is required. I simply want to implement the ODMG STANDARD
for ODBMS databases on PostgreSQL. There are no great design issues
here,
just a matter of nailing down the details so that everyone can live
with them.

The reality, AFAIK, is that in the crucible of commercial use, real
OO databases and thinking simply haven't penetrated.

Not really true. In certain areas ODBMSes are pervasive. For example
many
Telco companies use ODBMSes for the majority of their stuff. It's
necessary
to get the performance they need. Also of course CAD apps can only use
an ODBMS.

No offence, but you havn't actually used one have you?

From bouncefilter Thu Feb 3 08:53:32 2000
Received: from hotmail.com (f4.law4.hotmail.com [216.33.149.4])
by hub.org (8.9.3/8.9.3) with SMTP id IAA24036
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 08:53:07 -0500 (EST)
(envelope-from nubeiro@hotmail.com)
Received: (qmail 98060 invoked by uid 0); 3 Feb 2000 13:52:33 -0000
Message-ID: <20000203135233.98059.qmail@hotmail.com>
Received: from 193.146.41.106 by www.hotmail.com with HTTP;
Thu, 03 Feb 2000 05:52:33 PST
X-Originating-IP: [193.146.41.106]
From: "O Nubeiro" <nubeiro@hotmail.com>
To: pgsql-hackers@postgreSQL.org
Date: Thu, 03 Feb 2000 05:52:33 PST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

unsubscribe
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From bouncefilter Thu Feb 3 01:11:31 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA96021;
Thu, 3 Feb 2000 01:10:34 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA03437; Thu, 3 Feb 2000 17:10:01 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdKtscV_;
Thu Feb 3 17:09:40 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA27020; Thu, 3 Feb 2000 17:09:38 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdk5jvm_; Thu Feb 3 17:09:14 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA10173;
Thu, 3 Feb 2000 17:09:10 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
RAA15417; Thu, 3 Feb 2000 17:08:29 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38991B2B.939F93CC@nimrod.itg.telecom.com.au>
Date: Thu, 03 Feb 2000 17:07:40 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3.0.1.32.20000202210952.0086dd60@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

At 09:55 PM 2/2/00 -0500, Tom Lane wrote:

There is also a nontrivial performance penalty that would be paid
for reversing this default, because then every ordinary SQL query
would suffer the overhead of looking to see whether there are
child tables for each table named in the query. That *really*
doesn't strike me as a good idea.

Thank you for pointing this out, because my first reaction to
the proposal was "what's the overhead for SQL users"?

I just did a performance check on this. I found that the overhead
is one tenth of a millisecond on a Sun desktop workstation. Pretty
trivial, and I'm sure it can be improved.

From bouncefilter Thu Feb 3 01:27:27 2000
Received: from serv0.ilse.net (serv0.ilse.nl [194.158.182.236])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA97909;
Thu, 3 Feb 2000 01:26:46 -0500 (EST) (envelope-from mathijs@ilse.nl)
Received: (from mathijs@localhost) by serv0.ilse.net (8.8.8/8.6.12) id
HAA00438; Thu, 3 Feb 2000 07:25:15 +0100 (MET)
Date: Thu, 3 Feb 2000 07:25:15 +0100
From: Mathijs Brands <mathijs@ilse.nl>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
Subject: Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL
Message-ID: <20000203072514.B174@ilse.nl>
References: <3898EBCA.2ADFE390@nimrod.itg.telecom.com.au>
<200002030257.VAA00457@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200002030257.VAA00457@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Wed, Feb 02, 2000 at 09:57:48PM
-0500
X-Unexpected-Header: The Spanish Inquisition

On Wed, Feb 02, 2000 at 09:57:48PM -0500, Bruce Momjian allegedly wrote:

3) The ability to return different types of rows from a SELECT. This
is to allow implementation of ODBMS functionality where a query could
be required to instantiate objects of differing types with differing
attributes.

This bothers me. We return relational data, showing the same number of
columns and types for every query. I don't think we want to change
that, even for OO.

What aspects bother you? This is the fundamental important thing about
object databases.

I fear it is totally against the way our API works. How does someone
see how many columns in the returned row?

This would probably break applications written in PHP and Perl (and
possibly others) that have their queryresults returned to them in a
numerically indexed array (index by offset). If this behaviour could
be turned off, than it shouldn't be a problem.

Mathijs

From bouncefilter Thu Feb 3 01:35:27 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA02402;
Thu, 3 Feb 2000 01:34:29 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA15981; Thu, 3 Feb 2000 17:33:55 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdl0uvl_;
Thu Feb 3 17:33:11 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA14061; Thu, 3 Feb 2000 17:33:09 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdxGA1._; Thu Feb 3 17:31:12 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA20762;
Thu, 3 Feb 2000 17:31:11 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
RAA16195; Thu, 3 Feb 2000 17:30:26 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38992052.8BA1702E@nimrod.itg.telecom.com.au>
Date: Thu, 03 Feb 2000 17:29:38 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Mathijs Brands <mathijs@ilse.nl>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
Subject: Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL
References: <3898EBCA.2ADFE390@nimrod.itg.telecom.com.au>
<200002030257.VAA00457@candle.pha.pa.us>
<20000203072514.B174@ilse.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mathijs Brands wrote:

On Wed, Feb 02, 2000 at 09:57:48PM -0500, Bruce Momjian allegedly wrote:

3) The ability to return different types of rows from a SELECT. This
is to allow implementation of ODBMS functionality where a query could
be required to instantiate objects of differing types with differing
attributes.

This bothers me. We return relational data, showing the same number of
columns and types for every query. I don't think we want to change
that, even for OO.

What aspects bother you? This is the fundamental important thing about
object databases.

I fear it is totally against the way our API works. How does someone
see how many columns in the returned row?

This would probably break applications written in PHP and Perl (and
possibly others) that have their queryresults returned to them in a
numerically indexed array (index by offset). If this behaviour could
be turned off, than it shouldn't be a problem.

It wouldn't affect them because the current APIs would continue to
return
the same base-level columns. You would only get access to the extra
columns
with a new API.

From bouncefilter Thu Feb 3 02:00:27 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA07087;
Thu, 3 Feb 2000 02:00:21 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA26718;
Thu, 3 Feb 2000 02:00:10 -0500 (EST)
To: chris@bitmead.com
cc: pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-reply-to: <3898F8DE.8159BFE7@nimrod.itg.telecom.com.au>
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<24649.949546519@sss.pgh.pa.us>
<3898F8DE.8159BFE7@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Thu, 03 Feb 2000 14:41:18 +1100"
Date: Thu, 03 Feb 2000 02:00:09 -0500
Message-ID: <26715.949561209@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Tom Lane wrote:

1) An imaginary field in every tuple that tells you the class it came

This is a good idea, but it seems to me that it'd fit into the system
traditions better if the pseudo-field gave the OID of the source
relation.

What do you think about having both? I know you can go from one to the
other by joining with pg_class, but that's too inconvenient, and I can't
make up my mind which is the better "system tradition" either.

If we can implement it as I sketched before, there's no reason not to
offer both, since either one would create zero overhead for any query
not using the feature.

I'll comment on the other issues later ... but I will say that I don't
think it's acceptable to add *any* overhead to standard-SQL queries
in order to support inheritance better. The vast majority of our users
want SQL performance and don't give a damn about inheritance. We have
to pay attention to that.

regards, tom lane

From bouncefilter Thu Feb 3 04:18:29 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA41811;
Thu, 3 Feb 2000 04:17:43 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id UAA28874;
Thu, 3 Feb 2000 20:17:13 +1100
Sender: chris@tech.com.au
Message-ID: <38994796.36079744@bitmead.com>
Date: Thu, 03 Feb 2000 20:17:10 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<24649.949546519@sss.pgh.pa.us>
<3898F8DE.8159BFE7@nimrod.itg.telecom.com.au>
<26715.949561209@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

I'll comment on the other issues later ... but I will say that I don't
think it's acceptable to add *any* overhead to standard-SQL queries
in order to support inheritance better. The vast majority of our users
want SQL performance and don't give a damn about inheritance. We have
to pay attention to that.

Well I see that pg_class has columns like "relhasindex". If we added a
"relhassubclass", the overhead should be unmeasureable.

From bouncefilter Thu Feb 3 04:53:29 2000
Received: from hu.tm.ee (ppp907.tele2.ee [212.107.37.207])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA51070;
Thu, 3 Feb 2000 04:53:28 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id EDF263987; Thu, 3 Feb 2000 12:00:20 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389951B4.51E74B47@tm.ee>
Date: Thu, 03 Feb 2000 12:00:20 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3.0.1.32.20000202210952.0086dd60@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

The reality, AFAIK, is that in the crucible of commercial use, real
OO databases and thinking simply haven't penetrated.

AFAIK Informix integrated most OO features from Illustra into their UDB
and also latest versions of Oracle have moved a lot in that direction too.

Nor is Postgres written in C++ :)

what does C++ have to do with OO ;)

----------------------
Hannu

From bouncefilter Thu Feb 3 05:05:29 2000
Received: from vpcit.ru (qmailr@dialup.vpcit.ru [195.38.52.246])
by hub.org (8.9.3/8.9.3) with SMTP id FAA58072
for <pgsql-general@postgreSQL.org>; Thu, 3 Feb 2000 05:04:37 -0500 (EST)
(envelope-from yura@vpcit.ru)
Received: (qmail 31886 invoked from network); 3 Feb 2000 10:04:34 -0000
Received: from gercon.vpcit.ru (195.38.52.226)
by dialup.vpcit.ru with SMTP; 3 Feb 2000 10:04:34 -0000
Date: Thu, 3 Feb 2000 15:03:57 +0500
From: Yury Don <yura@vpcit.ru>
X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational
Reply-To: Yury Don <yura@vpcit.ru>
Organization: Gercon
X-Priority: 3 (Normal)
Message-ID: <3627.000203@vpcit.ru>
To: pgsql-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Proposed Changes to PostgreSQL
In-reply-To: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Chris,

Once, Thursday, February 03, 2000, 6:30:26 AM, you wrote:

CB> 1) An imaginary field in every tuple that tells you the class it came
CB> from.
CB> This is useful when you select from table* and want to know which
CB> relation the object actually came from. It wouldn't be stored on disk,
CB> and like oid it wouldn't be displayed when you do SELECT *. The field
CB> would be called classname. So you could have...
CB> SELECT p.classname, p.name FROM person p;
CB> person | Fred
CB> student | Bill
CB> employee | Jim
CB> person | Chris

I am voting for this by both hands. Now we forced to use an additional
column classname in every table and rule to fill this column.

CB> 2) Changing the sense of the default for getting inherited tuples.
CB> Currently you only get inherited tuples if you specify "tablename*".
CB> This would be changed so that you get all sub-class tuples too by
CB> default unless you specify "ONLY tablename". There are several
CB> rationale for this. Firstly this is what Illustra/Informix have
CB> implemented. Secondly, I believe it is more logical from an OO
CB> perspective as well as giving a more useful default. If a politician
CB> IS a person and I say SELECT * from person, then logically I should
CB> see all the politicians because they are people too (so they claim
CB> :). Thirdly, there are a whole range of SQL statements that should
CB> probably be disallowed without including sub-classes. e.g. an ALTER
CB> TABLE ADD COLUMN that does not include sub-classes is almost certainly
CB> undesirable. It seems ashame to have to resort to non-standard SQL
CB> with the "*" syntax in this case when it is really your only
CB> choice. Basicly, wanting ONLY a classname is a far more unusual
CB> choice, and leaving off the "*" is a common error. Fourthly, it seems
CB> out of character for the SQL language to have this single character
CB> operator. The SQL style is to use wordy descriptions of the operators
CB> meaning. "ONLY" fits well here because it describes its own meaning
CB> perfectly whereas to the unitiated, "*" is harder to guess at. While
CB> this change is an incompatibility I hope for those few people using
CB> inheritance they can accept the need to move forward without
CB> over-burden of backwards compatibility.

Sounds very logically.

--
Best regards,
Yury ICQ 11831432
mailto:yura@vpcit.ru

From bouncefilter Thu Feb 3 04:59:29 2000
Received: from hu.tm.ee (ppp907.tele2.ee [212.107.37.207])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA52029;
Thu, 3 Feb 2000 04:59:10 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 9CF443987; Thu, 3 Feb 2000 12:06:09 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38995311.AA81CA4A@tm.ee>
Date: Thu, 03 Feb 2000 12:06:09 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Proposed Changes to PostgreSQL
References: <200002030257.VAA00457@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Bruce Momjian wrote:

So the field is created on the fly to show what table it came from.
Seems like a good idea, though implementing another usually-invisible
column will be tough.

What problems do you forsee?

Well, it is usually pretty strange to carry around a column that doesn't
exist through all the code and finally contruct it at the end. I would
suspect something in the rewrite system could do that pretty easily,
though. That is the direction I would go with that.

Oracle has a ROWNR (IIRC) pseudo-column that is added in th every end of
query and is a convienient way to put numbers on report rows (among other
things).

------------
Hannu

From bouncefilter Thu Feb 3 05:04:31 2000
Received: from hu.tm.ee (ppp907.tele2.ee [212.107.37.207])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA57907;
Thu, 3 Feb 2000 05:03:48 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 2C4CC3987; Thu, 3 Feb 2000 12:10:47 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38995427.8F48CAA5@tm.ee>
Date: Thu, 03 Feb 2000 12:10:47 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Proposed Changes to PostgreSQL
References: <200002030257.VAA00457@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Yikes. Strange. Can we just return nulls for the empty fields?

I think more natural way would be to define a new type (NAF - NotAFiled),
like we have NAN for floats (do we ?, at least IEEE has)

-----------------
Hannu

From bouncefilter Thu Feb 3 05:24:30 2000
Received: from hu.tm.ee (ppp907.tele2.ee [212.107.37.207])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA62607;
Thu, 3 Feb 2000 05:24:24 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id BD0153987; Thu, 3 Feb 2000 12:31:23 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389958FB.2E6927B5@tm.ee>
Date: Thu, 03 Feb 2000 12:31:23 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: chris@bitmead.com
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<24649.949546519@sss.pgh.pa.us>
<3898F8DE.8159BFE7@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Bitmead wrote:

Tom Lane wrote:

1) An imaginary field in every tuple that tells you the class it came

This is a good idea, but it seems to me that it'd fit into the system
traditions better if the pseudo-field gave the OID of the source
relation.

This was my initial thought too, but then it occured to me that SQL
doesn't normally deal in oids. For example you don't do a DROP TABLE
oid;

DROP TABLE (SELECT relname FROM pg_class WHERE oid=the_oid);

would be cool ;)

I would propose that that anytime you do a SELECT * from a base table
that you would get back the full rows from those sub tables.

Maybe SELECT ** FROM BASE would be more flexible as it leaves the standard
SQL with its "standard" meaning ?

Frankly: ugh. This doesn't square with *my* ideas of object
inheritance. When you are dealing with something that ISA person,
you do not really want to hear about any additional properties it may
have; you are dealing with it as a person and not at any finer grain of
detail. That goes double for dealing with whole collections of persons.
If you want to examine a particular member of the collection and
dynamically downcast it to some more-specific type, the proposed
classname/classoid feature will give you the ability to do that;
but I think it's a mistake to assume that this should happen by default.

This would be the case if the database were the whole world. But it is
not,
it is a repository for applications written in other languages. How can
you
"dynamically downcast to a more specific type" if the database hasn't
returned
the columns of the more specific type? How can I instantiate a C++
object of
type "Student" if the database has only returned to me the data members
of type
"Person"?

You could do as some DB's (IIRC Oracle) do with large objects - return the
whole row if doing a select that has many rows.

return just a handle when going over a cursor with FETCH 1 and then have
calls to get the rest.

We will have to change the API sometime not too distant anyway, the current
api is unable to deal with anything that does not have a nice textual
representation (like an image or sound) in spite of all the talks about
easy extensibility - the extensibility is all in the backend, ther is no
easy way to get new datatypes in/out.

---------------
Hannu

From bouncefilter Thu Feb 3 05:49:31 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA70945;
Thu, 3 Feb 2000 05:49:07 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id VAA29627;
Thu, 3 Feb 2000 21:46:45 +1100
Sender: chris@tech.com.au
Message-ID: <38995C95.38897035@bitmead.com>
Date: Thu, 03 Feb 2000 21:46:45 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Hannu Krosing <hannu@tm.ee>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<24649.949546519@sss.pgh.pa.us>
<3898F8DE.8159BFE7@nimrod.itg.telecom.com.au>
<389958FB.2E6927B5@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hannu Krosing wrote:

Maybe SELECT ** FROM BASE would be more flexible as it leaves the standard
SQL with its "standard" meaning ?

That was my first thought and it's definitely a possibility. My argument
against it is that SQL doesn't have a "standard meaning" in the case of
inheritance, and ** is an incompatibility with OQL.

I suspect we need both. Something like
SET GET_INHERITED_COLUMNS true; etc.

We will have to change the API sometime not too distant anyway, the current
api is unable to deal with anything that does not have a nice textual
representation (like an image or sound) in spite of all the talks about
easy extensibility - the extensibility is all in the backend, ther is no
easy way to get new datatypes in/out.

What about PQbinaryTuples() and friends?

From bouncefilter Thu Feb 3 06:05:30 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id GAA77046
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 06:04:29 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12GJt0-0003kbC; Thu, 3 Feb 100 11:53 MET
Message-Id: <m12GJt0-0003kbC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
In-Reply-To: <24715.949547413@sss.pgh.pa.us> from Tom Lane at "Feb 2,
2000 10:10:13 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 3 Feb 2000 11:53:18 +0100 (CET)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

I couldn't judge whether the following current behavior has some meaning
or not.

Let v be a view;

lock table v in exclusive mode; (I don't know what this means)

Good question ... but it seems to me that it has to mean grabbing
exclusive lock on the table(s) referred to by v. Otherwise, if
client A locks the view and client B locks the underlying table
directly, they'll both pass the lock and be able to access/modify
the underlying table at the same time. That can't be right.

The rewriter correctly passes SELECT FOR UPDATE locking from the
view to the referenced tables, but I'm not sure whether it is
bright enough to do the same for LOCK statements. (Jan?)

Isn't LOCK TABLE a utility statement? So it doesn't go
through the rewriter.

The LOCK code would have to do the correct locking of the
underlying tables. And not to forget cascaded views or
possible subselects.

Actually LockTableCommand() in command.c doesn't do it. It
simply locks the view relation, what's definitely wrong.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Thu Feb 3 06:27:30 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA80275
for <pgsql-hackers@postgresql.org>; Thu, 3 Feb 2000 06:27:05 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12GKNM-0000hm-00; Thu, 3 Feb 2000 11:24:40 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12GKNH-0000Pz-00; Thu, 3 Feb 2000 11:24:35 +0000
Date: Thu, 3 Feb 2000 11:24:34 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
Message-ID: <20000203112434.B1509@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <12080.949370550@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Mon, Jan 31, 2000 at 09:02:30PM -0500

On Mon, Jan 31, 2000 at 09:02:30PM -0500, Tom Lane wrote:

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

Tom Lane wrote:

There are cache-flush-related bugs still left to deal with, but they
seem to be far lower in probability than the ones squashed so far.
I'm finding that even with MAXNUMMESSAGES set to 8, the parallel tests
usually pass; so it seems we need some other way of testing to nail down
the remaining problems.

I also tried that nonsensical join from the other day, and it failed in
the same way again:
newnham=# select * from crsids,"tblPerson" where
newnham-# crsids.crsid != "tblPerson"."CRSID";
Backend sent B message without prior T

Hmm. Can you provide a self-contained test case (a script to build the
failing tables, preferably)?

It seems this is a memory exhaustion thing: I have 128Mb real memory.
Attached below is the C program used to create some random data in
tables test and test2 of database test (which needs to exist). Executing
the non-sensical query

select * from test,test2 where test.i!=test2.i;

should result in 2600*599=1557400 (ie lots of) rows to be returned.
The process's memory consumption during this select grows to 128Mb, and after
a moment or two:

Backend sent D message without prior T
Backend sent D message without prior T
...

Which isn't quite the same message as before, but is of the same type.

59 processes: 2 running, 57 sleeping
CPU states: 2.3% user, 86.4% nice, 9.3% system, 0.0% interrupt, 1.9% idle
Memory: 74M Act, 37M Inact, 184K Wired, 364K Free, 95M Swap, 262M Swap free

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
1547 prlw1 50 0 128M 516K run 1:28 59.28% 59.28% psql
1552 postgres 50 0 1920K 632K run 1:37 24.32% 24.32% postgres

later, while the "Backend sent..." messages appear

1547 prlw1 -5 0 128M 68M sleep 1:41 23.00% 23.00% psql
1552 postgres 2 0 1920K 4K sleep 1:41 141.00% 6.88% <postgres>

Note that there is still plenty of swap space. The 128Mb number seems to be
more than a coincidence (how to prove?)

So, is this only happening to me? How can lack of real memory affect timing
of interprocess communication?

Cheers,

Patrick

==========================================================================

#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>

#include "libpq-fe.h"

const char *progname;

PGresult *send_query(PGconn *db, const char *query)
{
PGresult *res;

res=PQexec(db,query);
switch(PQresultStatus(res))
{
case PGRES_EMPTY_QUERY:
printf("PGRES_EMPTY_QUERY: %s\n",query);
break;
case PGRES_COMMAND_OK:
printf("PGRES_COMMAND_OK: %s\n",query);
break;
case PGRES_TUPLES_OK:
printf("PGRES_TUPLES_OK: %s\n",query);
break;
case PGRES_COPY_OUT:
printf("PGRES_COPY_OUT: %s\n",query);
break;
case PGRES_COPY_IN:
printf("PGRES_COPY_IN: %s\n",query);
break;
case PGRES_BAD_RESPONSE:
printf("PGRES_BAD_RESPONSE: %s\n",query);
exit(1);
break;
case PGRES_NONFATAL_ERROR:
printf("PGRES_NONFATAL_ERROR: %s\n",query);
break;
case PGRES_FATAL_ERROR:
printf("PGRES_FATAL_ERROR: %s\n",query);
exit(1);
break;
default:
fprintf(stderr,"Error from %s: Unknown response from "\
"PQresultStatus()\n",progname);
exit(1);
break;
}

return res;
}

char get_letter(void)
{
int c;

do c=(int)random()%128;
while(!(isascii(c)&&isalpha(c)));

return (char)tolower(c);
}

unsigned int get_num(void)
{
return random()%100;
}

int main(int argc, char* argv[])
{
char id[7],query[2048];
int i;
PGconn *db;
PGresult *res;

progname=argv[0];

srandom(42); /* same data each time hopefully */

db=PQconnectdb("dbname=test");
if(PQstatus(db)==CONNECTION_BAD)
{
fprintf(stderr,"Error from %s: Unable to connect to database \"test\".\n",
progname);
exit(1);
}

res=send_query(db,"create table test (txt text,var varchar(7),i integer)");
PQclear(res);
res=send_query(db,"create table test2(txt text,var varchar(7),i integer)");
PQclear(res);

for(i=1;i<=2600;++i)
{
sprintf(id,"%c%c%c%c%03u",get_letter(),get_letter(),get_letter(),
get_letter(),get_num());

sprintf(query,"insert into test values ('%s','%s','%i')",id,id,i);
res=send_query(db,query);
PQclear(res);
}

for(i=1;i<=600;++i)
{
sprintf(id,"%c%c%c%c%03u",get_letter(),get_letter(),get_letter(),
get_letter(),get_num());

sprintf(query,"insert into test2 values ('%s','%s','%i')",id,id,i);
res=send_query(db,query);
PQclear(res);
}

PQfinish(db);

return 0;
}

From bouncefilter Thu Feb 3 07:21:31 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA95161;
Thu, 3 Feb 2000 07:20:37 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
HAA20081;
Thu, 3 Feb 2000 07:09:18 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002031209.HAA20081@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-Reply-To: <38991B2B.939F93CC@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 3, 2000 05:07:40 pm"
To: chris@bitmead.com
Date: Thu, 3 Feb 2000 07:09:18 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

At 09:55 PM 2/2/00 -0500, Tom Lane wrote:

There is also a nontrivial performance penalty that would be paid
for reversing this default, because then every ordinary SQL query
would suffer the overhead of looking to see whether there are
child tables for each table named in the query. That *really*
doesn't strike me as a good idea.

Thank you for pointing this out, because my first reaction to
the proposal was "what's the overhead for SQL users"?

I just did a performance check on this. I found that the overhead
is one tenth of a millisecond on a Sun desktop workstation. Pretty
trivial, and I'm sure it can be improved.

Good point. Has to be non-mearurable performance penalty because most
people don't use it. Maybe you will need a system cache entry for this.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 3 07:22:32 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA95333;
Thu, 3 Feb 2000 07:21:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
HAA20196;
Thu, 3 Feb 2000 07:13:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002031213.HAA20196@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-Reply-To: <38994796.36079744@bitmead.com> from Chris at "Feb 3,
2000 08:17:10 pm"
To: Chris <chris@bitmead.com>
Date: Thu, 3 Feb 2000 07:13:36 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

I'll comment on the other issues later ... but I will say that I don't
think it's acceptable to add *any* overhead to standard-SQL queries
in order to support inheritance better. The vast majority of our users
want SQL performance and don't give a damn about inheritance. We have
to pay attention to that.

Well I see that pg_class has columns like "relhasindex". If we added a
"relhassubclass", the overhead should be unmeasureable.

Yes, but how do you keep that accurate? If I add indexes, then drop
them, does relhasindex go to false. Could you do that for relhassubclass?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 3 07:15:31 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA93825
for <pgsql-hackers@postgresql.org>; Thu, 3 Feb 2000 07:14:31 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12GL9b-0000jo-00; Thu, 3 Feb 2000 12:14:31 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12GL9W-0000Qi-00; Thu, 3 Feb 2000 12:14:26 +0000
Date: Thu, 3 Feb 2000 12:14:26 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: prlw1@cam.ac.uk
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
Message-ID: <20000203121426.D1509@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <20000203112434.B1509@quartz.newn.cam.ac.uk>;
from prlw1@newn.cam.ac.uk on Thu, Feb 03, 2000 at 11:24:34AM +0000

On Thu, Feb 03, 2000 at 11:24:34AM +0000, Patrick Welche wrote:

char id[7],query[2048];

^
should be 8 to be safe..

From bouncefilter Thu Feb 3 07:25:31 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA95978
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 07:24:58 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
HAA20668;
Thu, 3 Feb 2000 07:22:11 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002031222.HAA20668@candle.pha.pa.us>
Subject: Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
In-Reply-To: <m12GJt0-0003kbC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Feb 3, 2000 11:53:18 am"
To: Jan Wieck <wieck@debis.com>
Date: Thu, 3 Feb 2000 07:22:11 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The rewriter correctly passes SELECT FOR UPDATE locking from the
view to the referenced tables, but I'm not sure whether it is
bright enough to do the same for LOCK statements. (Jan?)

Isn't LOCK TABLE a utility statement? So it doesn't go
through the rewriter.

The LOCK code would have to do the correct locking of the
underlying tables. And not to forget cascaded views or
possible subselects.

Actually LockTableCommand() in command.c doesn't do it. It
simply locks the view relation, what's definitely wrong.

Added to TODO:

* Disallow LOCK on view

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 3 07:31:32 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA98622;
Thu, 3 Feb 2000 07:30:51 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id XAA30791;
Thu, 3 Feb 2000 23:28:31 +1100
Sender: chris@tech.com.au
Message-ID: <3899746F.9869F4D8@bitmead.com>
Date: Thu, 03 Feb 2000 23:28:31 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <200002031213.HAA20196@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Well I see that pg_class has columns like "relhasindex". If we added a
"relhassubclass", the overhead should be unmeasureable.

Yes, but how do you keep that accurate? If I add indexes, then drop
them, does relhasindex go to false.

I don't know. Does it?

Could you do that for relhassubclass?

If we made it relnumsubclasses and incremented/decremented on
CREATE/DROP, it seems easy in theory.

--
Chris Bitmead
mailto:chris@bitmead.com
http://www.techphoto.org - Photography News, Stuff that Matters

From bouncefilter Thu Feb 3 08:03:31 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA10507;
Thu, 3 Feb 2000 08:03:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
HAA21220;
Thu, 3 Feb 2000 07:37:42 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002031237.HAA21220@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-Reply-To: <3899746F.9869F4D8@bitmead.com> from Chris at "Feb 3,
2000 11:28:31 pm"
To: Chris <chris@bitmead.com>
Date: Thu, 3 Feb 2000 07:37:42 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Well I see that pg_class has columns like "relhasindex". If we added a
"relhassubclass", the overhead should be unmeasureable.

Yes, but how do you keep that accurate? If I add indexes, then drop
them, does relhasindex go to false.

I don't know. Does it?

Oops:

test=> create table test(x int);
CREATE
test=> create index i_test on test(x);
CREATE
test=> select relhasindex from pg_class where relname = 'test';
relhasindex
-------------
t
(1 row)

test=> drop index i_test;
DROP
test=> select relhasindex from pg_class where relname = 'test';
relhasindex
-------------
t
(1 row)

Let me add that to the TODO list.

Could you do that for relhassubclass?

If we made it relnumsubclasses and incremented/decremented on
CREATE/DROP, it seems easy in theory.

Yes, that would work. Seems hasindex has problems.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 3 08:08:33 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA11235;
Thu, 3 Feb 2000 08:07:46 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id AAA31652;
Fri, 4 Feb 2000 00:05:33 +1100
Sender: chris@tech.com.au
Message-ID: <38997D1C.9F353FED@bitmead.com>
Date: Fri, 04 Feb 2000 00:05:32 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <200002031237.HAA21220@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Oops:

test=> drop index i_test;
DROP
test=> select relhasindex from pg_class where relname = 'test';
relhasindex
-------------
t
(1 row)

Let me add that to the TODO list.

Why not change that to a relnumindexes as well? Easier to maintain and
more useful information.

Could you do that for relhassubclass?

If we made it relnumsubclasses and incremented/decremented on
CREATE/DROP, it seems easy in theory.

Yes, that would work. Seems hasindex has problems.

From bouncefilter Thu Feb 3 08:32:51 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA19641;
Thu, 3 Feb 2000 08:32:07 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
IAA22002;
Thu, 3 Feb 2000 08:26:05 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002031326.IAA22002@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-Reply-To: <38997D1C.9F353FED@bitmead.com> from Chris at "Feb 4,
2000 00:05:32 am"
To: Chris <chris@bitmead.com>
Date: Thu, 3 Feb 2000 08:26:05 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org,
pgsql-sql@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Let me add that to the TODO list.

Why not change that to a relnumindexes as well? Easier to maintain and
more useful information.

Yes, we probably should do that, but I bet some interfaces us it.
Comments?

Actually, looks like only pg_dump uses it, so maybe we would be OK.
Maybe 7.0 is a good time to fix this.

Could you do that for relhassubclass?

If we made it relnumsubclasses and incremented/decremented on
CREATE/DROP, it seems easy in theory.

Yes, that would work. Seems hasindex has problems.

************

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 3 08:39:32 2000
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com
[192.135.215.14]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA21501;
Thu, 3 Feb 2000 08:39:25 -0500 (EST)
(envelope-from mhh@nortelnetworks.com)
Received: from zrchb213.us.nortel.com (actually zrchb213)
by smtprch1.nortel.com; Thu, 3 Feb 2000 07:38:39 -0600
Received: from zrtpd003.us.nortel.com ([47.140.224.137])
by zrchb213.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id 1F2TKB5C; Thu, 3 Feb 2000 07:38:31 -0600
Received: from americasm01.nt.com (hrtpp28d.us.nortel.com [47.190.110.250])
by zrtpd003.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id DJLAH580; Thu, 3 Feb 2000 08:38:30 -0500
Message-ID: <38998548.C6C8606A@americasm01.nt.com>
Date: Thu, 03 Feb 2000 08:40:24 -0500
From: "Mark Hollomon" <mhh@nortelnetworks.com>
Reply-To: "Mark Hollomon" <mhh@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: chris@bitmead.com
CC: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <200002030402.XAA03844@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[ discussion on changing the default to getting subclasses ]

I object.

How about a set variable?

SET GETSUBCLASSES = true

With the '*' and ONLY being explicit overrides to the setting
of the variable. The default would be 'false'. I would not
object to a configuration switch that would change the
default.
--

Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008

From bouncefilter Thu Feb 3 09:48:33 2000
Received: from gandalf.telecom.at (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA42913
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 09:47:33 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id PAA19058;
Thu, 3 Feb 2000 15:47:10 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALQBH3>; Thu, 3 Feb 2000 15:47:09 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC238@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'chris@bitmead.com'" <chris@bitmead.com>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Proposed Changes to PostgreSQL
Date: Thu, 3 Feb 2000 15:47:07 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

The SQL style is to use wordy descriptions of the operators
meaning. "ONLY" fits well here because it describes its own meaning
perfectly whereas to the unitiated, "*" is harder to guess at. While
this change is an incompatibility I hope for those few people using
inheritance they can accept the need to move forward without
over-burden of backwards compatibility.

Might also allow the *, but do nothing with it, or maybe throw a
"deprecated" notice.

SELECT *, studentid FROM person;

NAME
----
Fred
Bill

NAME | STUDENTID
----------------
Jim | 23455
Chris| 45666

The above is incorrect, since the * already returns studentid, thus the
result
of the above query should be:

SELECT *, studentid FROM person;

NAME
----
Fred
Bill

NAME | STUDENTID | FACULTY | STUDENTID
--------------------------
Jim | 23455 | Science | 23455
Chris| 45666 | Arts | 45666

Also there should be an settable option that specifies that "*" should
also return the normally ignored columns of oid and classname. This is
so that OO programs that embed SQL into them also get back the oid and
classname which are required for the behind the scenes implementation
of an ODMG client. Something like...

why don't they simply always
select oid, classname, * from ...
The reason I suggest this is, because implementing joins to return the
correct oid, classname seems very complex.

The rest sounds good to me :-)

Andreas

From bouncefilter Thu Feb 3 10:06:33 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA50269
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 10:06:14 -0500 (EST)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (max05-009.enterprise.net [194.72.197.9])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id PAA01408;
Thu, 3 Feb 2000 15:06:12 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id PAA19091;
Thu, 3 Feb 2000 15:06:42 GMT
Message-Id: <200002031506.PAA19091@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: "Oliver Elphick" <olly@lfix.co.uk>, pgsql-hackers@postgreSQL.org,
olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Recent RI changes have broken something
In-Reply-To: Message from Tom Lane <tgl@sss.pgh.pa.us>
of "Wed, 02 Feb 2000 19:04:39 EST." <24021.949536279@sss.pgh.pa.us>
References: <200001312218.WAA32035@linda.lfix.co.uk>
<12134.949370805@sss.pgh.pa.us>
<200002010929.JAA06616@linda.lfix.co.uk>
<24021.949536279@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 03 Feb 2000 15:06:42 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>

Tom Lane wrote:

"Oliver Elphick" <olly@lfix.co.uk> writes:

ERROR: RelationClearRelation: relation 21645 modified while in use

This is probably my fault. Can you provide a simple test case?
The two table declarations might be enough.

I think this is fixed now. Hopefully I didn't break SELECT FOR UPDATE
while I was at it.

Yes, it is fixed from my point of view. I can't say about SELECT FOR
UPDATE...

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"O come, let us worship and bow down; let us kneel
before the LORD our maker." Psalms 95:6

From bouncefilter Thu Feb 3 10:25:33 2000
Received: from gandalf.telecom.at (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA55366;
Thu, 3 Feb 2000 10:24:54 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id QAA151004;
Thu, 3 Feb 2000 16:21:04 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALQBPW>; Thu, 3 Feb 2000 16:21:04 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC239@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Hannu Krosing'" <hannu@tm.ee>, "'chris@bitmead.com'" <chris@bitmead.com>
Cc: "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'pgsql-hackers@postgresql.org'"
<pgsql-hackers@postgresql.org>, "'pgsql-sql@postgresql.org'"
<pgsql-sql@postgresql.org>
Subject: AW: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Date: Thu, 3 Feb 2000 16:21:03 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

I would propose that that anytime you do a SELECT *

from a base table

that you would get back the full rows from those sub tables.

Maybe SELECT ** FROM BASE would be more flexible as it leaves
the standard
SQL with its "standard" meaning ?

I like the idea of not messing with the traditional meaning of the *.
The Informix select * from table_with_subclasses also only returns
the parent columns.

Of course I would also like that the default select * from table
return all subclass rows.

Imho there is no real argument against extra syntax to select
all columns of subclasses though.

Andreas

From bouncefilter Thu Feb 3 10:31:33 2000
Received: from gandalf.telecom.at (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA57882
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 10:30:37 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id QAA195782
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 16:30:34 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALQBRF>; Thu, 3 Feb 2000 16:30:33 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC23A@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
Date: Thu, 3 Feb 2000 16:30:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Added to TODO:

* Disallow LOCK on view

I really think we should give views a different relkind 'V'.
All this mess with a real table + rules is very unclean.
It is then clear that such a relkind does'nt have locks.
Then it would also be easy to readd some of the now lost features
like computed columns ...

I would instead add the following TODO:
* create new relkind 'V' for views

Andreas

From bouncefilter Thu Feb 3 10:52:35 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA77326;
Thu, 3 Feb 2000 10:52:22 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA28298;
Thu, 3 Feb 2000 07:49:23 -0800 (PST)
Message-Id: <3.0.1.32.20000203073928.00fc2ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 03 Feb 2000 07:39:28 -0800
To: chris@bitmead.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Cc: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
In-Reply-To: <38991440.6ED3B94@nimrod.itg.telecom.com.au>
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3.0.1.32.20000202210952.0086dd60@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:38 PM 2/3/00 +1100, Chris Bitmead wrote:

Don Baccus wrote:

On the other hand, as someone who once made his living off his
designed and implemented optimizing multi-language, multi-platform
compiler technology...is it entirely out of the question to
consider more greatly abstracting the language (gram.y/analyze.c)
and backend (optimizer and executor) interfaces so more than one
front-end could exist (even if only in experimental and research
environments)? Along with front-end specific versions of libpq?

A good thought, but we still need one good front end that supports
all the features.

I wasn't think in terms of this being mutually exclusive with your
desires. Merely raising up the notion that the possibility exists
of creating a sandbox, so to speak, for people to play in, a tool
for the exploration of such concepts.

Nor mine, in fact the stuff I've seen about primitive OO in databases
make me thing the folks just don't get it.

Not to mention that I'm not convinced that "getting it" is worth it. OO
fits some paradigms, not others, when programming in the large.

Well, the features I'm talking about don't affect you unless you want
OO.

No, and I wasn't arguing that you shouldn't move forward, either. I
was just stating my personal opinion regarding the utility of simple
OO-ish features, that's all.

One reason I raise the issue of possible multiple front-ends (or making
it easy for folks to make there own by making the parser->optimizer/backend
interface more general) is that this whole area would seem to be one
that begs for RESEARCH and experimentalism.

No research is required. I simply want to implement the ODMG STANDARD
for ODBMS databases on PostgreSQL. There are no great design issues
here,
just a matter of nailing down the details so that everyone can live
with them.

Well...that's sorta like saying no research into procedural language
design is needed 'cause now we've got C++.

Whether or not the existing standard for ODBMS is the greatest thing
since sliced bread, I find it hard to believe that no research is
required or design issues raised by the fundamental problems of
database technology.

Maybe I'm wrong, though, maybe the problem's been solved.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Thu Feb 3 10:52:34 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA77246;
Thu, 3 Feb 2000 10:51:53 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA28347;
Thu, 3 Feb 2000 07:49:34 -0800 (PST)
Message-Id: <3.0.1.32.20000203074208.00fc58d0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 03 Feb 2000 07:42:08 -0800
To: Hannu Krosing <hannu@tm.ee>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Cc: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
In-Reply-To: <389951B4.51E74B47@tm.ee>
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3.0.1.32.20000202210952.0086dd60@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:00 PM 2/3/00 +0200, Hannu Krosing wrote:

Don Baccus wrote:

what does C++ have to do with OO ;)

Nothing, but don't tell them :) Having worked on C++ compilers,
don't get me started on THAT subject!

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Thu Feb 3 10:54:34 2000
Received: from thelab.hub.org (nat198.40.mpoweredpc.net [142.177.198.40])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA77670
for <pgsql-hackers@postgresql.org>; Thu, 3 Feb 2000 10:54:23 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA33331
for <pgsql-hackers@postgresql.org>; Thu, 3 Feb 2000 11:54:20 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 3 Feb 2000 11:54:20 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: SERIAL type isn't listed...?
Message-ID: <Pine.BSF.4.21.0002031153280.25537-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Shouldn't this produce something? Was talking with Dave Page today about
the lack of a serial type in PgAdmin, and he mentioned that its not a listed
type?

template1=> SELECT typname FROM pg_type WHERE typrelid = 0 and typname='serial';
typname
---------
(0 rows)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Thu Feb 3 11:27:34 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA87208;
Thu, 3 Feb 2000 11:26:35 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA27995;
Thu, 3 Feb 2000 11:26:11 -0500 (EST)
To: Chris <chris@bitmead.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-reply-to: <38997D1C.9F353FED@bitmead.com>
References: <200002031237.HAA21220@candle.pha.pa.us>
<38997D1C.9F353FED@bitmead.com>
Comments: In-reply-to Chris <chris@bitmead.com>
message dated "Fri, 04 Feb 2000 00:05:32 +1100"
Date: Thu, 03 Feb 2000 11:26:11 -0500
Message-ID: <27991.949595171@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris <chris@bitmead.com> writes:

Why not change that to a relnumindexes as well? Easier to maintain and
more useful information.

Maintaining an accurate count of descendants (or indexes for that
matter) would be expensive; in particular, it'd create severe
concurrency problems. If one transaction is in the middle of creating
or dropping a child C of table P, then all other transactions would be
blocked from creating or dropping any other children of P until the C
transaction commits or aborts. They'd have to wait or they wouldn't
know what to set relnumchildren to.

For the purpose at hand, I think it would be OK to have a
"relhaschildren" field that is set true when the first child is created
and then never changed. If you have a table that once had children but
has none at the moment, then you pay the price of looking through
pg_inherits; but the case that we're really concerned about (a pure SQL,
no-inheritance table) would still win.

Not sure whether we can concurrently create/delete indexes on a rel,
but I'd be inclined to leave relhasindexes alone: again its main
function in life is to let you short-circuit looking for indexes on
a table that's never had and never will have any.

regards, tom lane

From bouncefilter Thu Feb 3 11:27:36 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA87266;
Thu, 3 Feb 2000 11:26:59 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Katt.DoCS.UU.SE (e99re41@Katt.DoCS.UU.SE [130.238.9.90])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA13058;
Thu, 3 Feb 2000 17:26:52 +0100 (MET)
Received: from localhost (e99re41@localhost) by Katt.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id RAA10988; Thu, 3 Feb 2000 17:26:51 +0100
X-Authentication-Warning: Katt.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 3 Feb 2000 17:26:50 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Chris Bitmead <chris@bitmead.com>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
Subject: Re: [HACKERS] Proposed Changes to PostgreSQL
In-Reply-To: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
Message-ID: <Pine.GSO.4.02A.10002031705390.10941-100000@Katt.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

While I think that these kinds of changes are a No Go because they'd break
a lot of applications (including mine), IF (big if) you really want to
make major changes to the inheritance scheme, I got a few ideas.

First let me say that I like the conceptual simplicity of relational
databases. Some or all of the ideas thrown around here break with
simplicity and consistency, by suggesting, e.g., that some commands be
allowed only on entire inheritance structures, while others be allowed on
individual tables, and attached to it a discussion which ones those should
be. That doesn't strike me as too promising.

A lot of people use inheritance to create "consistent schemas", that is,
they empty create base tables, such as "address" which are inherited by
tables such as customer, vendor, office, etc. That is probably not what
inheritance is for, perhaps it should be some sort of a macro-like
concept, such as create table vendor (name text,
copy_schema_from(address), more fields), expanded by the parser. This is
pretty much what it does now, only this scheme wouldn't have to actually
store the (useless) inheritance link.

Anyway, an idea I had would be to reimplement inheritance based on joins,
since this is what the "pure relational" solution would be anyway. When I
create a table B that is based on A, all the system does is create the
table B as usual and store a note "I inherit from A". Any row you insert
into B also creates a row in A, and the row in B contains an oid pointer
to it. Thus a select on B performs a join on A.oid and B.row_in_A_pointer.
A select on A just returns all the rows in A, no extras needed. A delete
on B deletes the row in B and in A. A delete in A would cascade to B. Both
of this can be gotten for free with foreign keys. Adding a column to A
just adds the column to A, all other tables get the new column magically
and in the right order. Same with dropping columns, etc.

In short, this approach solves all inheritance problems at once and does
so without adding any extra kludges besides the "I inherited from" field,
which is static, plus the necessary transformations necessary in the
parser. The drawback is of course that a select from an inherited table
would always incur a join, perhaps some optimizing could be done in this
direction. But the bottom line is that the compatibility issue looms big.

-Peter

On Thu, 3 Feb 2000, Chris Bitmead wrote:

Hi,

I've been spending a lot of time lately with gdb and tracing the
back-end seeing if I can understand it enough to make some changes.
I'm starting to actually understand a lot of stuff, so in order
to have some possibility of having my changes accepted, I want to
discuss
them here first. Based on that, I'm going to hopefully make an attempt
at implementation. I have a patch for one of these changes already
if I get the go ahead.

THESE CHANGES DON'T AFFECT YOU IF YOU DON'T USE INHERITANCE.

Speak now about these changes or please, forever hold your peace. Of
course you can comment later if I screw up implementation.

The proposed changes are....

1) An imaginary field in every tuple that tells you the class it came
from.
This is useful when you select from table* and want to know which
relation the object actually came from. It wouldn't be stored on disk,
and like oid it wouldn't be displayed when you do SELECT *. The field
would be called classname. So you could have...
SELECT p.classname, p.name FROM person p;
person | Fred
student | Bill
employee | Jim
person | Chris

If you want to know the exact behaviour it is as if every table in the
database had done to it...
ALTER TABLE foo ADD COLUMN classname TEXT;
UPDATE foo SET classname='foo';

Of course this is not how it would be implemented. It is just
reference for how it will appear to work. BTW, this idea was also
in the original berkeley design notes.

2) Changing the sense of the default for getting inherited tuples.
Currently you only get inherited tuples if you specify "tablename*".
This would be changed so that you get all sub-class tuples too by
default unless you specify "ONLY tablename". There are several
rationale for this. Firstly this is what Illustra/Informix have
implemented. Secondly, I believe it is more logical from an OO
perspective as well as giving a more useful default. If a politician
IS a person and I say SELECT * from person, then logically I should
see all the politicians because they are people too (so they claim
:). Thirdly, there are a whole range of SQL statements that should
probably be disallowed without including sub-classes. e.g. an ALTER
TABLE ADD COLUMN that does not include sub-classes is almost certainly
undesirable. It seems ashame to have to resort to non-standard SQL
with the "*" syntax in this case when it is really your only
choice. Basicly, wanting ONLY a classname is a far more unusual
choice, and leaving off the "*" is a common error. Fourthly, it seems
out of character for the SQL language to have this single character
operator. The SQL style is to use wordy descriptions of the operators
meaning. "ONLY" fits well here because it describes its own meaning
perfectly whereas to the unitiated, "*" is harder to guess at. While
this change is an incompatibility I hope for those few people using
inheritance they can accept the need to move forward without
over-burden of backwards compatibility.

3) The ability to return different types of rows from a SELECT. This
is to allow implementation of ODBMS functionality where a query could
be required to instantiate objects of differing types with differing
attributes.

I would propose that that anytime you do a SELECT * from a base table
that you would get back the full rows from those sub tables. Since the
current PQ interface which doesn't support this notion would remain
unchanged this wouldn't affect current users.

It's probably also desirable to have a syntax for getting just the
columns of the base table when this is desired. Say perhaps SELECT %
from table. This would be a performance hack for users of libpq and a
functionality difference for users of psql.

The reason I think the "*" syntax should take on the new functionality
is because it would be more consistent with what the OQL (object query
language) standard specifies, and also because it seems the more
useful default. Also there is no compatibility reason not to do it.

In addition it would be legal to specify columns that only exist in
sub-classes. For example, if we had

CREATE TABLE person (name TEXT);
CREATE TABLE student (studentid TEXT, faculty TEXT) INHERITS (person);

it would be legal to say...

SELECT * FROM person;

NAME
----
Fred
Bill

NAME | STUDENTID | FACULTY
--------------------------
Jim | 23455 | Science
Chris| 45666 | Arts

SELECT *, studentid FROM person;

NAME
----
Fred
Bill

NAME | STUDENTID
----------------
Jim | 23455
Chris| 45666

SELECT *, studentid FROM ONLY person;

ERROR: person does not contain studentid.

SELECT % FROM person;

NAME
----
Fred
Bill
Jim
Chris

As you can see, it is desirable that psql be modified to be able to
print these differing tuple types. Presumably new column headings will
be printed when a tuple is differing to the previous one. Likely it
will be often desirable to do a
SELECT * FROM person p ORDER BY p.classname;
in order to have all the tuples of a particular type grouped together.

In addition some extenions will be done to the PQ interface to support
these differing return types. The current PQ interface will be left
unchanged and backwards compatible for retrieving rows of a single
type.

Also there should be an settable option that specifies that "*" should
also return the normally ignored columns of oid and classname. This is
so that OO programs that embed SQL into them also get back the oid and
classname which are required for the behind the scenes implementation
of an ODMG client. Something like...

SET SHOW_OID TRUE;
SHOW_CLASSNAME TRUE;

SELECT * FROM person;

OID CLASSNAME NAME
-------------------
2344 person Fred
3445 person Bill

OID CLASSNAME NAME | STUDENTID | FACULTY
-----------------------------------------
2355 student Jim | 23455 | Science
5655 student Chris| 45666 | Arts

************

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 3 11:28:34 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA87580
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 11:28:13 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Katt.DoCS.UU.SE (e99re41@Katt.DoCS.UU.SE [130.238.9.90])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA13136;
Thu, 3 Feb 2000 17:28:09 +0100 (MET)
Received: from localhost (e99re41@localhost) by Katt.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id RAA10994; Thu, 3 Feb 2000 17:28:08 +0100
X-Authentication-Warning: Katt.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 3 Feb 2000 17:28:07 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] SERIAL type isn't listed...?
In-Reply-To: <Pine.BSF.4.21.0002031153280.25537-100000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10002031727040.10941-100000@Katt.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Serial isn't a type. The parser transforms it to int4 plus some default
and a sequence. There is a TODO item in this direction, but I think no one
is quite sure how/why/whether to do it.

On Thu, 3 Feb 2000, The Hermit Hacker wrote:

Shouldn't this produce something? Was talking with Dave Page today about
the lack of a serial type in PgAdmin, and he mentioned that its not a listed
type?

template1=> SELECT typname FROM pg_type WHERE typrelid = 0 and typname='serial';
typname
---------
(0 rows)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

************

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 3 11:31:34 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA89165
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 11:31:07 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA31065
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 17:31:05 +0100
Date: Thu, 3 Feb 2000 17:31:04 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: array operators to the main tree
Message-ID: <Pine.LNX.3.96.1000203172557.29494A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

is a plan remove from the contrib tree 'array interator'
(in contrib/array) to the main tree as standard array operator(s)?

Karel

----------------------------------------------------------------------
Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/

Docs: http://docs.linux.cz (big docs archive)
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
-----------------------------------------------------------------------

From bouncefilter Thu Feb 3 11:24:34 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA86617
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 11:23:32 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA08638;
Thu, 3 Feb 2000 16:31:47 GMT
Sender: lockhart@hub.org
Message-ID: <3899AD73.1C31C1A6@alumni.caltech.edu>
Date: Thu, 03 Feb 2000 16:31:47 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] SERIAL type isn't listed...?
References: <Pine.BSF.4.21.0002031153280.25537-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Shouldn't this produce something? Was talking with Dave Page today about
the lack of a serial type in PgAdmin, and he mentioned that its not a
listed type?

Right. That's because the SERIAL type is a parser kludge rather than a
full-fledged type. At the moment, a column defined as SERIAL becomes,
in the parser backend, a defined sequence (CREATE SEQUENCE ...) and an
INT4 column with a constraint of DEFAULT ... which refers to the
sequence just created.

There are downsides to this: the implicit SEQUENCE is not cleaned up
if the column is destroyed; explicit reference to SERIAL is lost
during dump/restore; the implicit stuff just leads to confusion, etc
etc etc.

Perhaps eventually it should become a type on its own, directly
accessing the same structures as Vadim's "sequence" code. Or perhaps
it could be done using the SPI interface.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 3 11:36:42 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA92960
for <hackers@postgresql.org>; Thu, 3 Feb 2000 11:35:31 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA08653
for <hackers@postgresql.org>; Thu, 3 Feb 2000 16:43:51 GMT
Sender: lockhart@hub.org
Message-ID: <3899B047.A298F429@alumni.caltech.edu>
Date: Thu, 03 Feb 2000 16:43:51 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Parser/planner and column aliases
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

OK, on the road toward "outer join syntax"...

I'm implementing the "column alias" features of SQL92, as in

postgres=# select b, c from t2 ty (b, c);
b | c
---+---
1 | 1
1 | 2
2 | 2
(3 rows)

where the t2 columns are labeled "j, k" when created.

I'm running across the behavior that an explicit select as above
works, but if I try a wildcard expansion (select *...) instead of the
explicit column listing the planner decides it needs to do some wild
nested join stuff:

postgres=# select * from t2 ty (b, c);
b | c
---+---
1 | 1
1 | 2
2 | 2
1 | 1
1 | 2
2 | 2
1 | 1
1 | 2
2 | 2
(9 rows)

(Darn!)

Explain shows the following for the two cases:

postgres=# explain verbose select b, c from t2 ty (b, c);
NOTICE: QUERY DUMP:

{ SEQSCAN :cost 43 :rows 1000 :width 8 :state <> :qptargetlist ({
TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1
:resname b :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false }
:expr { VAR :varno 1 :varattno 1 :vartype 23 :vartypmod -1
:varlevelsup 0 :varnoold 1 :varoattno 1}} { TARGETENTRY :resdom {
RESDOM :resno 2 :restype 23 :restypmod -1 :resname c :reskey 0
:reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 1
:varattno 2 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1
:varoattno 2}}) :qpqual <> :lefttree <> :righttree <> :extprm ()
:locprm () :initplan <> :nprm 0 :scanrelid 1 }
NOTICE: QUERY PLAN:

Seq Scan on t2 ty (cost=43.00 rows=1000 width=8)

EXPLAIN
postgres=# explain verbose select * from t2 ty (b, c);
NOTICE: QUERY DUMP:

{ NESTLOOP :cost 43043 :rows 1000000 :width 12 :state <> :qptargetlist
({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1
:resname b :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false }
:expr { VAR :varno 65000 :varattno 1 :vartype 23 :vartypmod -1
:varlevelsup 0 :varnoold 0 :varoattno 1}} { TARGETENTRY :resdom {
RESDOM :resno 2 :restype 23 :restypmod -1 :resname c :reskey 0
:reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno
65000 :varattno 2 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold
0 :varoattno 2}}) :qpqual <> :lefttree { SEQSCAN :cost 43 :rows 1000
:width 4 :state <> :qptargetlist ({ TARGETENTRY :resdom { RESDOM
:resno 1 :restype 26 :restypmod -1 :resname <> :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno -2
:vartype 26 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno -2}})
:qpqual <> :lefttree <> :righttree <> :extprm () :locprm () :initplan
<> :nprm 0 :scanrelid 1 } :righttree { SEQSCAN :cost 43 :rows 1000
:width 8 :state <> :qptargetlist ({ TARGETENTRY :resdom { RESDOM
:resno 1 :restype 23 :restypmod -1 :resname <> :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 0 :varattno 1
:vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 0 :varoattno 1}} {
TARGETENTRY :resdom { RESDOM :resno 2 :restype 23 :restypmod -1
:resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false }
:expr { VAR :varno 0 :varattno 2 :vartype 23 :vartypmod -1
:varlevelsup 0 :varnoold 0 :varoattno 2}}) :qpqual <> :lefttree <>
:righttree <> :extprm () :locprm () :initplan <> :nprm 0 :scanrelid 0
} :extprm () :locprm () :initplan <> :nprm 0 }
NOTICE: QUERY PLAN:

Nested Loop (cost=43043.00 rows=1000000 width=12)
-> Seq Scan on t2 ty (cost=43.00 rows=1000 width=4)
-> Seq Scan (cost=43.00 rows=1000 width=8)

EXPLAIN

I *think* that the transformed parts of the query tree looks similar
for the two cases coming out of the parser, but clearly something is
different. Does anyone (Tom Lane??) know if the planner reaches back
into the untransformed nodes of the parse tree to get info? The resdom
nodes in the transformed target list look the same for the two cases,
but the planner is generating a bunch of new ones sometime later.

Hints would be appreciated, though I'm pretty sure I'll be able to
track it down even without ;)

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 3 11:52:34 2000
Received: from r149127-2815.dobiecenter.com ([209.217.149.127])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA97246;
Thu, 3 Feb 2000 11:52:21 -0500 (EST) (envelope-from taral@taral.net)
Received: from localhost (taral@localhost)
by r149127-2815.dobiecenter.com (8.9.3/8.9.3) with ESMTP id KAA06104;
Thu, 3 Feb 2000 10:50:30 -0600
X-Authentication-Warning: r149127-2815.dobiecenter.com: taral owned process
doing -bs
Date: Thu, 3 Feb 2000 10:50:30 -0600 (CST)
From: Taral <taral@taral.net>
X-Sender: taral@r149127-2815.dobiecenter.com
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Chris <chris@bitmead.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-Reply-To: <27991.949595171@sss.pgh.pa.us>
Message-ID:
<Pine.LNX.4.10.10002031049570.6100-100000@r149127-2815.dobiecenter.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 3 Feb 2000, Tom Lane wrote:

Maintaining an accurate count of descendants (or indexes for that
matter) would be expensive; in particular, it'd create severe
concurrency problems.

What about fixing these things on VACUUM then?

Taral

From bouncefilter Thu Feb 3 11:53:35 2000
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net
[194.217.242.41]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA97272;
Thu, 3 Feb 2000 11:52:27 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 12GPUX-000ELY-0C; Thu, 3 Feb 2000 16:52:25 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id RAA21235;
Thu, 3 Feb 2000 17:53:54 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <1GS4TVQD>; Thu, 3 Feb 2000 16:51:35 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C161@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: RE: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Date: Thu, 3 Feb 2000 16:51:33 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

As usual when replying from here, replies prefixed with PM:

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, February 03, 2000 4:26 PM
To: Chris
Cc: Bruce Momjian; pgsql-hackers@postgreSQL.org;
pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

PM: [snip]

For the purpose at hand, I think it would be OK to have a
"relhaschildren" field that is set true when the first child is created
and then never changed. If you have a table that once had children but
has none at the moment, then you pay the price of looking through
pg_inherits; but the case that we're really concerned about (a pure SQL,
no-inheritance table) would still win.

PM: Perhaps get vacuum to check for any children when it's set, and if
it finds none, it clears the flag?

From bouncefilter Thu Feb 3 11:55:34 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA98287;
Thu, 3 Feb 2000 11:55:19 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA28275;
Thu, 3 Feb 2000 11:52:58 -0500 (EST)
To: "Mark Hollomon" <mhh@nortelnetworks.com>
cc: chris@bitmead.com, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-reply-to: <38998548.C6C8606A@americasm01.nt.com>
References: <200002030402.XAA03844@candle.pha.pa.us>
<38998548.C6C8606A@americasm01.nt.com>
Comments: In-reply-to "Mark Hollomon" <mhh@nortelnetworks.com>
message dated "Thu, 03 Feb 2000 08:40:24 -0500"
Date: Thu, 03 Feb 2000 11:52:58 -0500
Message-ID: <28272.949596778@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Mark Hollomon" <mhh@nortelnetworks.com> writes:

How about a set variable?

SET GETSUBCLASSES = true

With the '*' and ONLY being explicit overrides to the setting
of the variable. The default would be 'false'.

I like that a lot. Clean, flexible, doesn't break any existing
applications.

Perhaps the business of whether to fetch extra columns from subclasses
could be done similarly. I am beginning to understand why Chris wants
to do that, and I see that it would support a particular style of
database programming very nicely. But I really fail to see why it's
necessary to change the default behavior to cater to those apps rather
than existing ones. Let the new apps use a variant syntax; don't
expect people to change existing code in order to avoid getting tripped
up by a new feature.

Note that "oh they won't see the extra columns if they're using an
old API" doesn't answer my objection. I'm concerned about the
performance hit from fetching those columns and transferring them to
the client, as well as the memory hit of storing them in query results
on the client side. We should *not* set things up in such a way that
that happens by default when the client didn't ask for it and isn't
even using an API that can support it. That's why it'd be a mistake
to redefine the existing query syntax to act this way.

The suggestion of "SELECT ** FROM ..." sounds pretty good to me,
actually. I don't really see any need for changing the behavior of
anything that looks like a standard SQL query. Applications that
need this feature will know that they need it and can issue a query
that specifically requests it.

I would not object to a configuration switch that would change the
default.

Mmm, I think that would probably not be such a hot idea. That would
introduce a pretty fundamental semantics incompatibility between
different installations, which would hurt script portability, complicate
debugging and support, yadda yadda. I think a SET variable is enough...

regards, tom lane

From bouncefilter Thu Feb 3 12:00:34 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA06899
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 12:00:26 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA28328;
Thu, 3 Feb 2000 12:00:22 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <20000203112434.B1509@quartz.newn.cam.ac.uk>
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Thu, 03 Feb 2000 11:24:34 +0000"
Date: Thu, 03 Feb 2000 12:00:21 -0500
Message-ID: <28325.949597221@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

Note that there is still plenty of swap space. The 128Mb number seems to be
more than a coincidence (how to prove?)

The majority of Unix systems have a process size limit kernel parameter,
which is normally set to less than the amount of available swap space
(you don't want a single process running wild to chew up all your swap
and make other stuff start failing for lack of swap...) Check your
kernel parameters.

It sounds to me like the backend has hit the size limit and is not
reacting gracefully to failure of malloc() to allocate more space.
It ought to exit with an elog(FATAL), probably. Sigh, time to take
another pass through the code to cast a suspicious eye on everyplace
that calls malloc() directly.

There's a separate question about *why* such a simple query is chewing
up so much memory. What query plan does EXPLAIN show for your test
query?

You said this was with current sources, right?

regards, tom lane

From bouncefilter Thu Feb 3 11:53:34 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA97299
for <hackers@postgreSQL.org>; Thu, 3 Feb 2000 11:52:34 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA08717
for <hackers@postgreSQL.org>; Thu, 3 Feb 2000 17:00:54 GMT
Sender: lockhart@hub.org
Message-ID: <3899B446.FC71BE97@alumni.caltech.edu>
Date: Thu, 03 Feb 2000 17:00:54 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Parser/planner and column aliases
References: <3899B047.A298F429@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm running across the behavior that an explicit select as above
works, but if I try a wildcard expansion (select *...) instead of the
explicit column listing the planner decides it needs to do some wild
nested join stuff:

Hmm. Wildcarding like this works:

postgres=# select ty.* from t2 ty (b, c);
b | c
---+---
1 | 1
1 | 2
2 | 2
(3 rows)

So my problems are maybe just within the parser. Will keep looking at
it...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 3 11:56:34 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA98516
for <hackers@postgreSQL.org>; Thu, 3 Feb 2000 11:55:54 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA08984
for <hackers@postgreSQL.org>; Thu, 3 Feb 2000 17:04:15 GMT
Sender: lockhart@hub.org
Message-ID: <3899B50F.4D926B5C@alumni.caltech.edu>
Date: Thu, 03 Feb 2000 17:04:15 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Parser/planner and column aliases
References: <3899B047.A298F429@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ha, got it:

postgres=# select * from t2 ty (b, c);
b | c
---+---
1 | 1
1 | 2
2 | 2
(3 rows)

so never mind...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 3 12:30:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA23174
for <hackers@postgreSQL.org>; Thu, 3 Feb 2000 12:30:34 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA28417;
Thu, 3 Feb 2000 12:30:23 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Parser/planner and column aliases
In-reply-to: <3899B047.A298F429@alumni.caltech.edu>
References: <3899B047.A298F429@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Thu, 03 Feb 2000 16:43:51 +0000"
Date: Thu, 03 Feb 2000 12:30:22 -0500
Message-ID: <28414.949599022@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

I'm running across the behavior that an explicit select as above
works, but if I try a wildcard expansion (select *...) instead of the
explicit column listing the planner decides it needs to do some wild
nested join stuff:

Nested Loop (cost=43043.00 rows=1000000 width=12)
-> Seq Scan on t2 ty (cost=43.00 rows=1000 width=4)
-> Seq Scan (cost=43.00 rows=1000 width=8)

Man, that's weird-looking. What happened to the table name in the
second Seq Scan line? I think you must be passing a broken rangetable
list.

My guess is that expansion of "*" is somehow failing to recognize that
it should be using the same RTE for all columns, and is causing an
extra bogus RTE to get added to the list. Put two RTEs in there and
you get a join...

regards, tom lane

BTW, this example reminds me once again that un-pretty-printed
EXPLAIN VERBOSE output is damn near unreadable. Would anyone object
if it got formatted the same as what goes to the postmaster log?
(It used to be unsafe to do that, but now that we can cope with
unlimited-length NOTICE messages I see no real good reason not to
format it more nicely.)

From bouncefilter Thu Feb 3 12:35:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA26925;
Thu, 3 Feb 2000 12:34:57 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA28440;
Thu, 3 Feb 2000 12:32:40 -0500 (EST)
To: Taral <taral@taral.net>
cc: Chris <chris@bitmead.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-reply-to:
<Pine.LNX.4.10.10002031049570.6100-100000@r149127-2815.dobiecenter.com>
References:
<Pine.LNX.4.10.10002031049570.6100-100000@r149127-2815.dobiecenter.com>
Comments: In-reply-to Taral <taral@taral.net>
message dated "Thu, 03 Feb 2000 10:50:30 -0600"
Date: Thu, 03 Feb 2000 12:32:39 -0500
Message-ID: <28437.949599159@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Taral <taral@taral.net> writes:

On Thu, 3 Feb 2000, Tom Lane wrote:

Maintaining an accurate count of descendants (or indexes for that
matter) would be expensive; in particular, it'd create severe
concurrency problems.

What about fixing these things on VACUUM then?

Could probably do that ... not sure if it's worth the trouble ...

regards, tom lane

From bouncefilter Thu Feb 3 12:46:35 2000
Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net
[137.118.22.15]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA28813
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 12:45:58 -0500 (EST)
(envelope-from mhh@nortelnetworks.com)
Received: from zrtpd004.us.nortel.com (actually zrtpd004)
by smtprtp.ntcom.nortel.net; Thu, 3 Feb 2000 12:45:28 -0500
Received: from zrtpd003.us.nortel.com ([47.140.224.137])
by zrtpd004.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id 1D5VBTGR; Thu, 3 Feb 2000 12:45:25 -0500
Received: from americasm01.nt.com (hrtpp28d.us.nortel.com [47.190.110.250])
by zrtpd003.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id DJLAH671; Thu, 3 Feb 2000 12:45:24 -0500
Message-ID: <3899BF26.61CACD40@americasm01.nt.com>
Date: Thu, 03 Feb 2000 12:47:18 -0500
From: "Mark Hollomon" <mhh@nortelnetworks.com>
Reply-To: "Mark Hollomon" <mhh@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <200002031237.HAA21220@candle.pha.pa.us>
<38997D1C.9F353FED@bitmead.com> <27991.949595171@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Chris <chris@bitmead.com> writes:

Why not change that to a relnumindexes as well? Easier to maintain and
more useful information.

Maintaining an accurate count of descendants (or indexes for that
matter) would be expensive; in particular, it'd create severe
concurrency problems. If one transaction is in the middle of creating
or dropping a child C of table P, then all other transactions would be
blocked from creating or dropping any other children of P until the C
transaction commits or aborts. They'd have to wait or they wouldn't
know what to set relnumchildren to.

For the purpose at hand, I think it would be OK to have a
"relhaschildren" field that is set true when the first child is created
and then never changed. If you have a table that once had children but
has none at the moment, then you pay the price of looking through
pg_inherits; but the case that we're really concerned about (a pure SQL,
no-inheritance table) would still win.

Not sure whether we can concurrently create/delete indexes on a rel,
but I'd be inclined to leave relhasindexes alone: again its main
function in life is to let you short-circuit looking for indexes on
a table that's never had and never will have any.

WOuld it be possible to consider this a 'statistic' and let
vacuum update it?

In other words, creating an index (or subtable) sets
relhasindex (relhaschild) but vacuum will set it to false
if it finds no children or indexes. or would this
run into concurrency problems as well?

--

Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008

From bouncefilter Thu Feb 3 13:02:35 2000
Received: from andie.ip23.net (andie.ip23.net [212.83.32.23])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA33838
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 13:01:51 -0500 (EST)
(envelope-from sevo@ip23.net)
Received: from imap1.ip23.net (imap1.ip23.net [212.83.32.35])
by andie.ip23.net (8.9.3/8.9.3) with ESMTP id TAA20120;
Thu, 3 Feb 2000 19:01:19 +0100 (CET)
Received: from ip23.net (spc.ip23.net [212.83.32.122])
by imap1.ip23.net (8.9.3/8.9.3) with ESMTP id TAA13924;
Thu, 3 Feb 2000 19:02:53 +0100 (CET)
Sender: sevo@imap1.ip23.net
Message-ID: <3899C39F.6F4AE35F@ip23.net>
Date: Thu, 03 Feb 2000 19:06:23 +0100
From: Sevo Stille <sevo@ip23.net>
Organization: IP23
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] SERIAL type isn't listed...?
References: <Pine.BSF.4.21.0002031153280.25537-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The Hermit Hacker wrote:

Shouldn't this produce something? Was talking with Dave Page today about
the lack of a serial type in PgAdmin, and he mentioned that its not a listed
type?

On 6.5, serial is not a type, but is promoted to "int4 DEFAULT nextval (
'"sequence_name_here"' ) NOT NULL", generating the associated sequence
in the process.

Sevo

From bouncefilter Thu Feb 3 13:36:35 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA43706;
Thu, 3 Feb 2000 13:36:15 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12GR70-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-interfaces@postgreSQL.org;
Thu, 3 Feb 2000 12:36:14 -0600 (CST)
Date: Thu, 3 Feb 2000 12:36:14 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: pgsql-hackers@postgresql.org
Cc: pgsql-interfaces@postgresql.org
Subject: coming ColdFusion support for PostgreSQL
Message-ID: <20000203123614.A23721@rice.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i

This is probably somewhat off topic, but all the people who need to
know about this read this list, so, if you'll forgive me:

Background:
The project I'm working on is using ColdFusion as it's middleware,
accessing a PostgreSQL backend. To date, we've had to run on NT, using
ODBC to the DB on a separate box. Allaire is in the process of releasing
a real live Linux version of their software (a native port, this time)
which I've been beta testing. I was pleased to discover that the unixODBC
driver worked (although I had to hand configure it into ColdFusion.)

Current news:
I just pulled the latest beta, and low and behold, it's checking to see
if PostgreSQL is installed, in order to install examples! It missed on my
box, since I run a Debian install, not the RedHat it's expecting, but
they're on the right track. Yep, the pgsql datasources are configurable
from within the CF adminstrator pages: excellent!

This _will_ lead to more commercial type users, I can guarantee.
Especially since the examples will be there. Lamar, we should make sure
that they detect the RPM install correctly, so that the examples just
work, right out of the box. I can image a lot of "throw together a demo,
using a DB backend, oh, here's PostgreSQL, I can use that" systems ending
up in production, since it'll just keep working.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Thu Feb 3 13:41:37 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA44469
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 13:40:41 -0500 (EST)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (max01-057.enterprise.net [194.72.195.57])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id SAA08105;
Thu, 3 Feb 2000 18:40:38 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id SAA22521;
Thu, 3 Feb 2000 18:41:29 GMT
Message-Id: <200002031841.SAA22521@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: prlw1@cam.ac.uk, pgsql-hackers@postgreSQL.org, olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Another nasty cache problem
In-Reply-To: Message from Tom Lane <tgl@sss.pgh.pa.us>
of "Thu, 03 Feb 2000 12:00:21 EST." <28325.949597221@sss.pgh.pa.us>
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<28325.949597221@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 03 Feb 2000 18:41:28 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>

Tom Lane wrote:

There's a separate question about *why* such a simple query is chewing
up so much memory. What query plan does EXPLAIN show for your test
query?

I can show a similar problem.

You said this was with current sources, right?

This is with current sources: I managed to kill the backend before
it had used up all swap. If left to run on 6.5.3 or CVS as of 2
weeks back it would kill the whole machine; I haven't let it get that
far today.

bray=# explain select * from pg_operator as a, pg_operator as b;
NOTICE: QUERY PLAN:

Nested Loop (cost=12604.88 rows=258064 width=162)
-> Seq Scan on pg_operator b (cost=24.76 rows=508 width=81)
-> Seq Scan on pg_operator a (cost=24.76 rows=508 width=81)

EXPLAIN

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"O come, let us worship and bow down; let us kneel
before the LORD our maker." Psalms 95:6

From bouncefilter Thu Feb 3 13:47:36 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA45750
for <pgsql-hackers@postgresql.org>; Thu, 3 Feb 2000 13:47:06 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12GRHi-0000wb-00; Thu, 3 Feb 2000 18:47:18 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12GRHX-0000bE-00; Thu, 3 Feb 2000 18:47:07 +0000
Date: Thu, 3 Feb 2000 18:47:07 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
Message-ID: <20000203184707.A2289@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<28325.949597221@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <28325.949597221@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Thu, Feb 03, 2000 at 12:00:21PM -0500

On Thu, Feb 03, 2000 at 12:00:21PM -0500, Tom Lane wrote:

The majority of Unix systems have a process size limit kernel parameter,
which is normally set to less than the amount of available swap space
(you don't want a single process running wild to chew up all your swap
and make other stuff start failing for lack of swap...) Check your
kernel parameters.

Probably to do with the shell limit:

memoryuse 125460 kbytes

There's a separate question about *why* such a simple query is chewing
up so much memory. What query plan does EXPLAIN show for your test
query?

test=# explain select * from test,test2 where test.i!=test2.i;
NOTICE: QUERY PLAN:

Nested Loop (cost=64104.80 rows=1559400 width=56)
-> Seq Scan on test2 (cost=24.80 rows=600 width=28)
-> Seq Scan on test (cost=106.80 rows=2600 width=28)

EXPLAIN

You said this was with current sources, right?

They're about 2 days old now. (Well, after your SI buffer overrun fixes)

Cheers,

Patrick

From bouncefilter Thu Feb 3 13:59:36 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA48484;
Thu, 3 Feb 2000 13:59:19 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id NAA04140;
Thu, 3 Feb 2000 13:59:14 -0500
Message-ID: <3899CFFB.7FA166E@wgcr.org>
Date: Thu, 03 Feb 2000 13:59:07 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
CC: pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
Subject: Re: [HACKERS] coming ColdFusion support for PostgreSQL
References: <20000203123614.A23721@rice.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ross J. Reedstrom" wrote:

This _will_ lead to more commercial type users, I can guarantee.
Especially since the examples will be there. Lamar, we should make sure
that they detect the RPM install correctly, so that the examples just
work, right out of the box. I can image a lot of "throw together a demo,
using a DB backend, oh, here's PostgreSQL, I can use that" systems ending
up in production, since it'll just keep working.

If you, as a beta tester for Cold Fusion, can let me know what they're
looking for, then I can oblige them with no problem. :-)

I am going to have to make it easier for third party software to detect
the RPM installation -- while things have settled down on where things
are, I have been considering moving some things around -- in particular,
the location of PGDATA is likely to move in 7.0 RPM's unless I hear a
cry otherwise. Currently, PGDATA is /var/lib/pgsql, I'm considering
changing that to /var/lib/pgsql/data, which is more in line with the
standard installation. This gives me the whole /var/lib/pgsql tree for
backups and other temp data that I need to move out of /usr/lib/pgsql.

I am open to suggestions -- environment variables perhaps?

I am going to look at Olivers Debian packages more closely so that I can
use the same envvar names for consistency, if I do use envvars.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Thu Feb 3 14:27:36 2000
Received: from cncware.whidbey.com (IDENT:root@cncware.whidbey.com
[208.25.171.37]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA56343;
Thu, 3 Feb 2000 14:26:54 -0500 (EST) (envelope-from ken@ori-ind.com)
Received: from ken (ren.cncware.com [192.168.61.201])
by cncware.whidbey.com (8.9.3/8.9.3) with SMTP id LAA15523;
Thu, 3 Feb 2000 11:27:58 -0800
Message-Id: <3.0.32.20000203112759.009ab4e0@ren.cncware.com>
X-Sender: ken_ori@ren.cncware.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 03 Feb 2000 11:28:02 -0800
To: Lamar Owen <lamar.owen@wgcr.org>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
From: "Ken J. Wright" <ken@ori-ind.com>
Subject: Re: [INTERFACES] Re: [HACKERS] coming ColdFusion support for
PostgreSQL
Cc: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

the location of PGDATA is likely to move in 7.0 RPM's unless I hear a
cry otherwise. Currently, PGDATA is /var/lib/pgsql, I'm considering
changing that to /var/lib/pgsql/data, which is more in line with the
standard installation. This gives me the whole /var/lib/pgsql tree for
backups and other temp data that I need to move out of /usr/lib/pgsql.

My two cents (sense?).

/var/lib follows Redhat dist install, correct?

I just installed 6.5.3 from the rpms for the first time and was thrown off
just a little, because I have always compiled & installed from the sources
to the default of /usr/local/pgsql.
This caused me to update some environment variables (PGxxx & PATH), but
that's about it. I actually prefer to have the source install and the rpm
install remain in separate places. But I would suggest /var/lib/pgsql/data
just to be inline with the source install. BTW, the rpm install was a
breeze. Much appreciated ;-)

Ken

From bouncefilter Thu Feb 3 16:15:39 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA87567;
Thu, 3 Feb 2000 16:15:24 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12GTaw-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Thu, 3 Feb 2000 15:15:18 -0600 (CST)
Date: Thu, 3 Feb 2000 15:15:18 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Lamar Owen <lamar.owen@wgcr.org>
Cc: pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
Subject: Re: [HACKERS] coming ColdFusion support for PostgreSQL
Message-ID: <20000203151518.B24398@rice.edu>
References: <20000203123614.A23721@rice.edu> <3899CFFB.7FA166E@wgcr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <3899CFFB.7FA166E@wgcr.org>;
from lamar.owen@wgcr.org on Thu, Feb 03, 2000 at 01:59:07PM -0500

On Thu, Feb 03, 2000 at 01:59:07PM -0500, Lamar Owen wrote:

"Ross J. Reedstrom" wrote:

This _will_ lead to more commercial type users, I can guarantee.
Especially since the examples will be there. Lamar, we should make sure
that they detect the RPM install correctly, so that the examples just
work, right out of the box. I can image a lot of "throw together a demo,
using a DB backend, oh, here's PostgreSQL, I can use that" systems ending
up in production, since it'll just keep working.

If you, as a beta tester for Cold Fusion, can let me know what they're
looking for, then I can oblige them with no problem. :-)

Hmm, looks like it would have found either a RPM or source install,
but mis-sets a variable for the source install. I'll send you the
appropriate snippet from the install script privately. The script wants
to find createdb and psql to run, and uses the location of postmaster
as a clue.

I am going to look at Olivers Debian packages more closely so that I can
use the same envvar names for consistency, if I do use envvars.

Good plan. Coordinating the different packages will make everyone's job
easier.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Thu Feb 3 22:07:41 2000
Received: from bender.toppoint.de (bender.toppoint.de [195.244.243.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA02445;
Thu, 3 Feb 2000 22:07:31 -0500 (EST)
(envelope-from marten@feki.toppoint.de)
Received: (from uucp@localhost)
by bender.toppoint.de (8.9.3/8.9.3) id EAA01920;
Fri, 4 Feb 2000 04:04:04 +0100 (MET)

Received: (from marten@localhost)

by feki.toppoint.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id WAA04803;
Thu, 3 Feb 2000 22:19:06 +0100
From: Marten Feldtmann <marten@feki.toppoint.de>
Message-Id: <200002032119.WAA04803@feki.toppoint.de>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
In-Reply-To: <26715.949561209@sss.pgh.pa.us> from Tom Lane at "Feb 3,
2000 02:00:09 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 3 Feb 2000 22:19:06 +0100 (CET)
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

I'll comment on the other issues later ... but I will say that I don't
think it's acceptable to add *any* overhead to standard-SQL queries
in order to support inheritance better. The vast majority of our users
want SQL performance and don't give a damn about inheritance. We have
to pay attention to that.

Well said !

Actually I'm a little bit uncertain what ORDBMS really improves ? After
writing a full mapper and wrapper for PostgreSQL and a Smalltalk dialect
I see really no usage for these additional inheritance features databases
like PostgreSQL offer.

Some points about this:

- all these additional features are very specific to PostgreSQL and
are not compatible with other databases. Writing an application
based on these features results in non-portable systems.

- Speed is still a very, very important feature for a database. A
single query, which uses about 5 seconds because the optimizer
is not very clever to use several indices to improove the
query execution is much more worse and can change the structure
of the whole application program.

- when creating automatic sql-queries through a mapper one can get
very complicated sql queries which tests the parser very hard and
the limits of PostgreSQL has been seen very quickly during
the development of the wrapper above.

What I'm missing from these new database are structural changes to
the query system: the possibility to execute complicated
concatenated queries on the server .. perhaps with different
parameters.

Just some ideas about all these nice features

Marten

From bouncefilter Thu Feb 3 16:41:37 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA95346
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 16:40:43 -0500 (EST)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (max01-054.enterprise.net [194.72.195.54])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id VAA21306;
Thu, 3 Feb 2000 21:40:41 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id VAA23959;
Thu, 3 Feb 2000 21:41:23 GMT
Message-Id: <200002032141.VAA23959@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [INTERFACES] coming ColdFusion support for PostgreSQL
In-reply-to: Message from "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
of Thu,
03 Feb 2000 12:36:14 CST. <20000203123614.A23721@rice.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 03 Feb 2000 21:41:23 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>

"Ross J. Reedstrom" wrote:

Background:
The project I'm working on is using ColdFusion as it's middleware,
accessing a PostgreSQL backend. To date, we've had to run on NT, using
ODBC to the DB on a separate box. Allaire is in the process of releasing
a real live Linux version of their software (a native port, this time)
which I've been beta testing. I was pleased to discover that the unixODBC
driver worked (although I had to hand configure it into ColdFusion.)

Current news:
I just pulled the latest beta, and low and behold, it's checking to see
if PostgreSQL is installed, in order to install examples! It missed on my
box, since I run a Debian install, not the RedHat it's expecting, but
they're on the right track. Yep, the pgsql datasources are configurable
from within the CF adminstrator pages: excellent!

If you can give me a contact, I would like to help them set it up as a
Debian package.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"O come, let us worship and bow down; let us kneel
before the LORD our maker." Psalms 95:6

From bouncefilter Thu Feb 3 17:31:39 2000
Received: from hu.tm.ee (ppp868.tele2.ee [212.107.37.168])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA07237;
Thu, 3 Feb 2000 17:31:28 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 79E3E3987; Fri, 4 Feb 2000 00:38:28 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389A0364.A1E6E766@tm.ee>
Date: Fri, 04 Feb 2000 00:38:28 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris <chris@bitmead.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<24649.949546519@sss.pgh.pa.us>
<3898F8DE.8159BFE7@nimrod.itg.telecom.com.au>
<389958FB.2E6927B5@tm.ee> <38995C95.38897035@bitmead.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris wrote:

Hannu Krosing wrote:

Maybe SELECT ** FROM BASE would be more flexible as it leaves the standard
SQL with its "standard" meaning ?

That was my first thought and it's definitely a possibility. My argument
against it is that SQL doesn't have a "standard meaning" in the case of
inheritance, and ** is an incompatibility with OQL.

I suspect we need both. Something like
SET GET_INHERITED_COLUMNS true; etc.

We will have to change the API sometime not too distant anyway, the current
api is unable to deal with anything that does not have a nice textual
representation (like an image or sound) in spite of all the talks about
easy extensibility - the extensibility is all in the backend, ther is no
easy way to get new datatypes in/out.

What about PQbinaryTuples() and friends?

They don't help you at all when doing inserts and are by definition in native
byte order on queries.

Something like [ PREPARE query; BIND arguments ; EXEC ] which knows about
binary
formats would be needed here.

One could use LOs except that the current ineffective implementation.

-------------
Hannu

From bouncefilter Thu Feb 3 17:46:38 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA12817;
Thu, 3 Feb 2000 17:46:30 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA22543; Fri, 4 Feb 2000 09:45:57 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0m.pg2;
Fri Feb 4 09:45:36 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA20034; Fri, 4 Feb 2000 09:45:34 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd04Lh0I; Fri Feb 4 09:45:20 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA06999;
Fri, 4 Feb 2000 09:45:15 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
JAA06947; Fri, 4 Feb 2000 09:44:35 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A04A4.BC343241@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 09:43:48 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Hollomon <mhh@nortelnetworks.com>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <200002030402.XAA03844@candle.pha.pa.us>
<38998548.C6C8606A@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Hollomon wrote:

[ discussion on changing the default to getting subclasses ]

I object.

Tell me why you object. Performance concerns? Compatibility?

A SET might be a good idea, but to decide whether and also a
default, it's good to know what the objections are.

How about a set variable?

SET GETSUBCLASSES = true

With the '*' and ONLY being explicit overrides to the setting
of the variable. The default would be 'false'. I would not
object to a configuration switch that would change the
default.
--

Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008

From bouncefilter Thu Feb 3 17:51:50 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA13707
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 17:51:06 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA27274; Fri, 4 Feb 2000 09:50:34 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0NPRH2;
Fri Feb 4 09:50:17 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA26581; Fri, 4 Feb 2000 09:50:16 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd05PGFS; Fri Feb 4 09:49:35 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA10982;
Fri, 4 Feb 2000 09:49:30 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
JAA07122; Fri, 4 Feb 2000 09:48:50 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A05A4.566417B4@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 09:48:04 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
CC: "'chris@bitmead.com'" <chris@bitmead.com>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] Proposed Changes to PostgreSQL
References:
<219F68D65015D011A8E000006F8590C603FDC238@sdexcsrv1.f000.d0188.sd.spardat.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Zeugswetter Andreas SB wrote:

Also there should be an settable option that specifies that "*" should
also return the normally ignored columns of oid and classname. This is
so that OO programs that embed SQL into them also get back the oid and
classname which are required for the behind the scenes implementation
of an ODMG client. Something like...

why don't they simply always
select oid, classname, * from ...
The reason I suggest this is, because implementing joins to return the
correct oid, classname seems very complex.

Because I envisage people using an ODBMS-ish interface and allowing
use of SQL queries. This infrastructure wouldn't work without oid and
classname. Forcing always to add oid, classname would be
repetitive and error prone.

From bouncefilter Thu Feb 3 17:57:39 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA14948;
Thu, 3 Feb 2000 17:57:01 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA03289; Fri, 4 Feb 2000 09:56:29 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdTN1lY_;
Fri Feb 4 09:56:03 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA05202; Fri, 4 Feb 2000 09:56:03 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdvU1ja_; Fri Feb 4 09:55:05 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA16394;
Fri, 4 Feb 2000 09:54:59 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
JAA07341; Fri, 4 Feb 2000 09:54:19 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A06ED.ECDB921A@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 09:53:33 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: chris@bitmead.com, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3.0.1.32.20000202210952.0086dd60@mail.pacifier.com>
<3.0.1.32.20000203073928.00fc2ec0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

No research is required. I simply want to implement the ODMG STANDARD
for ODBMS databases on PostgreSQL. There are no great design issues
here,
just a matter of nailing down the details so that everyone can live
with them.

Well...that's sorta like saying no research into procedural language
design is needed 'cause now we've got C++.

Whether or not the existing standard for ODBMS is the greatest thing
since sliced bread, I find it hard to believe that no research is
required or design issues raised by the fundamental problems of
database technology.

Maybe I'm wrong, though, maybe the problem's been solved.

No research is required _for what I want to do_. (or if there is
research required, I think I've just done it over the last 5 years :).
i.e. I don't want to explore some new style database, only implement
a current ODMG standard on postgresql. This style of database is
fairly well understood now for good or bad. Once the RDBMS and ODBMS
features exist in one database, maybe then research can be done
to move forward. That's my opinion anyway.

From bouncefilter Thu Feb 3 17:28:38 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA05770
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 17:28:07 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id
OAA28153
for pgsql-hackers@postgreSQL.org; Thu, 3 Feb 2000 14:54:01 -0800 (PST)
Date: Thu, 3 Feb 2000 14:54:01 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: pgsql-hackers@postgreSQL.org
Subject: how to deal with sparse/to-be populated tables
Message-ID: <20000203145401.O25520@fw.wintelcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i

We were having some trouble doing updates to our database,
a lot of our database sort of works like this:

dbfunc(data)
somedatatype *data;
{
somedatatype *existing_row;

existing_row = exists_in_table(data);

if (existing_row != NULL) {
update_table(existing_row, count = count + data->count)
} else
insert_into_table(data);

}

Is there anything built into postgresql to accomplish this without
the "double" work that goes on here?

something like:
update_row_but_insert_if_it_doesn't_exist(data,
update = 'count = count + data->count');

Meaning, if a row matching the 'new' data exists, update it, otherwise
store our new data as a new record?

It seems like the database has to do an awful amount of extra work
for our application because we haven't figured out how to do this
effeciently.

Any pointers?

thanks,
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]

From bouncefilter Thu Feb 3 17:52:02 2000
Received: from hu.tm.ee (ppp868.tele2.ee [212.107.37.168])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA13613;
Thu, 3 Feb 2000 17:50:43 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 204283988; Fri, 4 Feb 2000 00:57:45 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389A07E9.5FD0C77A@tm.ee>
Date: Fri, 04 Feb 2000 00:57:45 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
Cc: chris@bitmead.com, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3898DA32.793A98BA@nimrod.itg.telecom.com.au>
<3.0.1.32.20000202210952.0086dd60@mail.pacifier.com>
<3.0.1.32.20000203073928.00fc2ec0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

A good thought, but we still need one good front end that supports
all the features.

I wasn't think in terms of this being mutually exclusive with your
desires. Merely raising up the notion that the possibility exists
of creating a sandbox, so to speak, for people to play in, a tool
for the exploration of such concepts.

So we would be returning to roots. The original Postgres was exactly that -
a tool for the exploration of such concepts.

No, and I wasn't arguing that you shouldn't move forward, either. I
was just stating my personal opinion regarding the utility of simple
OO-ish features, that's all.

Yes, it needs quite much discussion/design befor going forth, lest we
will be in the next level of the current situation where some peoples
usage of the current limited inheritance is an obstacle to moving
forward to a more developed one.

One reason I raise the issue of possible multiple front-ends (or making
it easy for folks to make there own by making the parser->optimizer/backend
interface more general) is that this whole area would seem to be one
that begs for RESEARCH and experimentalism.

No research is required. I simply want to implement the ODMG STANDARD
for ODBMS databases on PostgreSQL. There are no great design issues
here, just a matter of nailing down the details so that everyone can
live with them.

Well...that's sorta like saying no research into procedural language
design is needed 'cause now we've got C++.

Whether or not the existing standard for ODBMS is the greatest thing
since sliced bread, I find it hard to believe that no research is
required or design issues raised by the fundamental problems of
database technology.

Maybe I'm wrong, though, maybe the problem's been solved.

My wife has forbidden me to buy any sliced bread, because the slices are of
wrong thickness.

Hardly the situation can be any better in OODB design.

The ODMG standard may be a good starting point for discussion, but one can't
run any programs on a standard - one needs a real db.
And IIRC the standard is only semi-public (not freely
available/distributable).

------------------
Hannu

From bouncefilter Thu Feb 3 17:53:38 2000
Received: from hu.tm.ee (ppp868.tele2.ee [212.107.37.168])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA14205
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 17:53:26 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 8F54B3989; Fri, 4 Feb 2000 01:00:28 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389A088C.F363684F@tm.ee>
Date: Fri, 04 Feb 2000 01:00:28 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] SERIAL type isn't listed...?
References: <Pine.BSF.4.21.0002031153280.25537-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The Hermit Hacker wrote:

Shouldn't this produce something? Was talking with Dave Page today about
the lack of a serial type in PgAdmin, and he mentioned that its not a listed
type?

Does PgAdmin support VIEWs ? They don't really exist either.

----------------------
Hannu

From bouncefilter Thu Feb 3 18:07:39 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA21064;
Thu, 3 Feb 2000 18:06:57 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA13443; Fri, 4 Feb 2000 10:06:25 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd9p6DE_;
Fri Feb 4 10:05:50 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA20126; Fri, 4 Feb 2000 10:05:48 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0TYn8m; Fri Feb 4 10:04:41 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA25738;
Fri, 4 Feb 2000 10:04:40 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA07760; Fri, 4 Feb 2000 10:04:00 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A0932.6D4C0CC@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 10:03:14 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Chris Bitmead <chris@bitmead.com>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
Subject: Re: [HACKERS] Proposed Changes to PostgreSQL
References: <Pine.GSO.4.02A.10002031705390.10941-100000@Katt.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Eisentraut wrote:

A lot of people use inheritance to create "consistent schemas", that is,
they empty create base tables, such as "address" which are inherited by
tables such as customer, vendor, office, etc.

This is a really bad idea. You could never have both a postal address
AND
a home address for example. I thought the original postgres supported
this
by having
CREATE TABLE ADDRESS (...)
CREATE TABLE PERSON(add ADDRESS).

Anyway, this is what Oracle and others can do these days, and this is
the right
thing.

Anyway, an idea I had would be to reimplement inheritance based on joins,
since this is what the "pure relational" solution would be anyway. When I
create a table B that is based on A, all the system does is create the
table B as usual and store a note "I inherit from A". Any row you insert
into B also creates a row in A, and the row in B contains an oid pointer
to it.

This is a really stu^H^H^H bad idea. I have hierarchies 5 levels deep
with
multiple inheritance, and I
don't want to do a 10 way join just to retrieve an object.

This is why RDBMS's performance sucks so incredibly badly on some
applications.
an ODBMS can perform 100x as fast in these cases just because of what
you
are proposing.

Thus a select on B performs a join on A.oid and B.row_in_A_pointer.
A select on A just returns all the rows in A, no extras needed. A delete
on B deletes the row in B and in A. A delete in A would cascade to B. Both
of this can be gotten for free with foreign keys. Adding a column to A
just adds the column to A, all other tables get the new column magically
and in the right order. Same with dropping columns, etc.

In short, this approach solves all inheritance problems at once and does
so without adding any extra kludges besides the "I inherited from" field,
which is static, plus the necessary transformations necessary in the
parser. The drawback is of course that a select from an inherited table
would always incur a join, perhaps some optimizing could be done in this
direction. But the bottom line is that the compatibility issue looms big.

-Peter

On Thu, 3 Feb 2000, Chris Bitmead wrote:

Hi,

I've been spending a lot of time lately with gdb and tracing the
back-end seeing if I can understand it enough to make some changes.
I'm starting to actually understand a lot of stuff, so in order
to have some possibility of having my changes accepted, I want to
discuss
them here first. Based on that, I'm going to hopefully make an attempt
at implementation. I have a patch for one of these changes already
if I get the go ahead.

THESE CHANGES DON'T AFFECT YOU IF YOU DON'T USE INHERITANCE.

Speak now about these changes or please, forever hold your peace. Of
course you can comment later if I screw up implementation.

The proposed changes are....

1) An imaginary field in every tuple that tells you the class it came
from.
This is useful when you select from table* and want to know which
relation the object actually came from. It wouldn't be stored on disk,
and like oid it wouldn't be displayed when you do SELECT *. The field
would be called classname. So you could have...
SELECT p.classname, p.name FROM person p;
person | Fred
student | Bill
employee | Jim
person | Chris

If you want to know the exact behaviour it is as if every table in the
database had done to it...
ALTER TABLE foo ADD COLUMN classname TEXT;
UPDATE foo SET classname='foo';

Of course this is not how it would be implemented. It is just
reference for how it will appear to work. BTW, this idea was also
in the original berkeley design notes.

2) Changing the sense of the default for getting inherited tuples.
Currently you only get inherited tuples if you specify "tablename*".
This would be changed so that you get all sub-class tuples too by
default unless you specify "ONLY tablename". There are several
rationale for this. Firstly this is what Illustra/Informix have
implemented. Secondly, I believe it is more logical from an OO
perspective as well as giving a more useful default. If a politician
IS a person and I say SELECT * from person, then logically I should
see all the politicians because they are people too (so they claim
:). Thirdly, there are a whole range of SQL statements that should
probably be disallowed without including sub-classes. e.g. an ALTER
TABLE ADD COLUMN that does not include sub-classes is almost certainly
undesirable. It seems ashame to have to resort to non-standard SQL
with the "*" syntax in this case when it is really your only
choice. Basicly, wanting ONLY a classname is a far more unusual
choice, and leaving off the "*" is a common error. Fourthly, it seems
out of character for the SQL language to have this single character
operator. The SQL style is to use wordy descriptions of the operators
meaning. "ONLY" fits well here because it describes its own meaning
perfectly whereas to the unitiated, "*" is harder to guess at. While
this change is an incompatibility I hope for those few people using
inheritance they can accept the need to move forward without
over-burden of backwards compatibility.

3) The ability to return different types of rows from a SELECT. This
is to allow implementation of ODBMS functionality where a query could
be required to instantiate objects of differing types with differing
attributes.

I would propose that that anytime you do a SELECT * from a base table
that you would get back the full rows from those sub tables. Since the
current PQ interface which doesn't support this notion would remain
unchanged this wouldn't affect current users.

It's probably also desirable to have a syntax for getting just the
columns of the base table when this is desired. Say perhaps SELECT %
from table. This would be a performance hack for users of libpq and a
functionality difference for users of psql.

The reason I think the "*" syntax should take on the new functionality
is because it would be more consistent with what the OQL (object query
language) standard specifies, and also because it seems the more
useful default. Also there is no compatibility reason not to do it.

In addition it would be legal to specify columns that only exist in
sub-classes. For example, if we had

CREATE TABLE person (name TEXT);
CREATE TABLE student (studentid TEXT, faculty TEXT) INHERITS (person);

it would be legal to say...

SELECT * FROM person;

NAME
----
Fred
Bill

NAME | STUDENTID | FACULTY
--------------------------
Jim | 23455 | Science
Chris| 45666 | Arts

SELECT *, studentid FROM person;

NAME
----
Fred
Bill

NAME | STUDENTID
----------------
Jim | 23455
Chris| 45666

SELECT *, studentid FROM ONLY person;

ERROR: person does not contain studentid.

SELECT % FROM person;

NAME
----
Fred
Bill
Jim
Chris

As you can see, it is desirable that psql be modified to be able to
print these differing tuple types. Presumably new column headings will
be printed when a tuple is differing to the previous one. Likely it
will be often desirable to do a
SELECT * FROM person p ORDER BY p.classname;
in order to have all the tuples of a particular type grouped together.

In addition some extenions will be done to the PQ interface to support
these differing return types. The current PQ interface will be left
unchanged and backwards compatible for retrieving rows of a single
type.

Also there should be an settable option that specifies that "*" should
also return the normally ignored columns of oid and classname. This is
so that OO programs that embed SQL into them also get back the oid and
classname which are required for the behind the scenes implementation
of an ODMG client. Something like...

SET SHOW_OID TRUE;
SHOW_CLASSNAME TRUE;

SELECT * FROM person;

OID CLASSNAME NAME
-------------------
2344 person Fred
3445 person Bill

OID CLASSNAME NAME | STUDENTID | FACULTY
-----------------------------------------
2355 student Jim | 23455 | Science
5655 student Chris| 45666 | Arts

************

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 3 18:31:39 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA39983;
Thu, 3 Feb 2000 18:30:49 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA07868; Fri, 4 Feb 2000 10:30:17 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdIuHAk_;
Fri Feb 4 10:30:00 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA26919; Fri, 4 Feb 2000 10:29:59 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0hkd0j; Fri Feb 4 10:29:05 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA19268;
Fri, 4 Feb 2000 10:29:04 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA08646; Fri, 4 Feb 2000 10:28:23 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A0EE9.3BA060D9@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 10:27:37 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Taral <taral@taral.net>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Chris <chris@bitmead.com>,
Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References:
<Pine.LNX.4.10.10002031049570.6100-100000@r149127-2815.dobiecenter.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Taral wrote:

On Thu, 3 Feb 2000, Tom Lane wrote:

Maintaining an accurate count of descendants (or indexes for that
matter) would be expensive; in particular, it'd create severe
concurrency problems.

What about fixing these things on VACUUM then?

It could produce wrong results to queries if the data is wrong.

From bouncefilter Thu Feb 3 18:59:39 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA48197;
Thu, 3 Feb 2000 18:59:20 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA04848; Fri, 4 Feb 2000 10:58:48 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdPIIUm_;
Fri Feb 4 10:58:19 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA06836; Fri, 4 Feb 2000 10:58:18 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdmXpfA_; Fri Feb 4 10:57:11 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA14274;
Fri, 4 Feb 2000 10:57:05 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA09672; Fri, 4 Feb 2000 10:56:25 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A157B.1EDF669@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 10:55:39 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Mark Hollomon <mhh@nortelnetworks.com>, chris@bitmead.com,
Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <200002030402.XAA03844@candle.pha.pa.us>
<38998548.C6C8606A@americasm01.nt.com>
<28272.949596778@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom, I agree with most of what you say. If we want to have ** be the
default
syntax for getting sub-columns I can live with that (for suggestion (3))

But for (2), I do feel very strongly that getting sub-tuples should be
the
"default default", and a SET GETSUBCLASSES=true should be the default
setting.

I've been using the postgres inheritance for a real system and I can
say with certainty that this is a massive source of errors. Not
wanting sub-class tuples seems rarely needed, and leaving off the "*" is
something that too often seems forgotten. I often can trawl through
code and realise that some query is missing the "*" but it hasn't been
discovered yet. In fact I find that almost all queries require the "*"
when you have a proper OO model, and not using "*" is usually laziness.

Also when adding a sub-class where there previously was none, one
usually has to trawl through the queries and add "*" to all of them
because as I said, there are almost never occasions where "*" is not
required in real life OO models.

So I understand the compatibility issue here, but I really feel strongly
that this should be changed now before there really are a lot of people
using it. Sure, have as many compatibility modes as you like, but I
think
this is a broken enough design that the default should be changed.
Apparently Illustra/Informix agreed.

Tom Lane wrote:

"Mark Hollomon" <mhh@nortelnetworks.com> writes:

How about a set variable?

SET GETSUBCLASSES = true

With the '*' and ONLY being explicit overrides to the setting
of the variable. The default would be 'false'.

I like that a lot. Clean, flexible, doesn't break any existing
applications.

Perhaps the business of whether to fetch extra columns from subclasses
could be done similarly. I am beginning to understand why Chris wants
to do that, and I see that it would support a particular style of
database programming very nicely. But I really fail to see why it's
necessary to change the default behavior to cater to those apps rather
than existing ones. Let the new apps use a variant syntax; don't
expect people to change existing code in order to avoid getting tripped
up by a new feature.

Note that "oh they won't see the extra columns if they're using an
old API" doesn't answer my objection. I'm concerned about the
performance hit from fetching those columns and transferring them to
the client, as well as the memory hit of storing them in query results
on the client side. We should *not* set things up in such a way that
that happens by default when the client didn't ask for it and isn't
even using an API that can support it. That's why it'd be a mistake
to redefine the existing query syntax to act this way.

The suggestion of "SELECT ** FROM ..." sounds pretty good to me,
actually. I don't really see any need for changing the behavior of
anything that looks like a standard SQL query. Applications that
need this feature will know that they need it and can issue a query
that specifically requests it.

I would not object to a configuration switch that would change the
default.

Mmm, I think that would probably not be such a hot idea. That would
introduce a pretty fundamental semantics incompatibility between
different installations, which would hurt script portability, complicate
debugging and support, yadda yadda. I think a SET variable is enough...

regards, tom lane

From bouncefilter Thu Feb 3 19:06:39 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA52878
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 19:05:48 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA11783; Fri, 4 Feb 2000 11:05:16 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd_47Uq_;
Fri Feb 4 11:04:42 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA16590; Fri, 4 Feb 2000 11:04:42 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdrDRc7_; Fri Feb 4 11:03:16 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA20141;
Fri, 4 Feb 2000 11:03:11 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
LAA09885; Fri, 4 Feb 2000 11:02:30 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A16E8.773105A@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 11:01:44 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Alfred Perlstein <bright@wintelcom.net>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables
References: <20000203145401.O25520@fw.wintelcom.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The thing is, in the relational model there isn't a standard
defininition of "already exists". For example, when you say
"already exists", I presume you mean that a record with the
same primary key already exists. But not all tables have
primary keys.

There are two things you can do...

1) remember if a record came out of the database in the first place
with a flag. This is what an object database would do.

2) If there is a unique index, instead of checking
whether the record exists with exists_in_table,
attempt to update the record. If you get a database error, THEN
do an insert. This is a common programming technique, often used
with unix system calls. Try one option and if error try the other.
Don't try to predict yourself whether an error will occur. This
will save 1 or two database calls depending on whether it exists
or not.

Alfred Perlstein wrote:

We were having some trouble doing updates to our database,
a lot of our database sort of works like this:

dbfunc(data)
somedatatype *data;
{
somedatatype *existing_row;

existing_row = exists_in_table(data);

if (existing_row != NULL) {
update_table(existing_row, count = count + data->count)
} else
insert_into_table(data);

}

Is there anything built into postgresql to accomplish this without
the "double" work that goes on here?

something like:
update_row_but_insert_if_it_doesn't_exist(data,
update = 'count = count + data->count');

Meaning, if a row matching the 'new' data exists, update it, otherwise
store our new data as a new record?

It seems like the database has to do an awful amount of extra work
for our application because we haven't figured out how to do this
effeciently.

Any pointers?

thanks,
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]

************

From bouncefilter Thu Feb 3 19:12:40 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA53996;
Thu, 3 Feb 2000 19:12:02 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA11742; Fri, 04 Feb 2000 09:10:53 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, <pgsql-hackers@postgreSQL.org>,
<pgsql-sql@postgreSQL.org>, "Chris" <chris@bitmead.com>
Subject: relhasindex(was RE: [HACKERS] Proposed Changes to PostgreSQL)
Date: Fri, 4 Feb 2000 09:16:46 +0900
Message-ID: <000201bf6ea5$1f8a9be0$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-To: <200002031237.HAA21220@candle.pha.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian

Bruce Momjian wrote:

Well I see that pg_class has columns like "relhasindex". If

we added a

"relhassubclass", the overhead should be unmeasureable.

Yes, but how do you keep that accurate? If I add indexes, then drop
them, does relhasindex go to false.

I don't know. Does it?

Let me add that to the TODO list.

Could you do that for relhassubclass?

If we made it relnumsubclasses and incremented/decremented on
CREATE/DROP, it seems easy in theory.

Yes, that would work. Seems hasindex has problems.

This posting may be off the point,sorry.

Isn't relhasindex a kind of item that we can live without it ?
I proposed to change the use of this item in [[HACKERS] Index
recreation in vacuum]. Though I have heard no clear objection,
I want to confirm again. My proposal is as follows.

1) DDL commands don't rely on relhasindex.
2) DML commands don't take indexes into account if
relhasindex is set to false.
3) REINDEX command and vacuum with REINDEX option
sets this flag to false at the beginning and sets it to true
when recreation of all indexes completed.

Comments ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Thu Feb 3 19:29:41 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA57352;
Thu, 3 Feb 2000 19:29:07 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12GWcB-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Thu, 3 Feb 2000 18:28:47 -0600 (CST)
Date: Thu, 3 Feb 2000 18:28:47 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: chris@bitmead.com
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Mark Hollomon <mhh@nortelnetworks.com>,
Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org,
pgsql-sql@postgresql.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Message-ID: <20000203182847.B25549@rice.edu>
References: <200002030402.XAA03844@candle.pha.pa.us>
<38998548.C6C8606A@americasm01.nt.com>
<28272.949596778@sss.pgh.pa.us>
<389A157B.1EDF669@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <389A157B.1EDF669@nimrod.itg.telecom.com.au>;
from chrisb@nimrod.itg.telstra.com.au on Fri, Feb 04, 2000 at
10:55:39AM +1100

On Fri, Feb 04, 2000 at 10:55:39AM +1100, Chris Bitmead wrote:
<snipped it all!>

Just wanted to chime in on this thread with the sugestion that Chris
clearly has been thinking about this a lot, and has some strong opinions
about the 'right way to do things'. How about an offical, postgresql.org
hosted, CVS branch for ORDBMS development? Let Chris and whomever is
interested take a crack at doing it however they want, and _prove_
that the performance is as good, or much better, and is compatible, etc.
Clearly, details of implementation can be discussed to death, until
Chris gets fed up and goes away: not good. So, what do the core
developers think? Sound feasable? As to problems of keeping in sync with
HEAD, etc., that'd be up to Chris and his crew. Does postgresql.org
have the extra 20-30 MB of disk?

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Thu Feb 3 19:29:40 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA57312
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 19:28:50 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id QAA02442;
Thu, 3 Feb 2000 16:54:37 -0800 (PST)
Date: Thu, 3 Feb 2000 16:54:37 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: chris@bitmead.com
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables
Message-ID: <20000203165437.T25520@fw.wintelcom.net>
References: <20000203145401.O25520@fw.wintelcom.net>
<389A16E8.773105A@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <389A16E8.773105A@nimrod.itg.telecom.com.au>;
from chrisb@nimrod.itg.telstra.com.au on Fri, Feb 04, 2000 at
11:01:44AM +1100

* Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> [000203 16:32] wrote:

The thing is, in the relational model there isn't a standard
defininition of "already exists". For example, when you say
"already exists", I presume you mean that a record with the
same primary key already exists. But not all tables have
primary keys.

I could adopt the tables to use this particular field as a primary
key, but see my questions about interpreting errors in responce
to suggestion #2.

There are two things you can do...

1) remember if a record came out of the database in the first place
with a flag. This is what an object database would do.

You mean implement an LRU cache outside the database, I've thought about
this and could actually do it, the thing that bugs me about it is
that i'm essentially trying to outsmart a 10+ year (guessing) old
piece of software with something that I'd have to hack up in a
matter of days.

2) If there is a unique index, instead of checking
whether the record exists with exists_in_table,
attempt to update the record. If you get a database error, THEN
do an insert. This is a common programming technique, often used
with unix system calls. Try one option and if error try the other.
Don't try to predict yourself whether an error will occur. This
will save 1 or two database calls depending on whether it exists
or not.

This is what I was thinking, the problem then becomes that I'm
not aware of way to determine the error with
some degree of accuracy so that I don't mistake:
insert error because of duplication
with:
insert error because of database connectivity (or other factors)

Is it possible to do that? I guess I could parse the error responce
from the backend, but maybe there's an easier/more-correct way?

-Alfred

Alfred Perlstein wrote:

We were having some trouble doing updates to our database,
a lot of our database sort of works like this:

dbfunc(data)
somedatatype *data;
{
somedatatype *existing_row;

existing_row = exists_in_table(data);

if (existing_row != NULL) {
update_table(existing_row, count = count + data->count)
} else
insert_into_table(data);

}

Is there anything built into postgresql to accomplish this without
the "double" work that goes on here?

something like:
update_row_but_insert_if_it_doesn't_exist(data,
update = 'count = count + data->count');

Meaning, if a row matching the 'new' data exists, update it, otherwise
store our new data as a new record?

It seems like the database has to do an awful amount of extra work
for our application because we haven't figured out how to do this
effeciently.

Any pointers?

thanks,
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]

************

--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]

From bouncefilter Thu Feb 3 20:13:41 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA71658
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 20:12:59 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA15317; Fri, 4 Feb 2000 12:12:23 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd9ZAS4_;
Fri Feb 4 12:11:54 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA21586; Fri, 4 Feb 2000 12:11:52 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdBxu26_; Fri Feb 4 12:11:36 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA22218;
Fri, 4 Feb 2000 12:11:35 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
MAA12494; Fri, 4 Feb 2000 12:10:54 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A26F0.E2742DF1@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 12:10:08 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Alfred Perlstein <bright@wintelcom.net>
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables
References: <20000203145401.O25520@fw.wintelcom.net>
<389A16E8.773105A@nimrod.itg.telecom.com.au>
<20000203165437.T25520@fw.wintelcom.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alfred Perlstein wrote:

There are two things you can do...

1) remember if a record came out of the database in the first place
with a flag. This is what an object database would do.

You mean implement an LRU cache outside the database, I've thought about
this and could actually do it, the thing that bugs me about it is
that i'm essentially trying to outsmart a 10+ year (guessing) old
piece of software with something that I'd have to hack up in a
matter of days.

Well, you only gave a small code snippet, I don't know how your app
works.

But often you retrieve tuples from the database and populate a C struct
or something...

struct Person {
char *firstname;
char *lastname;
};

What I'm saying is, if you are already doing something like this, then
just add one more boolean to say if it is a new or existing Person.
If you are not doing anything like this currently then it's not an
option.

Alternatively wait for my ODBMS features :-)

This is what I was thinking, the problem then becomes that I'm
not aware of way to determine the error with
some degree of accuracy so that I don't mistake:
insert error because of duplication
with:
insert error because of database connectivity (or other factors)

Is it possible to do that? I guess I could parse the error responce
from the backend, but maybe there's an easier/more-correct way?

Hmm. Doesn't PostgreSQL have a big list of error codes? I don't think
it does, I've never seen one. There should be a way to get error
codes without comparing strings. Should this be on the TODO?

From bouncefilter Thu Feb 3 21:35:41 2000
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA93832
for <pgsql-hackers@postgresql.org>; Thu, 3 Feb 2000 21:35:27 -0500 (EST)
(envelope-from mhh@mindspring.com)
Received: from mars (user-2inim47.dialup.mindspring.com [165.121.88.135])
by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id VAA07530
for <pgsql-hackers@postgresql.org>; Thu, 3 Feb 2000 21:35:25 -0500 (EST)
Received: from mhh by mars with local (Exim 3.12 #1 (Debian))
id 12GXtw-0003Ht-00
for <pgsql-hackers@postgresql.org>; Thu, 03 Feb 2000 20:51:12 -0500
Date: Thu, 3 Feb 2000 20:51:12 -0500
From: Mark Hollomon <mhh@mindspring.com>
To: pgsql-hackers@postgresql.org
Subject: docs and createlang patch for plperl
Message-ID: <20000203205112.A12565@mindspring.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99"
User-Agent: Mutt/1.0.1i

--5vNYLRcllDrimb99
Content-Type: text/plain; charset=us-ascii

Attached is a tarball that contains:

pl-perl.sgml - A start at documentation.
Thomas, I didn't know where this belongs. Does
it need to be integrated into the user manual
or should it stand on its own. If it needs
to stand alone, then all the docbook declarations
need to be added at the front.

createlang.sh.diff - a patch to add plperl
to the repertoire of createlang.sh
--
Mark Hollomon
mhh@mindspring.com

--5vNYLRcllDrimb99
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="plperl3.uu"

begin 644 plperl3.tar.gz
M'XL(``4OFC@``^U8;4\;21+FJ_D5M2B2@1B_$`?NB(..$&\.B1`6C%:G*(K:
M,VW/*.WIH;L'8YWVO]]3W>,7%I/DP^[F5IKZXNF>KO>GJGJ<J[U<&M6TXXG:
M^).HW6FW#[K=C7:[W3E\V5[]93KH[K_8:!^VNW@X..AV<+[3[1YL4/O/,FB5
M"NN$(=J8),E7SWWK_=^4>E$B<B<-I?'KK3R`8>MXDWHN=4H>7V))ET9',BZ,
M4'0NLG$AQK+7"N\W<3(71H!CD*26YM)B:2.3#J6E1$_):8KT)$^5;%":(>!*
MD<CB32JLI,OS%FMI0E*K%-6[EI'KX(%Z`Z_FPYTT=ZF<]EIAS6_*LW-^@E`]
MM333!>N;FM1)&A59Y%*=6:@EET`9GV33<I=F8W"KTB&:)FF4T$3,:"C9KIA9
MKG\YI]M"FA2."`@9L9`93:61!.9AD2J'<]#7RXV.B\AE8H*H:>O&1EHXM++;
M9):%CTL'!LDB""Q+YD;ZA$`E'$"H%F],>-6D?^NI1$@:X(ZD<0*F:F1.!%\3
M<2?AA<PH3JT8JN"+-C&DPM0TBXP45H*90V)E5"!8,U(0J4B/PN[,.CEIKK?X
M+*.QS*!/-?SA%=TN$8X$P@/WG4DC!^6\=(FVTK\%O_=%1(ZFJ4N\!)G=I49G
M$YFY9D`2K%0%8$0CP"8!6M2J'O:\IU(6HXZ-O"U2`TS.-QJ,KN5[9'/YCK9'
MVI"\QRH3"F(FR)"2=N<I7QW91!<J9EQDFOWQ/CHV<A$[/.,=B:'5JG"RB1#%
M4L8-G+ACM1#T5F:I4'MZM'?-8(XD">=$],7Z^%B7(M.YMC9%PFB/)G*BS0R&
M)@(M"CZ'BD&D$`EK26F=!U8WU0]L[[7*\EE32&^`V!C(]P$Z"Z6(Y:*<5QP_
ML;:8\-'27?D]&`>?U86!<\Y(R6$QVL<,(IY=OKN^.O6(*8M1M7)?CYZ#L:QC
MSZ-T)%Q`;6!J61.U<AQ7>6@5:^M(^X+DH*>37,THUE[-2'-G@"='..2=&!LQ
M4:GE%L",4;Q6#=YX\]Z++Y)!V+P\9[A@Y>6T'@MZJK[ATI33RW6'KB2`*"0N
M)I4.C4"2O73Z@!33>9H5]V7UH5FZP#ADE1S@F,H06-WTC8.!G%F&![>N.!V-
M4.18:7AN2CGVJ8!QG3^TI(2Z3Q'P'ND\]7EP(90X1K88QJBVR#$\0[?@2)5P
MF/=W7Z9?T1M"P=V71\.$X8@H^;[K6U08$E[GO$-[*P3%PHDAVA<+/QMQB-*%
MUH6M$@"`_$Z#QP*ZJ"M0*'/.,AN^30;K5W3,Y8C"Z0F\B+"<K:^OU?(*]7-C
MN6#*9OYD44D_I.;JE_@DQ\WZ*932Z57_9-"GP<F;\S[UWU^>?_A/OT_;F[4:
M(P,^W[L&%MY#H3B;B$77;^FLL'Y%.Z^>`N_9RH@8RU#Q3B,:?G8#9#ZEM,WR
MZ3EYF3L8A7@-R$!`C"K)I!]:8>KRR`S.V:/-VB.7:J5#/]]<G`[./EP$;:QL
MVQON#=ZAJ_[@YNKB.IA_<DWUS1I1#8.P,&@/GS^V/\$:_'8^X<WYR<6[FY-W
M?:J'.JF_@N(USEZ@*2T;FS#C@D=/Z*>YL"4,?7;FSJ39ZLSYU^>5D0(_)^DX
M<5PR\CZ7//6:=**L;F`K0@-GD)63];;0;`49GCK$PXAW^:;A:R)TW*7>!H/%
M]QWN$R@3+(V5:H1BF9_U32"&S7/9RWO/]NWMQT\\+?F';J<?/^U@XL%+/7*^
M#2,$C$9VO*R^)ZKV5^EMR'"?XVL;K%C&1J5?T$KT>NC6KOOG_=.![U^-E20O
M@=J8HVED](2X=O5,RO696V/9F\(U/!`%((>@^PQB4+J4IV.1<YR1S56+G[#T
M]XB$*=[4N4D[%'!G5]%8F\SH&4[0:[3/=.0`N04\L;UW_-_ZTM7Z;XS6^39[
M7?\-#'7Z7N2>!(^XZ95`%7Q1-!*-7V8\>#5:BTW">/@B9^4E`0M.@$7B(664
M2A4O;L4A1H'C3JA"!I[RL<1MI`WZ>ZZS.-R<O8@'$K[2[C,Y7:)E441E>%<J
MB5/H8<B(^AXX/<[0`PP]$<3'O;S7*C]=CC=_]"?97TK+.=P$9OC^\,?K^,;W
M?V?_</']?[C_`N<Z^R]?=JOO_[^"=G=WZ2$&M(IK@Z2@G^60Z`7MMX^ZG:/V
M/A[:[<V]O;V'QW]_=/]H_S`<W7U(O*;./[J-SC_WR6]@BM<@A<OW]1;N3(-(
M;?E-9Y`4&;_>&ES=7`_Z;RELAX]`PW]3N$A]YHO9YW)OZQ5?:VJ[._Z@C!)-
M6\].W[^].'G?/Z(BLT6>:\.?%(N;7OT9/W(3J6]M_K3@NGYT,O1"[LIC>ZOJ
M_LNI[DVH-X-A\AZ7T`XWJY*\-6CXD8]7</J`\+SW1SO]G&IA7.SPXP/)?`7=
M\KMK1#]_*)HE_*B`-N;1;,Q#Z\??MV/[HTNGHHHJJJBBBBJJJ****JJHHHHJ
0JJBBBO[OZ7]6U4>J`"@`````
`
end

--5vNYLRcllDrimb99--

From bouncefilter Thu Feb 3 22:45:42 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA11459;
Thu, 3 Feb 2000 22:45:29 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA17857; Fri, 4 Feb 2000 14:44:56 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd05bjDt;
Fri Feb 4 14:44:24 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA22767; Fri, 4 Feb 2000 14:44:23 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdhtbvS_; Fri Feb 4 14:43:33 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA19424;
Fri, 4 Feb 2000 14:43:27 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
OAA18233; Fri, 4 Feb 2000 14:42:46 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A4A88.C835B3D5@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 14:42:00 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Marten Feldtmann <marten@feki.toppoint.de>
CC: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <200002032119.WAA04803@feki.toppoint.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Marten Feldtmann wrote:

Actually I'm a little bit uncertain what ORDBMS really improves ? After
writing a full mapper and wrapper for PostgreSQL and a Smalltalk dialect
I see really no usage for these additional inheritance features databases
like PostgreSQL offer.

Some points about this:

- all these additional features are very specific to PostgreSQL and
are not compatible with other databases. Writing an application
based on these features results in non-portable systems.

Not true, because if the wrapper conforms to the ODMG standard, it will
be compatible with ObjectStore, Versant, the new Sun RDBS standard,
Gemstone, and many others.

- Speed is still a very, very important feature for a database. A
single query, which uses about 5 seconds because the optimizer
is not very clever to use several indices to improove the
query execution is much more worse and can change the structure
of the whole application program.

The biggest thing you can do for speed is to have less objects/tuples
in the database. Inheritance and the array feature of postgresql
can improve things here by orders of magnitude. The problem is that
these
two features are not viable to use at present. With an ODMG interface,
and TOAST to allow tuples of unlimited size this will then be a viable
feature. In some situations this will improve queries by 100x even
with the most brain-dead optimizer. ODBMS doesn't care a great deal
about wonderful optimizers because joins are less necessary.

- when creating automatic sql-queries through a mapper one can get
very complicated sql queries which tests the parser very hard and
the limits of PostgreSQL has been seen very quickly during
the development of the wrapper above.

Exactly, so stop mapping things and creating complicated joins. ODBMSes
do not do ANY joins to re-create objects. That's why mappers suck so
hard.

What I'm missing from these new database are structural changes to
the query system: the possibility to execute complicated
concatenated queries on the server .. perhaps with different
parameters.

What is a concatenated query?

I'm all in favour of more powerful queries, but that is not what this
proposal is about. This is about AVOIDING queries. Mappers and so forth
are great query generators because the database representation is
different from the in-memory object representation. This proposal
is all about making the in-memory object representation the same
as in the database.

If you still don't get it take an example..

class CarPart {
int volume;
}
class Wheel : CarPart {
int diameter;
}
class SteeringWheel : Wheel {
boolean horn;
}
class RoadWheel : Wheel {
int airpressure;
}
class Car {
List<CarPart> parts;
}

Now with an ODBMS, a Car with 4 wheels and a steering wheel we'll have 6
objects in the database - 1 Car, 4 RoadWheels and 1 SteeringWheel. With
a relational mapper, depending on how you map it you'll have 21 objects
- 5 CarPart objects, 5 wheel objects, 4 road wheel, 1 steering wheel, 1
car and 5 car_carpart relation entities. And when you join it all
together you'll have to join against 6 tables instead of 3.

From bouncefilter Thu Feb 3 23:17:42 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA19985
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 23:17:27 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA01254;
Thu, 3 Feb 2000 23:17:03 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: prlw1@cam.ac.uk, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <200002031841.SAA22521@linda.lfix.co.uk>
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<28325.949597221@sss.pgh.pa.us>
<200002031841.SAA22521@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Thu, 03 Feb 2000 18:41:28 +0000"
Date: Thu, 03 Feb 2000 23:17:03 -0500
Message-ID: <1251.949637823@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Oliver Elphick" <olly@lfix.co.uk> writes:

Tom Lane wrote:

There's a separate question about *why* such a simple query is chewing
up so much memory. What query plan does EXPLAIN show for your test
query?

I can show a similar problem.

bray=# explain select * from pg_operator as a, pg_operator as b;
NOTICE: QUERY PLAN:

Nested Loop (cost=12604.88 rows=258064 width=162)
-> Seq Scan on pg_operator b (cost=24.76 rows=508 width=81)
-> Seq Scan on pg_operator a (cost=24.76 rows=508 width=81)

OK, I sussed this one --- there's a (longstanding) memory leak in
catcache.c. When entering a system-table tuple into the cache,
it forgot to free the copy of the tuple that had been created in
transaction-local memory context. Cause enough cache entries to
be created within one transaction, and you'd start to notice the
leak. The above query exhibits the problem because it produces
about 250K tuples each with six regproc columns, and each regprocout
call does a cache lookup to convert regproc OID to procedure name.
Since you're cycling through 500-plus different procedure names,
and the cache only keeps ~ 300 entries, there's going to be a
fresh cache entry made every time :-(

With the fix I just committed, current sources execute the above query
in constant backend memory space. psql's space usage still goes to the
moon, of course, since it's trying to buffer the whole query result :-(
... but there's no way around that short of a major redesign of libpq's
API. When and if we switch over to CORBA, we really need to rethink
the client access API so that buffering the query result in the client-
side library is an option not a requirement.

I do not think this is the same problem that Patrick Welche is
complaining of, unfortunately.

regards, tom lane

From bouncefilter Thu Feb 3 23:32:42 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA24194
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 23:32:11 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA01276;
Thu, 3 Feb 2000 23:31:37 -0500 (EST)
To: chris@bitmead.com
cc: Alfred Perlstein <bright@wintelcom.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables
In-reply-to: <389A26F0.E2742DF1@nimrod.itg.telecom.com.au>
References: <20000203145401.O25520@fw.wintelcom.net>
<389A16E8.773105A@nimrod.itg.telecom.com.au>
<20000203165437.T25520@fw.wintelcom.net>
<389A26F0.E2742DF1@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Fri, 04 Feb 2000 12:10:08 +1100"
Date: Thu, 03 Feb 2000 23:31:37 -0500
Message-ID: <1273.949638697@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Hmm. Doesn't PostgreSQL have a big list of error codes? I don't think
it does, I've never seen one. There should be a way to get error
codes without comparing strings. Should this be on the TODO?

It doesn't, there should, and it already is ;-)

In the meantime, looking at the error message string is Alfred's
only option for distinguishing duplicate-record from other errors,
I'm afraid.

A partial answer to his performance concern is to use a rule
(or possibly a trigger) on the database side to reinterpret
"insert into table X" as "either insert or update in table Y,
depending on whether the key is already there". This wouldn't
buy anything in terms of database cycles, but it would avoid two
rounds of client-to-backend communication and query parsing.

I've never done that myself, but perhaps someone else on the
list has a working example.

regards, tom lane

From bouncefilter Thu Feb 3 23:42:44 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA27889
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 23:42:39 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA04068; Fri, 4 Feb 2000 15:42:07 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0HSFrm;
Fri Feb 4 15:41:56 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA01251; Fri, 4 Feb 2000 15:41:55 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdlX0AY_; Fri Feb 4 15:41:30 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA04171;
Fri, 4 Feb 2000 15:41:29 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
PAA20471; Fri, 4 Feb 2000 15:40:47 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A581F.47C0D822@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 15:39:59 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Oliver Elphick <olly@lfix.co.uk>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<28325.949597221@sss.pgh.pa.us>
<200002031841.SAA22521@linda.lfix.co.uk> <1251.949637823@
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

With the fix I just committed, current sources execute the above query
in constant backend memory space. psql's space usage still goes to the
moon, of course, since it's trying to buffer the whole query result :-(
... but there's no way around that short of a major redesign of libpq's
API. When and if we switch over to CORBA, we really need to rethink
the client access API so that buffering the query result in the client-
side library is an option not a requirement.

What about portals? Doesn't psql use portals?

From bouncefilter Thu Feb 3 23:57:43 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA29542
for <pgsql-hackers@postgreSQL.org>; Thu, 3 Feb 2000 23:56:46 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id NAA11921; Fri, 04 Feb 2000 13:55:11 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Alfred Perlstein" <bright@wintelcom.net>, <pgsql-hackers@postgreSQL.org>,
<chris@bitmead.com>
Subject: RE: [HACKERS] how to deal with sparse/to-be populated tables
Date: Fri, 4 Feb 2000 14:01:05 +0900
Message-ID: <000b01bf6ecc$d7733a60$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-To: <1273.949638697@sss.pgh.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Hmm. Doesn't PostgreSQL have a big list of error codes? I don't think
it does, I've never seen one. There should be a way to get error
codes without comparing strings. Should this be on the TODO?

It doesn't, there should, and it already is ;-)

Doens't the following TODO imply it ?

* Allow elog() to return error codes, not just messages

Many people have complained about it.
However,it seems not effective without a functionality of statement
level rollback. AFAIK,Vadim has planed it together with savepoint
functionality.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Fri Feb 4 00:19:43 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA36235
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 00:19:27 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA02987; Fri, 4 Feb 2000 16:18:44 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdae6kD_;
Fri Feb 4 16:18:34 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA14203; Fri, 4 Feb 2000 16:18:33 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd7e6Qs_; Fri Feb 4 16:18:11 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA02127;
Fri, 4 Feb 2000 16:18:10 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA21849; Fri, 4 Feb 2000 16:17:29 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A60BB.D8A4484B@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 16:16:43 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
CC: chris@bitmead.com
Subject: Time travel
References: <000b01bf6ecc$d7733a60$2801007e@tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

From time to time the old Time Travel postgres functionality is

mentioned.
When it is mentioned, somebody usually says "Yeah well you can implement
it
just as well with triggers therefore it's redundant" and the doco says
"New
features such as triggers allow one to mimic the behavior of time travel
when
desired, without incurring the overhead when it is not needed (for most
users,
this is most of the time).

This seems to fail to take into account the original design which was
to take advantage of a different style of storage manager, that doesn't
have an undo log. Unless I'm missing something, postgres is indeed still
"incurring the overhead" of time travel, but losing the feature.

In fact, if you have fsync turned on for full safety, the postgres
performance is going to be bad compared to a regular design
storage manager.

On the other hand the postgres storage manager had the advantage of time
travel because it does not update in place.

Now in the documentation it mentioned removing time travel because
"performance impact, storage size, and a pg_time file which
grows toward infinite size in a short period of time.".

Now since I believe the postgres storage manager does not replace
records in place when updated, I can't see how it is different to
having the time travel feature with vacuum configured to remove
all old records immediately. I don't know what the pg_time file
is.

Have I missed something about why taking out time travel has
improved performance, as opposed to simply making immediate
vacuum the default? Clearly the performance of triggers as an
alternative is going to suck very badly, since the postgres
storage manager was built specially from the ground up to
support time travel with its non-update semantics, and it
still has these characteristics.

From bouncefilter Fri Feb 4 11:33:50 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA12739;
Fri, 4 Feb 2000 11:33:48 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA11974;
Fri, 4 Feb 2000 08:31:39 -0800 (PST)
Message-Id: <3.0.1.32.20000203211710.00fd09c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 03 Feb 2000 21:17:10 -0800
To: chris@bitmead.com, Marten Feldtmann <marten@feki.toppoint.de>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Cc: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
In-Reply-To: <389A4A88.C835B3D5@nimrod.itg.telecom.com.au>
References: <200002032119.WAA04803@feki.toppoint.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:42 PM 2/4/00 +1100, Chris Bitmead wrote:

Not true, because if the wrapper conforms to the ODMG standard, it will
be compatible with ObjectStore, Versant, the new Sun RDBS standard,
Gemstone, and many others.

Without prejudice, I'd be interested in some order-of-magnitude
market share for these technologies vs., say, Oracle.

The biggest thing you can do for speed is to have less objects/tuples
in the database. Inheritance and the array feature of postgresql
can improve things here by orders of magnitude.

There's no doubt of this, for applications that can make use
of the paradigms.

The problem is that
these
two features are not viable to use at present. With an ODMG interface,
and TOAST to allow tuples of unlimited size this will then be a viable
feature. In some situations this will improve queries by 100x even
with the most brain-dead optimizer. ODBMS doesn't care a great deal
about wonderful optimizers because joins are less necessary.

And this last statement I really have to wonder about. For restricted
application spaces, yeah, no doubt. But in general, no way.

Exactly, so stop mapping things and creating complicated joins. ODBMSes
do not do ANY joins to re-create objects. That's why mappers suck so
hard.

If they don't do joins, then presumably they map many-to-one relations
by copying data into each of the "many" table rows. TANSTAAFL, no?

Though this strategy is a very viable one in today's big-memory, big-disk
environment. It's not clear to me that a extremely smart RDBMS system
couldn't decide to add redundancy itself and gain much of the efficiency,
but, heck, that's just my weak, uncreative compiler-writer mind at work
again.

(and clearly, of course, PG isn't on any threshold of doing it, I'm
thinking in theoretical space here).

Now with an ODBMS, a Car with 4 wheels and a steering wheel we'll have 6
objects in the database - 1 Car, 4 RoadWheels and 1 SteeringWheel. With
a relational mapper, depending on how you map it you'll have 21 objects
- 5 CarPart objects, 5 wheel objects, 4 road wheel, 1 steering wheel, 1
car and 5 car_carpart relation entities. And when you join it all
together you'll have to join against 6 tables instead of 3.

Not really. You'd probably denormalize and not worry about it, in
practice.

Would the result be as beautiful? I don't know - do most car designers
think that SteeringMechanism and PavementInterface are the same? It's
true for a variety of reasons in today's cars that aren't actually
related, and high-end race cars are exploring joystick control.

So one could claim that your hierarchy is merely limiting creative
expression...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Fri Feb 4 00:26:43 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA37141
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 00:26:11 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA01429;
Fri, 4 Feb 2000 00:26:00 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <20000203112434.B1509@quartz.newn.cam.ac.uk>
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Thu, 03 Feb 2000 11:24:34 +0000"
Date: Fri, 04 Feb 2000 00:26:00 -0500
Message-ID: <1426.949641960@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
1547 prlw1 50 0 128M 516K run 1:28 59.28% 59.28% psql
1552 postgres 50 0 1920K 632K run 1:37 24.32% 24.32% postgres

Sigh, I shoulda read this closely enough to notice that you were
complaining of psql memory overrun, not backend memory overrun :-(

The major problem here is that libpq's API is designed on the assumption
that libpq will buffer the whole query result in application memory
before letting the app see any of it. I see no way around that without
a fundamental redesign of the API. Which will happen someday, but not
today.

The minor problem is that libpq doesn't react very gracefully to running
out of memory. It detects it OK, but then aborts query processing,
which means it gets out of step with the backend. It needs to be fixed
so that it continues to absorb tuples (but drops them on the floor)
until the backend is done. I've known of this problem for some time,
but have had many higher-priority problems to worry about. Perhaps
someone else would like to take it on...

regards, tom lane

From bouncefilter Fri Feb 4 00:09:43 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA35092
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 00:09:12 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id VAA18788;
Thu, 3 Feb 2000 21:32:33 -0800 (PST)
Date: Thu, 3 Feb 2000 21:32:33 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables
Message-ID: <20000203213232.Y25520@fw.wintelcom.net>
References: <20000203145401.O25520@fw.wintelcom.net>
<389A16E8.773105A@nimrod.itg.telecom.com.au>
<20000203165437.T25520@fw.wintelcom.net>
<389A26F0.E2742DF1@nimrod.itg.telecom.com.au>
<1273.949638697@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <1273.949638697@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Thu, Feb 03, 2000 at 11:31:37PM -0500

* Tom Lane <tgl@sss.pgh.pa.us> [000203 20:58] wrote:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Hmm. Doesn't PostgreSQL have a big list of error codes? I don't think
it does, I've never seen one. There should be a way to get error
codes without comparing strings. Should this be on the TODO?

It doesn't, there should, and it already is ;-)

In the meantime, looking at the error message string is Alfred's
only option for distinguishing duplicate-record from other errors,
I'm afraid.

A partial answer to his performance concern is to use a rule
(or possibly a trigger) on the database side to reinterpret
"insert into table X" as "either insert or update in table Y,
depending on whether the key is already there". This wouldn't
buy anything in terms of database cycles, but it would avoid two
rounds of client-to-backend communication and query parsing.

I've never done that myself, but perhaps someone else on the
list has a working example.

Actually we have some plpgsql code lying around that does this.
The issue isn't ease of implementation, but actually the speed of
the implementation. Even parsing the error return isn't as optimal
as a insert_new|update_existing_with_args single op would be.

One of the more fustrating aspects is that we could use the field
that we merge rows on as a primary index, this would allow us to
do a insert or update on failed insert...

however... if we fail to locate the row on the initial query (to
see if it exists) we pay a large penalty because the insert must
be validated to be unique. This effectively doubles the search.
This is also a problem if we do "update or insert on fail", basically
a double scan is required.

(yes, I just thought about only indexing, and trying the update
first and only on failure doing an insert, however we really can't
determine if the initial update failed because no record matched(ok),
or possible some other error (ouch))

That's why we can't use this feild as a primary index, even though
it is supposed to be unqiue.

Basically the database seems to force a _double_ lookup, the only
way I see around this is to then switch over to a bulk copy getting
around the double lookup. However, this will only work for our
special case where there is only a single reader/writer updating
the table at any time, otherwise we need special locking to avoid
races.

Even if this isn't a TODO item, if there's a wish list out there
it'd be nice to see this request for feature listed.

I think once the dust settles over here and the need to scale goes
from very scalable to insanely scalable I'm going to have an even
greater interest in learning postgresql internals. :)

thanks,
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]

From bouncefilter Fri Feb 4 00:18:43 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA36105
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 00:17:52 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id VAA19063;
Thu, 3 Feb 2000 21:41:16 -0800 (PST)
Date: Thu, 3 Feb 2000 21:41:16 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
chris@bitmead.com
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables
Message-ID: <20000203214116.A25520@fw.wintelcom.net>
References: <1273.949638697@sss.pgh.pa.us>
<000b01bf6ecc$d7733a60$2801007e@tpf.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <000b01bf6ecc$d7733a60$2801007e@tpf.co.jp>;
from Inoue@tpf.co.jp on Fri, Feb 04, 2000 at 02:01:05PM +0900

* Hiroshi Inoue <Inoue@tpf.co.jp> [000203 21:34] wrote:

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Hmm. Doesn't PostgreSQL have a big list of error codes? I don't think
it does, I've never seen one. There should be a way to get error
codes without comparing strings. Should this be on the TODO?

It doesn't, there should, and it already is ;-)

Doens't the following TODO imply it ?

* Allow elog() to return error codes, not just messages

Many people have complained about it.
However,it seems not effective without a functionality of statement
level rollback. AFAIK,Vadim has planed it together with savepoint
functionality.

It would help, but it wouldn't be avoid the double searches I seem
to need to do to maintain a unique index.

--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]

From bouncefilter Fri Feb 4 00:43:43 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA42756
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 00:43:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA01543;
Fri, 4 Feb 2000 00:42:59 -0500 (EST)
To: chris@bitmead.com
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <389A581F.47C0D822@nimrod.itg.telecom.com.au>
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<28325.949597221@sss.pgh.pa.us>
<200002031841.SAA22521@linda.lfix.co.uk> <1251.949637823@
<389A581F.47C0D822@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Fri, 04 Feb 2000 15:39:59 +1100"
Date: Fri, 04 Feb 2000 00:42:58 -0500
Message-ID: <1540.949642978@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

What about portals? Doesn't psql use portals?

No ... portals are a backend concept ...

regards, tom lane

From bouncefilter Fri Feb 4 01:01:44 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA45922
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 01:01:06 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA03213; Fri, 4 Feb 2000 17:00:25 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpds94Yf_;
Fri Feb 4 17:00:12 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA28505; Fri, 4 Feb 2000 17:00:12 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd02kzwz; Fri Feb 4 16:59:35 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA01164;
Fri, 4 Feb 2000 16:59:25 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA23264; Fri, 4 Feb 2000 16:58:43 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389A6A62.7A6BD39C@nimrod.itg.telecom.com.au>
Date: Fri, 04 Feb 2000 16:57:54 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<28325.949597221@sss.pgh.pa.us>
<200002031841.SAA22521@linda.lfix.co.uk> <1251.949637823@
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

What about portals? Doesn't psql use portals?

No ... portals are a backend concept ...

Since when?

According to the old doco you do...

select portal XX * from table_name where ...;

fetch 20 into XX.

If the PQexec() is called with "fetch 20" at a time
wouldn't this mean that you wouldn't exhaust front-end
memory with a big query?

From bouncefilter Fri Feb 4 01:07:43 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA49007
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 01:07:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA01709;
Fri, 4 Feb 2000 01:06:53 -0500 (EST)
To: Alfred Perlstein <bright@wintelcom.net>
cc: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables
In-reply-to: <20000203213232.Y25520@fw.wintelcom.net>
References: <20000203145401.O25520@fw.wintelcom.net>
<389A16E8.773105A@nimrod.itg.telecom.com.au>
<20000203165437.T25520@fw.wintelcom.net>
<389A26F0.E2742DF1@nimrod.itg.telecom.com.au>
<1273.949638697@sss.pgh.pa.us>
<20000203213232.Y25520@fw.wintelcom.net>
Comments: In-reply-to Alfred Perlstein <bright@wintelcom.net>
message dated "Thu, 03 Feb 2000 21:32:33 -0800"
Date: Fri, 04 Feb 2000 01:06:53 -0500
Message-ID: <1706.949644413@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Alfred Perlstein <bright@wintelcom.net> writes:

(yes, I just thought about only indexing, and trying the update
first and only on failure doing an insert, however we really can't
determine if the initial update failed because no record matched(ok),
or possible some other error (ouch))

Uh ... why not? "UPDATE 0" is a perfectly recognizable result
signature, it seems like. (I forget just how that looks at the
libpq API level, but if psql can see it so can you.)

Alternatively, if you think the insert is more likely to be the
right thing, try it first and look to see if you get a "can't
insert duplicate key into unique index" error.

You're right that SQL provides no combination statement that would
allow these sequences to be done with only one index probe. But
FWIW, I'd think that the amount of wasted I/O would be pretty minimal;
the relevant index pages should still be in the buffer cache when
the second query gets to the backend.

regards, tom lane

From bouncefilter Fri Feb 4 01:34:44 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA56030
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 01:34:12 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA01815;
Fri, 4 Feb 2000 01:33:45 -0500 (EST)
To: chris@bitmead.com
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <389A6A62.7A6BD39C@nimrod.itg.telecom.com.au>
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<28325.949597221@sss.pgh.pa.us>
<200002031841.SAA22521@linda.lfix.co.uk> <1251.949637823@
<389A6A62.7A6BD39C@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Fri, 04 Feb 2000 16:57:54 +1100"
Date: Fri, 04 Feb 2000 01:33:45 -0500
Message-ID: <1812.949646025@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

No ... portals are a backend concept ...

Since when?

According to the old doco you do...

select portal XX * from table_name where ...;

fetch 20 into XX.

That still works if you spell it in the SQL-approved way,
DECLARE CURSOR followed by FETCH.

If the PQexec() is called with "fetch 20" at a time
wouldn't this mean that you wouldn't exhaust front-end
memory with a big query?

Sure, and that's how you work around the problem. Nonetheless
this requires the user to structure his queries to avoid sucking
up a lot of data in a single query. If the user doesn't have any
particular reason to need random access into a query result, it'd
be nicer to be able to read the result in a streaming fashion
without buffering it anywhere *or* making arbitrary divisions in it.

In any case, psql doesn't (and IMHO shouldn't) convert a SELECT
into a series of FETCHes for you.

regards, tom lane

From bouncefilter Fri Feb 4 02:42:44 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA72487
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 02:42:21 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA10244;
Fri, 4 Feb 2000 07:47:28 GMT
Sender: lockhart@hub.org
Message-ID: <389A840F.9FA3A249@alumni.caltech.edu>
Date: Fri, 04 Feb 2000 07:47:27 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Hollomon <mhh@mindspring.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] docs and createlang patch for plperl
References: <20000203205112.A12565@mindspring.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

pl-perl.sgml - A start at documentation.
Thomas, I didn't know where this belongs. Does
it need to be integrated into the user manual
or should it stand on its own. If it needs
to stand alone, then all the docbook declarations
need to be added at the front.

Great. I haven't had a chance to look, but I would assume that it
should be in the User's Guide or more likely in the Programmer's
Guide.

Thanks for the docs!! I'll add them in this weekend, if not before.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Fri Feb 4 06:29:47 2000
Received: from feivel.fam-meskes.de (postfix@p3E9B985A.dip0.t-ipconnect.de
[62.155.152.90]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA29940
for <pgsql-hackers@postgresql.org>; Fri, 4 Feb 2000 06:29:40 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id CE0C32BB9E; Fri, 4 Feb 2000 09:55:25 +0100 (CET)
Date: Fri, 4 Feb 2000 09:55:25 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Two backends at the same time
Message-ID: <20000204095525.A799@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
Sender: michael@fam-meskes.de

What happens if I run two backends on different ports at the same time on
the same database? Is there any kind of locking done?

No, one backend won't do since one software want US style dates and the
other wants German style dates. There should be no concurrent access but who
knows when I will type the wrong port.

michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Fri Feb 4 09:40:50 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA79861
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 09:40:34 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id JAA06482;
Fri, 4 Feb 2000 09:38:50 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <389A9DFB.BFAC279B@mascari.com>
Date: Fri, 04 Feb 2000 04:38:03 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Timothy Dyck <Timothy_Dyck@zd.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PC Week Labs benchmark results
References: <8525687B.003BD14A.00@mailer.zd.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Timothy Dyck wrote:

Hi everybody, I'm done my tests of PostgreSQL and Interbase.

I concentrated on two tests, an OLTP Single Read Test, where we read a
single row out of a 200K row indexed table, and the OLTP Read Mix Test,
which is a mix of about 30 queries, about half single table selects and
the other half joins of various complexity (up to four way). For both of
these tests, InterBase was about 2x to 2.5x as fast as PostgreSQL. In
multiuser tests (up to 100 users), the situation was reversed, with
PostgreSQL close to 3 times faster at peak throughput (which was at 50
concurrent users). The reason why is that InterBase on Linux has a
process-per-connection architecture without a shared cache. As such, I had
to really limit cache sizes to allow 100 users to connect, and that really
hurt InterBase's performance.

I ran both PostgreSQL and InterBase with syncs turned off, and used a
cache of 65536 4KB pages and 4000K of sort buffer.

Here's a list of things about PostgreSQL I had problems with:

1. "Null" is not accepted keyword on "create table" ("not null" is ok)

There was some discussion of this in the lists in the past:

http://www.postgresql.org/mhonarc/pgsql-hackers/1998-12/msg00546.html

: : : Now that we have the syntax problem straightened out:
I'm still : confused
: : : about the semantics. Does a "NULL" constraint say
that the field
: : : *must* be null, or only that it *can* be null (in
which case NULL is
: : : just a noise word, since that's the default
condition)? I had assumed
: : : the former, but Bruce seemed to think the latter...
: :
: : Can be null. Noise word. At least that is what I
rememeber Thomas
: : saying, and because it was noise, we removed it. In
fact, it doesn't
: : look like the standard accepts it, but there is no
reason we can't.

: This NULL clause is not part of constraints it is a
default option and
: we already support it,
: there's nothing like:
: CREATE TABLE table1 (field1 type NULL) in SQL92.

: but the following is SQL92 and it works on PostgreSQL:

: prova=> CREATE TABLE table1 (field1 INTEGER DEFAULT NULL);
: CREATE

2. copy command 'with null as' option not functional
3. try to create an index on a numeric and "no operator class for
'numeric' data type" error message results. Numerics not indexable?

That's fixed in current sources...its too bad you aren't
reviewing this a couple of months from now -- but I bet you
hear a lot of that...

4. no outer join -- I had to drop one query because of this

That's always been annoying, although it can be simulated
easily with:

SELECT t1.x, t2.y
FROM t1, t2
WHERE t1.x = t2.x
UNION
SELECT t1.x, NULL
FROM t1 WHERE NOT EXISTS ( SELECT t2.x FROM t2 WHERE t1.x =
t2.x );

5. no alter table add constraint
6. select count(distinct *) from a view gives a parser error on distinct
-- distinct keyword not supported here?
7. one query (dss_select_05) has an avg on a numeric field. I got an
overflow error (is there a cast to a longer type?). When the avg on
numeric field is removed, the query consumes memory rapidly and doesn't
terminate. I dropped this query.
8. Can't start postmaster with more than 65536 buffers as I get a "FATAL
1: couldn't
initialize shared buffer pool Hash Tbl". Variable overflow?

If you are referring to the -B option of the postmaster,
each "buffer" is 8K in size. So, for example -B 256 would be
2 megs of buffers. How much RAM was on the test machine? -B
65536 is a 1/2 gig...

Thanks for the tuning suggestions I received from various people.

Also, is PostgreSQL 7 expected to be SQL-92 compliant? It's pretty close
now.

I'll be posting complete scripts and C code when the story goes to print
on Feb. 14.

Regards,
Tim Dyck
Senior Analyst
PC Week Labs

************

From bouncefilter Fri Feb 4 05:53:46 2000
Received: from relayer.zd.com (relayer.zd.com [155.40.130.200])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA22437
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 05:53:39 -0500 (EST)
(envelope-from Timothy_Dyck@zd.com)
Received: from mailer.zd.com ([155.40.32.223])
by relayer.zd.com (PMDF V5.2-32 #37280)
with SMTP id <0FPE007AVJJYEK@relayer.zd.com> for
pgsql-hackers@postgreSQL.org; Fri, 4 Feb 2000 05:52:46 -0500 (EST)
Received: by mailer.zd.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998))
id 8525687B.003CC5D2 ; Fri, 04 Feb 2000 05:53:26 -0500
Date: Fri, 04 Feb 2000 05:46:24 -0500
From: Timothy Dyck <Timothy_Dyck@zd.com>
Subject: PC Week Labs benchmark results
To: pgsql-hackers@postgreSQL.org
Message-id: <8525687B.003BD14A.00@mailer.zd.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
X-Lotus-FromDomain: ZIFF-DAVIS@INET

Hi everybody, I'm done my tests of PostgreSQL and Interbase.

I concentrated on two tests, an OLTP Single Read Test, where we read a
single row out of a 200K row indexed table, and the OLTP Read Mix Test,
which is a mix of about 30 queries, about half single table selects and
the other half joins of various complexity (up to four way). For both of
these tests, InterBase was about 2x to 2.5x as fast as PostgreSQL. In
multiuser tests (up to 100 users), the situation was reversed, with
PostgreSQL close to 3 times faster at peak throughput (which was at 50
concurrent users). The reason why is that InterBase on Linux has a
process-per-connection architecture without a shared cache. As such, I had
to really limit cache sizes to allow 100 users to connect, and that really
hurt InterBase's performance.

I ran both PostgreSQL and InterBase with syncs turned off, and used a
cache of 65536 4KB pages and 4000K of sort buffer.

Here's a list of things about PostgreSQL I had problems with:

1. "Null" is not accepted keyword on "create table" ("not null" is ok)
2. copy command 'with null as' option not functional
3. try to create an index on a numeric and "no operator class for
'numeric' data type" error message results. Numerics not indexable?
4. no outer join -- I had to drop one query because of this
5. no alter table add constraint
6. select count(distinct *) from a view gives a parser error on distinct
-- distinct keyword not supported here?
7. one query (dss_select_05) has an avg on a numeric field. I got an
overflow error (is there a cast to a longer type?). When the avg on
numeric field is removed, the query consumes memory rapidly and doesn't
terminate. I dropped this query.
8. Can't start postmaster with more than 65536 buffers as I get a "FATAL
1: couldn't
initialize shared buffer pool Hash Tbl". Variable overflow?

Thanks for the tuning suggestions I received from various people.

Also, is PostgreSQL 7 expected to be SQL-92 compliant? It's pretty close
now.

I'll be posting complete scripts and C code when the story goes to print
on Feb. 14.

Regards,
Tim Dyck
Senior Analyst
PC Week Labs

From bouncefilter Fri Feb 4 10:55:50 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA00127
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 10:55:11 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id KAA06565;
Fri, 4 Feb 2000 10:53:44 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <389AAF8A.60F045C4@mascari.com>
Date: Fri, 04 Feb 2000 05:52:58 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Timothy Dyck <Timothy_Dyck@zd.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PC Week Labs benchmark results
References: <8525687B.003BD14A.00@mailer.zd.com>
<389A9DFB.BFAC279B@mascari.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mike Mascari wrote:

Timothy Dyck wrote:

Hi everybody, I'm done my tests of PostgreSQL and Interbase.

I concentrated on two tests, an OLTP Single Read Test, where we read a
single row out of a 200K row indexed table, and the OLTP Read Mix Test,
which is a mix of about 30 queries, about half single table selects and
the other half joins of various complexity (up to four way). For both of
these tests, InterBase was about 2x to 2.5x as fast as PostgreSQL. In
multiuser tests (up to 100 users), the situation was reversed, with
PostgreSQL close to 3 times faster at peak throughput (which was at 50
concurrent users). The reason why is that InterBase on Linux has a
process-per-connection architecture without a shared cache. As such, I had
to really limit cache sizes to allow 100 users to connect, and that really
hurt InterBase's performance.

I ran both PostgreSQL and InterBase with syncs turned off, and used a
cache of 65536 4KB pages and 4000K of sort buffer.

If you are referring to the -B option of the postmaster,
each "buffer" is 8K in size. So, for example -B 256 would be
2 megs of buffers. How much RAM was on the test machine? -B
65536 is a 1/2 gig...

I should have read your post more carefully. You say you
used 65536 4KB pages, so I assume you built PostgreSQL with
a BLCKSZ of 4 instead of 8, running with 256M of in-memory
buffers...

Mike Mascari

From bouncefilter Fri Feb 4 06:57:47 2000
Received: from andie.ip23.net (andie.ip23.net [212.83.32.23])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA36903;
Fri, 4 Feb 2000 06:56:49 -0500 (EST) (envelope-from sevo@ip23.net)
Received: from imap1.ip23.net (imap1.ip23.net [212.83.32.35])
by andie.ip23.net (8.9.3/8.9.3) with ESMTP id MAA21155;
Fri, 4 Feb 2000 12:56:18 +0100 (CET)
Received: from ip23.net (spc.ip23.net [212.83.32.122])
by imap1.ip23.net (8.9.3/8.9.3) with ESMTP id MAA15141;
Fri, 4 Feb 2000 12:57:57 +0100 (CET)
Sender: sevo@imap1.ip23.net
Message-ID: <389ABF93.2940C6EB@ip23.net>
Date: Fri, 04 Feb 2000 13:01:23 +0100
From: Sevo Stille <sevo@ip23.net>
Organization: IP23
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Michael Meskes <meskes@postgresql.org>
CC: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Two backends at the same time
References: <20000204095525.A799@fam-meskes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael Meskes wrote:

No, one backend won't do since one software want US style dates and the
other wants German style dates.

SET DateStyle can select date styles per session. There is no need to do
that at backend level.

Sevo

From bouncefilter Fri Feb 4 08:51:48 2000
Received: from qhars001.nortel.com (qhars001.NortelNetworks.com
[192.100.101.18]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA65213
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 08:51:19 -0500 (EST)
(envelope-from mhh@nortelnetworks.com)
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
Fri, 4 Feb 2000 13:47:38 +0000
Received: from zrchb213.us.nortel.com (actually zrchb213)
by smtprch1.nortel.com; Fri, 4 Feb 2000 07:47:22 -0600
Received: from zrtpd003.us.nortel.com ([47.140.224.137])
by zrchb213.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id 1F2TKZN8; Fri, 4 Feb 2000 07:47:21 -0600
Received: from americasm01.nt.com (hrtpp28d.us.nortel.com [47.190.110.250])
by zrtpd003.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id DJLAH8Q3; Fri, 4 Feb 2000 08:47:22 -0500
Message-ID: <389AD8E0.83CACDAC@americasm01.nt.com>
Date: Fri, 04 Feb 2000 08:49:20 -0500
From: "Mark Hollomon" <mhh@nortelnetworks.com>
Reply-To: "Mark Hollomon" <mhh@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: chris@bitmead.com
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <200002030402.XAA03844@candle.pha.pa.us>
<38998548.C6C8606A@americasm01.nt.com>
<389A04A4.BC343241@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

<I trimmed the CC list a bit>

Chris Bitmead wrote:

Mark Hollomon wrote:

[ discussion on changing the default to getting subclasses ]

I object.

Tell me why you object. Performance concerns? Compatibility?

Definitely compatibility. The load I see (200 - 300 queries a DAY)
isn't enough for me to be concerned about an extra millisecond
or two per query. But I certainly understand others concerns in
this area.

One of my responsibilities at work is the maintenance of a homegrown
document indexing and retrieval system. It is about 100K of Perl
that calls into a custom Perl wrapper around libpq. The system
is an escaped 'proof-of-concept'. I wrote it using inheritance
features of Postgres95.

The upshot is, that this proposed change would require me to examine
almost every line of this system in order to make sure that I put
ONLY in just the right spots. Yes, this would be where ever there
_isn't_ a '*', but how do I grep for the lack of a asterisk? Since
it is a "prototype", The code feels very free to pass around small
snippets of SQL, a disembodied FROM clause, a portion of a VALUES
clause.

I simply would not be allowed the time to do the rewrite necessary
to accomodate this change. And if I _did_ have the time, I would
probably rewrite it for Oracle because then DB Admin would be someone
_else's_ job.

Now, one of the days, I will find a good excuse (eg new feature)
to do a complete rewrite. And _then_ your proposal will actually
be a help.

And that is why I suggest a SET variable. When I'm ready to
use the new feature, I can. But no work is necessary until that
day arrives.

Thanks for listening.

--

Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008

From bouncefilter Fri Feb 4 09:17:49 2000
Received: from alert.infoplease.com (range.infoplease.com [208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA72650
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 09:16:54 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16648;
Fri, 4 Feb 2000 09:15:40 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id JAA27789;
Fri, 4 Feb 2000 09:15:40 -0500
Date: Fri, 4 Feb 2000 09:15:40 -0500
Message-Id: <200002041415.JAA27789@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: bright@wintelcom.net
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org
In-reply-to: <20000203165437.T25520@fw.wintelcom.net> (message from Alfred
Perlstein on Thu, 3 Feb 2000 16:54:37 -0800)
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables
Reply-to: kdebisschop@range.infoplease.com
References: <20000203145401.O25520@fw.wintelcom.net>
<389A16E8.773105A@nimrod.itg.telecom.com.au>
<20000203165437.T25520@fw.wintelcom.net>

This is what I was thinking, the problem then becomes that I'm
not aware of way to determine the error with
some degree of accuracy so that I don't mistake:
insert error because of duplication
with:
insert error because of database connectivity (or other factors)

Is it possible to do that? I guess I could parse the error responce
from the backend, but maybe there's an easier/more-correct way?

Not sure what interface you are using, But for example, perl will
easily tell the difference.

========================================================================
execute

$rv = $sth->execute || die $sth->errstr;
$rv = $sth->execute(@bind_values) || die $sth->errstr;

Perform whatever processing is necessary to execute
the prepared statement. An undef is returned if an
error occurs, a successful execute always returns true
regardless of the number of rows affected (even if
it's zero, see below). It is always important to check
the return status of execute (and most other DBI
methods) for errors.

For a non-select statement, execute returns the number
of rows affected (if known). If no rows were affected
then execute returns "0E0" which Perl will treat as 0
but will regard as true. Note that it is not an error
for no rows to be affected by a statement. If the
number of rows affected is not known then execute
returns -1.
========================================================================

which means the return value will be 0 if the insert is blocked, but
undef in there is a connectivity error.

In other words, failing to insert where a unique index prevents the
insertion is not an error.

PHP is similar.

One trick is to insert all tuple into a temporary table. Then do an
update using the natural join. The do the insert from that same
table.

If you can use a copy to create the temporary table, I think your
performance will be best.

Typically I would index the primary key of the temp table so that the
join proceeds well, but you may want to bench yourself with and
without the index. I don't think it's needed in the case you
describe.

--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)

Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper

Netsaint Plugins Development
http://netsaintplug.sourceforge.net

From bouncefilter Fri Feb 4 14:15:52 2000
Received: from feivel.fam-meskes.de (postfix@h-62.96.160.17.host.de.colt.net
[62.96.160.17]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA75652
for <pgsql-hackers@postgresql.org>; Fri, 4 Feb 2000 14:15:44 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 8D6452BBA0; Fri, 4 Feb 2000 15:29:50 +0100 (CET)
Date: Fri, 4 Feb 2000 15:29:50 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Two backends at the same time
Message-ID: <20000204152950.A26045@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
References: <20000204095525.A799@fam-meskes.de> <389ABF93.2940C6EB@ip23.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <389ABF93.2940C6EB@ip23.net>;
from sevo@ip23.net on Fri, Feb 04, 2000 at 01:01:23PM +0100
Sender: michael@fam-meskes.de

On Fri, Feb 04, 2000 at 01:01:23PM +0100, Sevo Stille wrote:

SET DateStyle can select date styles per session. There is no need to do
that at backend level.

Oops. I should have thought before asking. Sorry.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Fri Feb 4 09:45:50 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA80681
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 09:45:20 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA12683;
Fri, 4 Feb 2000 14:53:35 GMT
Sender: lockhart@hub.org
Message-ID: <389AE7EF.4EEEC4E4@alumni.caltech.edu>
Date: Fri, 04 Feb 2000 14:53:35 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Timothy Dyck <Timothy_Dyck@zd.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PC Week Labs benchmark results
References: <8525687B.003BD14A.00@mailer.zd.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi everybody, I'm done my tests of PostgreSQL and Interbase.
I concentrated on two tests, an OLTP Single Read Test, where we read a
single row out of a 200K row indexed table, and the OLTP Read Mix Test,
which is a mix of about 30 queries, about half single table selects and
the other half joins of various complexity (up to four way). For both of
these tests, InterBase was about 2x to 2.5x as fast as PostgreSQL. In
multiuser tests (up to 100 users), the situation was reversed, with
PostgreSQL close to 3 times faster at peak throughput (which was at 50
concurrent users). The reason why is that InterBase on Linux has a
process-per-connection architecture without a shared cache. As such, I had
to really limit cache sizes to allow 100 users to connect, and that really
hurt InterBase's performance.

So, we scale better. Nice.

I ran both PostgreSQL and InterBase with syncs turned off, and used a
cache of 65536 4KB pages and 4000K of sort buffer.
Here's a list of things about PostgreSQL I had problems with:

1. "Null" is not accepted keyword on "create table" ("not null" is ok)

"NULL" is *not* SQL92 standard (well, at least it wasn't in the draft
standard available on DEC's web site) presumably since including it
generally leads to parsing problems with a one-token-lookahead parser
such as yacc.

Also, since it is the default behavior for column creation, it seems
to be pretty much a useless noise word in this context.

But it will be in the next release for the typical case; I implemented
it a month or so ago but have some other developments I've been
working on and haven't yet committed this one to the source tree. Will
likely be there this weekend.

2. copy command 'with null as' option not functional

This was added 1999/12/14 to the development tree. Will be in the next
release.

3. try to create an index on a numeric and "no operator class for
'numeric' data type" error message results. Numerics not indexable?

Not yet. Should be there for the next release (1-2 months).

4. no outer join -- I had to drop one query because of this
5. no alter table add constraint
6. select count(distinct *) from a view gives a parser error on distinct
-- distinct keyword not supported here?

These are all high on the ToDo list, but I'm not sure they will be in
the next release.

7. one query (dss_select_05) has an avg on a numeric field. I got an
overflow error (is there a cast to a longer type?). When the avg on
numeric field is removed, the query consumes memory rapidly and doesn't
terminate. I dropped this query.
8. Can't start postmaster with more than 65536 buffers as I get a "FATAL
1: couldn't
initialize shared buffer pool Hash Tbl". Variable overflow?

Just guessing, but this is more likely a system resource problem. That
is a lot of buffers!

Also, is PostgreSQL 7 expected to be SQL-92 compliant? It's pretty close
now.

What feature do you feel is lacking for Postgres to be SQL92
compliant? As you know, SQL92 defines three levels of compliance, and
although virtually all databases claim compliance it is almost always
to the lowest, most basic level.

Things like outer joins are not required for the basic compliance,
which is how, for example, Oracle gets to claim compliance without
supporting SQL92 outer join syntax.

I'll be posting complete scripts and C code when the story goes to print
on Feb. 14.

Great.

Regards.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Fri Feb 4 10:18:50 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90082;
Fri, 4 Feb 2000 10:17:55 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA03609;
Fri, 4 Feb 2000 10:17:54 -0500 (EST)
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Two backends at the same time
In-reply-to: <20000204095525.A799@fam-meskes.de>
References: <20000204095525.A799@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgreSQL.org>
message dated "Fri, 04 Feb 2000 09:55:25 +0100"
Date: Fri, 04 Feb 2000 10:17:53 -0500
Message-ID: <3606.949677473@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Meskes <meskes@postgreSQL.org> writes:

What happens if I run two backends on different ports at the same time on
the same database? Is there any kind of locking done?

You mean two postmasters? Death and destruction is what will happen.
I believe there's an interlock to prevent this mistake in current
sources, but I don't recall if it was in 6.5.*.

No, one backend won't do since one software want US style dates and the
other wants German style dates. There should be no concurrent access but who
knows when I will type the wrong port.

As Sevo points out, setting DATESTYLE per-session is the right way to do
this. You might find that setting environment variable PGDATESTYLE on
the client side is a comfortable way to work --- if libpq sees that
variable set, it will issue a SET DATESTYLE command for you during
connection startup. Works with any libpq-based client, so it's
pretty transparent...

regards, tom lane

From bouncefilter Fri Feb 4 10:35:50 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA96709
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 10:35:34 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA03711;
Fri, 4 Feb 2000 10:35:31 -0500 (EST)
To: Timothy Dyck <Timothy_Dyck@zd.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PC Week Labs benchmark results
In-reply-to: <8525687B.003BD14A.00@mailer.zd.com>
References: <8525687B.003BD14A.00@mailer.zd.com>
Comments: In-reply-to Timothy Dyck <Timothy_Dyck@zd.com>
message dated "Fri, 04 Feb 2000 05:46:24 -0500"
Date: Fri, 04 Feb 2000 10:35:31 -0500
Message-ID: <3708.949678531@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Timothy Dyck <Timothy_Dyck@zd.com> writes:

Here's a list of things about PostgreSQL I had problems with:

1. "Null" is not accepted keyword on "create table" ("not null" is ok)

AFAICT from the SQL92 spec, NULL is not a legal column constraint.
I know some DBMSs accept it anyway, but we don't because it creates
grammatical ambiguities.

2. copy command 'with null as' option not functional

It looks like this has been added for 7.0 ... I haven't tried it
but I see the syntax is there.

3. try to create an index on a numeric and "no operator class for
'numeric' data type" error message results. Numerics not indexable?

Oversight in 6.5.* ... fixed for 7.0.

4. no outer join -- I had to drop one query because of this

Thomas is working on outer joins, but I'm not sure if it'll be ready
for 7.0. 7.1 for sure though; this is our most-requested missing SQL92
feature.

5. no alter table add constraint

Not there yet (but Peter E. was working on it when last seen...)

6. select count(distinct *) from a view gives a parser error on distinct
-- distinct keyword not supported here?

No, but it is for 7.0.

7. one query (dss_select_05) has an avg on a numeric field. I got an
overflow error (is there a cast to a longer type?). When the avg on
numeric field is removed, the query consumes memory rapidly and doesn't
terminate. I dropped this query.

Bug. I posted a patch for this and a couple of other NUMERIC problems
a few weeks ago; it'll be in 7.0 of course, and you can get the patch
off the pgsql-patches list archives if you need it to work in 6.5.*.

8. Can't start postmaster with more than 65536 buffers as I get a "FATAL
1: couldn't initialize shared buffer pool Hash Tbl". Variable overflow?

Probably. Hadn't occurred to me that we need to check for a sane upper
bound on the number of buffers, but I guess we do. (You do realize that
would be half a gig of in-memory buffers, right? If you've actually got
that much RAM, it's probably better to let the OS use it for general-
purpose disk buffers instead of dedicating it all to Postgres.)

Also, is PostgreSQL 7 expected to be SQL-92 compliant? It's pretty close
now.

We're getting closer all the time, but I wouldn't want to promise that
we'll ever have everything that's in SQL92.

Thanks for the report! I don't suppose you'd be interested in rerunning
your tests on current (pre-beta-7.0) sources?

regards, tom lane

From bouncefilter Fri Feb 4 11:32:51 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA12010
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 11:32:41 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA12120;
Fri, 4 Feb 2000 08:31:59 -0800 (PST)
Message-Id: <3.0.1.32.20000204082629.00fd8860@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 04 Feb 2000 08:26:29 -0800
To: Mike Mascari <mascarm@mascari.com>, Timothy Dyck <Timothy_Dyck@zd.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] PC Week Labs benchmark results
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <389A9DFB.BFAC279B@mascari.com>
References: <8525687B.003BD14A.00@mailer.zd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:38 AM 2/4/00 -0500, Mike Mascari wrote:

That's always been annoying, although it can be simulated
easily with:

SELECT t1.x, t2.y
FROM t1, t2
WHERE t1.x = t2.x
UNION
SELECT t1.x, NULL
FROM t1 WHERE NOT EXISTS ( SELECT t2.x FROM t2 WHERE t1.x =
t2.x );

SOME - but not all - outer joins can be simulated with this
trick. Others require subselects in the target list, etc.

And the union form gets really messy when a query includes more
than one outer join.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Fri Feb 4 11:38:51 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA14850
for <pgsql-hackers@postgresql.org>; Fri, 4 Feb 2000 11:38:01 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Fri, 4 Feb 2000 10:28:14 -0600
Sender: ed
Message-ID: <389B00A9.45077CC0@austin.rr.com>
Date: Fri, 04 Feb 2000 10:39:05 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Timothy Dyck <Timothy_Dyck@zd.com>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] PC Week Labs benchmark results
References: <8525687B.003BD14A.00@mailer.zd.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I was disappointed this benchmark did not include database recovery
and reliability measurements. Benchmarks ought to include the most
important characteristics of an RDBMS, and recovery/reliability is
certainly one of them. People tend to try to "measure up" against
accepted benchmarks; as one currently suffering from apparent
reliability issues, the thought of decreased focus on reliability irks
me.

Cheers,
Ed Loehr

Timothy Dyck wrote:

Hi everybody, I'm done my tests of PostgreSQL and Interbase.

From bouncefilter Fri Feb 4 12:14:51 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA25132
for <pgsql-hackers@postgresql.org>; Fri, 4 Feb 2000 12:14:26 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12GmH5-0001m0-00; Fri, 4 Feb 2000 17:12:03 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12GmGv-0000vY-00; Fri, 4 Feb 2000 17:11:53 +0000
Date: Fri, 4 Feb 2000 17:11:53 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
Message-ID: <20000204171153.D3402@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<1426.949641960@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <1426.949641960@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Fri, Feb 04, 2000 at 12:26:00AM -0500

It seems that I am still tracking problems, but each time they turn out to
have a different cause: A slight variant on the select that caused memory
to run out gives

newnham=# select crsids.surname, "tblPerson"."Surname" from crsids,"tblPerson" where crsids.usn="tblPerson"."USN"::int4;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Nested Loop (cost=66496.62 rows=34359 width=40)
-> Seq Scan on tblPerson (cost=157.62 rows=2625 width=24)
-> Seq Scan on crsids (cost=25.27 rows=584 width=16)

this is the table I based the memory hog on (2600*600). The backend closes
instantly ie., no memory usage! And, as before, it is hard to find a test case
that will do the same as repeatably (ie., test case never crashes, the
above case crashes every single time). "tblPerson", as its strange
capitalisation suggests, was imported from M$ access via ODBC.

select test.txt,test2.var from test,test2 where test2.i=test.var::int4;

Nested Loop (cost=63504.80 rows=2600 width=40)
-> Seq Scan on test2 (cost=24.80 rows=600 width=16)
-> Seq Scan on test (cost=105.80 rows=2600 width=24)

works fine.

Any thoughts on where to look?

Cheers,

Patrick

From bouncefilter Fri Feb 4 13:24:52 2000
Received: from bender.toppoint.de (bender.toppoint.de [195.244.243.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA45189;
Fri, 4 Feb 2000 13:24:41 -0500 (EST)
(envelope-from marten@feki.toppoint.de)
Received: (from uucp@localhost)
by bender.toppoint.de (8.9.3/8.9.3) id TAA27745;
Fri, 4 Feb 2000 19:24:15 +0100 (MET)

Received: (from marten@localhost)

by feki.toppoint.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id TAA07061;
Fri, 4 Feb 2000 19:15:31 +0100
From: Marten Feldtmann <marten@feki.toppoint.de>
Message-Id: <200002041815.TAA07061@feki.toppoint.de>
Subject: Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL
In-Reply-To: <389A0932.6D4C0CC@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 4, 2000 10:03:14 am"
To: chris@bitmead.com
Date: Fri, 4 Feb 2000 19:15:31 +0100 (CET)
CC: Peter Eisentraut <peter_e@gmx.net>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

Peter Eisentraut wrote:

This is a really stu^H^H^H bad idea. I have hierarchies 5 levels deep
with
multiple inheritance, and I
don't want to do a 10 way join just to retrieve an object.

This is why RDBMS's performance sucks so incredibly badly on some
applications.
an ODBMS can perform 100x as fast in these cases just because of what
you
are proposing.

Hmm, and yes one may find problems where the pure relational system
is 100x faster than your ODBMS.

After doing a project with VERSANT and VisualWorks (election projection
system for the first television sender here in Germany) I like the
idea of OODBMS, but I've also noticed, that they are not the solution
to all problems.

Clever database desing leeds to good performance on both systems, but
one should consider, that the designs of the database layout will be
different. There are cases, where a pure relational system is very
fast and an ODBMS never get it, but there are the examples you
mentioned.

Joins per se are not that bad .. it depends on when and how they
are used and how good the analyzer of the database is and how good
he uses the indices to get the job done.

One very good point is the query language of the rdbms systems. On
the odbms side no standard is really available, which can be seen as
the sql of the odbms.

Marten

From bouncefilter Fri Feb 4 14:49:53 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA85903
for <pgsql-hackers@postgresql.org>; Fri, 4 Feb 2000 14:49:06 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id OAA28027
for pgsql-hackers@postgresql.org; Fri, 4 Feb 2000 14:19:54 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "Douglas Ribas de Mattos" <dmattos@visteon.com>
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Test
Date: Fri, 4 Feb 2000 16:40:06 -0200
Organization: Ford Motor Company
Lines: 3
Message-ID: <87f68p$g3l16@eccws12.dearborn.ford.com>
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
To: pgsql-hackers@postgresql.org

It is a test...

From bouncefilter Fri Feb 4 15:01:53 2000
Received: from feivel.fam-meskes.de (postfix@h-62.96.159.49.host.de.colt.net
[62.96.159.49]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA88941
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 15:01:47 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 2610D2BB9E; Fri, 4 Feb 2000 20:45:48 +0100 (CET)
Date: Fri, 4 Feb 2000 20:45:48 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Two backends at the same time
Message-ID: <20000204204548.B1929@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000204095525.A799@fam-meskes.de> <3606.949677473@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <3606.949677473@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Fri, Feb 04, 2000 at 10:17:53AM -0500
Sender: michael@fam-meskes.de

On Fri, Feb 04, 2000 at 10:17:53AM -0500, Tom Lane wrote:

You mean two postmasters? Death and destruction is what will happen.
I believe there's an interlock to prevent this mistake in current
sources, but I don't recall if it was in 6.5.*.

I don't think there is one in 6.5.* since I was able to start two.

As Sevo points out, setting DATESTYLE per-session is the right way to do
this. You might find that setting environment variable PGDATESTYLE on
the client side is a comfortable way to work --- if libpq sees that

Yes, that would be a much better way. If now my perl wasn't so rusty since I
have to set that variable in a CGI script.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Fri Feb 4 15:59:53 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA04770
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 15:59:05 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id PAA04806;
Fri, 4 Feb 2000 15:58:57 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <20000204171153.D3402@quartz.newn.cam.ac.uk>
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<1426.949641960@sss.pgh.pa.us>
<20000204171153.D3402@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Fri, 04 Feb 2000 17:11:53 +0000"
Date: Fri, 04 Feb 2000 15:58:57 -0500
Message-ID: <4803.949697937@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

newnham=# select crsids.surname, "tblPerson"."Surname" from crsids,"tblPerson" where crsids.usn="tblPerson"."USN"::int4;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Any thoughts on where to look?

Is there anything in the postmaster log? Is there a core file (look
in the database subdirectory, ie .../data/base/yourdatabase/core)?
If so, compiling the backend with -g and extracting a backtrace from
the resulting corefile with gdb would be very useful info.

regards, tom lane

From bouncefilter Fri Feb 4 16:47:54 2000
Received: from arkin.exoffice.com (host95.ridgeventures.com [207.33.160.95]
(may be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id QAA27526
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 16:47:31 -0500 (EST)
(envelope-from arkin@exoffice.com)
Received: from exoffice.com (IDENT:arkin@arkin.exoffice.com [192.168.1.4])
by arkin.exoffice.com (8.9.3/8.9.3) with ESMTP id NAA01336
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 13:48:39 -0800
Sender: arkin@arkin.exoffice.com
Message-ID: <389B4936.88C19F4@exoffice.com>
Date: Fri, 04 Feb 2000 13:48:38 -0800
From: Assaf Arkin <arkin@exoffice.com>
Organization: Exoffice
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Identifying duplicate key inserts
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have a mechanism which stores objects inside the database. The primary
key is supplied by the object, so when a new object is created I need to
identify duplicate primary keys.

Originally I ran a SELECT against the table to identify if a record with
the same key exists, followed by an UPDATE. This approach can fail in a
race condition with some other thread getting the INSERT done first.

For Sybase I have restructed it to perform the INSERT first, and based
on the returned X/Open error code identify if a duplicate key exists.
Postgresql does not return an X/Open error code, so in the event of a
duplicate key I need to perform the INSERT to determine whether a
duplicate key was there, or it was another INSERT error.

When I perform an INSERT (which fails) followed by a SELECT on the same
table row, the SELECT operation ends with an error, reporting 'No
results were returned by the query.'

Is this a know bug and is a fixed planned for it in 0.7?

arkin

--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org

From bouncefilter Fri Feb 4 17:08:54 2000
Received: from hu.tm.ee (ppp233.tele2.ee [212.107.33.233])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA34667
for <pgsql-hackers@postgreSQL.org>; Fri, 4 Feb 2000 17:08:18 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 6B72F39AC; Sat, 5 Feb 2000 00:15:11 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389B4F6F.89B0221A@tm.ee>
Date: Sat, 05 Feb 2000 00:15:11 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: chris@bitmead.com
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Time travel
References: <000b01bf6ecc$d7733a60$2801007e@tpf.co.jp>
<389A60BB.D8A4484B@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Bitmead wrote:

Now in the documentation it mentioned removing time travel because
"performance impact, storage size, and a pg_time file which
grows toward infinite size in a short period of time.".

In the time this was written 200MB disk was a big disk.

Now since I believe the postgres storage manager does not replace
records in place when updated,

Yes, it's true at least for 6.5.3 (I've written a small script that
extracts the old/hidden tuples) and I'm pretty sure that for 7.x too
perhaps it is the removal of pg_time (which i think recorded correspondence
between transaction ids and timestamps) that gives the big performance win.

I can't see how it is different to
having the time travel feature with vacuum configured to remove
all old records immediately. I don't know what the pg_time file
is.

I guss it could be just a add_only, monotonuously growing 'tape'-type file,
suitable for being searched using binary search. So really not nearly as
much overhead as would be a regular pg table with two indexes.

Have I missed something about why taking out time travel has
improved performance, as opposed to simply making immediate
vacuum the default? Clearly the performance of triggers as an
alternative is going to suck very badly, since the postgres
storage manager was built specially from the ground up to
support time travel with its non-update semantics, and it
still has these characteristics.

Implementing time-travel with triggers wil actually give us double
time-travel, on hidden and one visible ;)

From bouncefilter Fri Feb 4 17:30:55 2000
Received: from hu.tm.ee (ppp233.tele2.ee [212.107.33.233])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA39382;
Fri, 4 Feb 2000 17:30:32 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 2DF7E39AC; Sat, 5 Feb 2000 00:37:36 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389B54AF.9614B3D3@tm.ee>
Date: Sat, 05 Feb 2000 00:37:35 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: chris@bitmead.com
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Mark Hollomon <mhh@nortelnetworks.com>,
Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <200002030402.XAA03844@candle.pha.pa.us>
<38998548.C6C8606A@americasm01.nt.com>
<28272.949596778@sss.pgh.pa.us>
<389A157B.1EDF669@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Bitmead wrote:

Tom, I agree with most of what you say. If we want to have ** be the
default
syntax for getting sub-columns I can live with that (for suggestion (3))

But for (2), I do feel very strongly that getting sub-tuples should be
the
"default default", and a SET GETSUBCLASSES=true should be the default
setting.

Then maybe we need a way to "break off" inheritance, i.e. make the inherited
table independent but retain the columns as they are at the time of breakage.

At least it could be given as an option in pg_dump. (--dump_flat_creates or
smth.)

I've been using the postgres inheritance for a real system and I can
say with certainty that this is a massive source of errors. Not
wanting sub-class tuples seems rarely needed, and leaving off the "*" is
something that too often seems forgotten. I often can trawl through
code and realise that some query is missing the "*" but it hasn't been
discovered yet. In fact I find that almost all queries require the "*"
when you have a proper OO model, and not using "*" is usually laziness.

True. I also think that people who used inheritance as a create table shortcut
can most easily ensure compatibility by dumping their not-really-inherited
tables as independent. They will have to dump-relaod anyway.

Also when adding a sub-class where there previously was none, one
usually has to trawl through the queries and add "*" to all of them
because as I said, there are almost never occasions where "*" is not
required in real life OO models.

So I understand the compatibility issue here, but I really feel strongly
that this should be changed now before there really are a lot of people
using it. Sure, have as many compatibility modes as you like, but I
think
this is a broken enough design that the default should be changed.
Apparently Illustra/Informix agreed.

And they are probably the only external DB we can aim to be compatible with,
or what does SQL3 say?

----------------------
Hannu

From bouncefilter Fri Feb 4 20:44:57 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA12759;
Fri, 4 Feb 2000 20:43:57 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id MAA20096;
Sat, 5 Feb 2000 12:41:35 +1100
Sender: chris@tech.com.au
Message-ID: <389B7FCE.6320E3AF@bitmead.com>
Date: Sat, 05 Feb 2000 12:41:34 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Marten Feldtmann <marten@feki.toppoint.de>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
References: <200002032119.WAA04803@feki.toppoint.de>
<3.0.1.32.20000203211710.00fd09c0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

Without prejudice, I'd be interested in some order-of-magnitude
market share for these technologies vs., say, Oracle.

Would you be interested in the market share of Win98 compared to Linux?

Nobody uses an ODBMS if they can get it to work with Oracle. They go to
an ODBMS when they realise that's the only way they can get it to work.

However, as I said, Sun is defining for Java a standard interface for
RDBMS which is exactly the same as ODMG. So expect a lot of people using
Oracle to be writing code that ports to an ODBMS. Maybe when they
realise they can slot a real ODBMS under their
app and greatly increase performance, it might be
good for the ODBMS market.

There's no doubt of this, for applications that can > make use of the paradigms.

To my mind that is like saying OO is useful for programs that can make
use of the paradigms. In fact I think nearly all programs can make use
of OO.

And this last statement I really have to wonder
about. For restricted
application spaces, yeah, no doubt. But in general,
no way.

It's only when you need a great deal of ad-hoc queries that you really
need a RDBMS. But a very great proportion of apps have only very
specific querying needs, and an ODBMS can do those queries MUCH faster.

And if postgresql has *both*, then it should be the
best of both worlds. I'm not going to go around
claiming RDBMS is obsolete, but I do know that ODBMS
is much more convenient to use for programming. Once
you've done your app and you want to spew off a few
reports, that's when you wish you had RDBMS.

Exactly, so stop mapping things and creating complicated joins. ODBMSes
do not do ANY joins to re-create objects. That's why mappers suck so
hard.

If they don't do joins, then presumably they map many-to-one relations
by copying data into each of the "many" table rows. TANSTAAFL, no?

^^^ ?

They have a similar layout on disk to what you might have in memory. So
if you store a 1:M in memory as an array of pointers, that's how you
might do it on disk too.

Though this strategy is a very viable one in today's
big-memory, big-disk
environment. It's not clear to me that a extremely
smart RDBMS system
couldn't decide to add redundancy itself and gain
much of the efficiency,
but, heck, that's just my weak, uncreative
compiler-writer mind at work again.

Do you mean an RDBMS might try and be smart and store it the same way?
Well if it did that, we might call it an ODBMS. But the other main
benefit of an ODBMS is that retrieving records for many cases
(non-ad-hoc) is very simple to program for because you don't have to map
say a join table into say a C++ List<type>. In
other words it's not just the performance of ODBMS
that is good, but also the interface. Also
if an RDBMS maps an object to a table and then maps it
back to an array on disk, well you've done an
unnecessary conversion.

Now with an ODBMS, a Car with 4 wheels and a steering wheel we'll have 6
objects in the database - 1 Car, 4 RoadWheels and 1 SteeringWheel. With
a relational mapper, depending on how you map it you'll have 21 objects
- 5 CarPart objects, 5 wheel objects, 4 road wheel, 1 steering wheel, 1
car and 5 car_carpart relation entities. And when you join it all
together you'll have to join against 6 tables instead of 3.

Not really. You'd probably denormalize and not
worry about it, in practice.

Then what happens to your RDBMSes wonderful ad-hoc query facility if you
de-normalise? Will you have to do a UNION with about 5000 clauses to
retrieve the volume and price of each type of car part?

Would the result be as beautiful? I don't know - do
most car designers
think that SteeringMechanism and PavementInterface
are the same? It's
true for a variety of reasons in today's cars that
aren't actually
related, and high-end race cars are exploring
joystick control.

So one could claim that your hierarchy is merely
limiting creative expression...

My hierarchy? The point is that you can _have_ a hierarchy. It's well
accepted that OO hierarchies are
good. The good thing here is being able to directly
store it in the database.

From bouncefilter Fri Feb 4 20:43:57 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA12692;
Fri, 4 Feb 2000 20:43:31 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id BAA13611;
Sat, 5 Feb 2000 01:51:50 GMT
Sender: lockhart@hub.org
Message-ID: <389B8236.55AE3A38@alumni.caltech.edu>
Date: Sat, 05 Feb 2000 01:51:50 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Meskes <meskes@postgresql.org>
CC: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Two backends at the same time
References: <20000204095525.A799@fam-meskes.de> <3606.949677473@sss.pgh.pa.us>
<20000204204548.B1929@fam-meskes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If now my perl wasn't so rusty since I
have to set that variable in a CGI script.

$ENV{"PGDATESTYLE"} = "German";

might do it, but I'm not recalling with certainty that Perl does the
Right Thing in to make the variable visible to children (pretty sure
it does).

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Fri Feb 4 20:52:58 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA13961;
Fri, 4 Feb 2000 20:52:41 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id MAA20190;
Sat, 5 Feb 2000 12:52:16 +1100
Sender: chris@tech.com.au
Message-ID: <389B8250.EB7CF08A@bitmead.com>
Date: Sat, 05 Feb 2000 12:52:16 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Marten Feldtmann <marten@feki.toppoint.de>
CC: Peter Eisentraut <peter_e@gmx.net>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
Subject: Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL
References: <200002041815.TAA07061@feki.toppoint.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Marten Feldtmann wrote:

Hmm, and yes one may find problems where the pure
relational system is 100x faster than your ODBMS.

After doing a project with VERSANT and VisualWorks
(election projection system for the first television
sender here in Germany) I like the idea of OODBMS,
but I've also noticed, that they are not the
solution to all problems.

Give me a clear application spec and VERSANT, and I will ALWAYS flog
Oracle into the dust. But...

Where SQL comes into it's own is _conveniently_ doing queries that I
never thought of when I first designed my app. Of course many ODBMSes
have SQL or similar too.

Joins per se are not that bad .. it depends on when
and how they are used and how good the analyzer of
the database is and how good he uses the indices to
get the job done.

Take the simple SUPPLIER, PART and SUPPLIER_PART situation. The very
fact that you've got an extra table here means you've got to touch many
more disk pages and transfer more data. An RDBMS just can't win when the
ODBMS data model is designed right.

One very good point is the query language of the
rdbms systems. On the odbms side no standard is
really available, which can be seen as the sql of
the odbms.

There is a standard called OQL which is very similar to SQL. It's just
rather poorly supported.

--
Chris Bitmead
mailto:chris@bitmead.com

From bouncefilter Fri Feb 4 21:07:58 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA20290;
Fri, 4 Feb 2000 21:07:04 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA01136;
Fri, 4 Feb 2000 18:06:01 -0800 (PST)
Message-Id: <3.0.1.32.20000204180357.017612a0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 04 Feb 2000 18:03:57 -0800
To: Chris <chris@bitmead.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Cc: Marten Feldtmann <marten@feki.toppoint.de>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
In-Reply-To: <389B7FCE.6320E3AF@bitmead.com>
References: <200002032119.WAA04803@feki.toppoint.de>
<3.0.1.32.20000203211710.00fd09c0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:41 PM 2/5/00 +1100, Chris wrote:

Don Baccus wrote:

Without prejudice, I'd be interested in some order-of-magnitude
market share for these technologies vs., say, Oracle.

Would you be interested in the market share of Win98 compared to Linux?

Postgres isn't in competition with either of those software products. It
is probably worth pointing out that at least some of the folks in the Linux
community would like to derail Win98 to some degree.

And I, at least, would love to see Postgres derail Oracle to some degree.

...

There's no doubt of this, for applications that can > make use of the

paradigms.

To my mind that is like saying OO is useful for programs that can make
use of the paradigms. In fact I think nearly all programs can make use
of OO.

This really isn't the place for a religious fight. Personally, I believe
the OO paradigm is well-suited to the decomposition of some problems, not
particularly well-suited to others. I've only been a professional software
engineer for 29 years, though, so I don't pretend to have all the answers.
I'd humbly suggest that OO methodologists don't, either.

But, that's just my opinion.

Far more important to me is that SQL queries not suffer performance hits
as a result of whatever changes to OO support make it into the standard
version of PG.

Let's just leave it at that, OK?

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Fri Feb 4 22:36:58 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA44338
for <hackers@postgreSQL.org>; Fri, 4 Feb 2000 22:36:50 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id OAA21125
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 14:36:44 +1100
Sender: chris@tech.com.au
Message-ID: <389B9ACB.9F929BAE@bitmead.com>
Date: Sat, 05 Feb 2000 14:36:43 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Patch attached...
Content-Type: multipart/mixed; boundary="------------A7B802EC4868B515DDDB4FFA"

This is a multi-part message in MIME format.
--------------A7B802EC4868B515DDDB4FFA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Attached is a patch for the ONLY inheritance
functionality...

*) It includes a SET compatibility mode.
*) The overhead for non-inheritance has
been cut down to 30 microseconds (on a pc).
*) It needs an initdb.

Comments welcome.

--
Chris Bitmead
mailto:chris@bitmead.com
--------------A7B802EC4868B515DDDB4FFA
Content-Type: text/plain; charset=us-ascii;
name="patch.only"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="patch.only"

? src/backend/1
Index: src/backend/commands/creatinh.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/commands/creatinh.c,v
retrieving revision 1.56
diff -c -r1.56 creatinh.c
*** src/backend/commands/creatinh.c	2000/01/29 16:58:34	1.56
--- src/backend/commands/creatinh.c	2000/02/05 03:13:17
***************
*** 35,40 ****
--- 35,43 ----
                              const char *attributeType, List *schema);
  static List *MergeAttributes(List *schema, List *supers, List **supconstr);
  static void StoreCatalogInheritance(Oid relationId, List *supers);
+ static void
+ setRelhassubclassInRelation(Oid relationId, bool relhassubclass);
+ 

  /* ----------------------------------------------------------------
   *		DefineRelation
***************
*** 323,328 ****
--- 326,332 ----
  		TupleConstr *constr;

relation = heap_openr(name, AccessShareLock);
+ setRelhassubclassInRelation(relation->rd_id, true);
tupleDesc = RelationGetDescr(relation);
constr = tupleDesc->constr;

***************
*** 655,657 ****
--- 659,698 ----
  	}
  	return false;
  }
+ 
+ 
+ static void
+ setRelhassubclassInRelation(Oid relationId, bool relhassubclass)
+ {
+         Relation        relationRelation;
+         HeapTuple       tuple;
+         Relation        idescs[Num_pg_class_indices];
+ 
+         /*
+          * Lock a relation given its Oid. Go to the RelationRelation (i.e.
+          * pg_relation), find the appropriate tuple, and add the specified
+          * lock to it.
+          */
+         relationRelation = heap_openr(RelationRelationName, RowExclusiveLock);
+         tuple = SearchSysCacheTupleCopy(RELOID,
+                                                                         ObjectIdGetDatum(relationId),
+                                                                         0, 0, 0)
+ ;
+         Assert(HeapTupleIsValid(tuple));
+ 
+         ((Form_pg_class) GETSTRUCT(tuple))->relhassubclass = relhassubclass;
+         heap_update(relationRelation, &tuple->t_self, tuple, NULL);
+ 
+         /* keep the catalog indices up to date */
+         CatalogOpenIndices(Num_pg_class_indices, Name_pg_class_indices, idescs);
+         CatalogIndexInsert(idescs, Num_pg_class_indices, relationRelation, tuple
+ );
+         CatalogCloseIndices(Num_pg_class_indices, idescs);
+ 
+         heap_freetuple(tuple);
+         heap_close(relationRelation, RowExclusiveLock);
+ }
+ 
+ 
+ 
+ 
Index: src/backend/commands/variable.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/commands/variable.c,v
retrieving revision 1.28
diff -c -r1.28 variable.c
*** src/backend/commands/variable.c	2000/01/22 23:50:10	1.28
--- src/backend/commands/variable.c	2000/02/05 03:13:18
***************
*** 48,53 ****
--- 48,56 ----

extern bool _use_keyset_query_optimizer;

+ #define examine_subclass_default true
+ bool examine_subclass = examine_subclass_default;
+ 
  /*
   *
   * Get_Token
***************
*** 228,233 ****
--- 231,274 ----
  	geqo_rels = GEQO_RELS;
  	return TRUE;
  }
+ /*
+  *
+  * EXAMINE_SUBCLASS
+  *
+  */
+ #define EXAMINE_SUBCLASS "EXAMINE_SUBCLASS"
+ 
+ static bool
+ parse_examine_subclass(const char *value)
+ {
+     if (strcasecmp(value, "on") == 0)
+         examine_subclass = true;
+     else if (strcasecmp(value, "off") == 0)
+         examine_subclass = false;
+     else if (strcasecmp(value, "default") == 0) 
+         examine_subclass = examine_subclass_default;
+ 	else
+ 		elog(ERROR, "Bad value for %s (%s)", EXAMINE_SUBCLASS, value);
+ 	return TRUE;
+ }
+ 
+ static bool
+ show_examine_subclass()
+ {
+     
+ 	if (examine_subclass)
+ 		elog(NOTICE, "%s is ON", EXAMINE_SUBCLASS);
+ 	else
+ 		elog(NOTICE, "%s is OFF", EXAMINE_SUBCLASS);
+ 	return TRUE;
+ }
+ 
+ static bool
+ reset_examine_subclass(void)
+ {
+     examine_subclass = examine_subclass_default;
+ 	return TRUE;
+ }

  /*
   *
***************
*** 600,605 ****
--- 641,649 ----
  	{
  		"pg_options", parse_pg_options, show_pg_options, reset_pg_options
  	},
+     {
+ 		EXAMINE_SUBCLASS, parse_examine_subclass, show_examine_subclass, reset_examine_subclass
+     },
  	{
  		NULL, NULL, NULL, NULL
  	}
Index: src/backend/optimizer/plan/planner.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v
retrieving revision 1.74
diff -c -r1.74 planner.c
*** src/backend/optimizer/plan/planner.c	2000/01/27 18:11:31	1.74
--- src/backend/optimizer/plan/planner.c	2000/02/05 03:13:21
***************
*** 35,40 ****
--- 35,41 ----
  #include "utils/builtins.h"
  #include "utils/lsyscache.h"
  #include "utils/syscache.h"
+ #include "parser/parsetree.h"

static List *make_subplanTargetList(Query *parse, List *tlist,
AttrNumber **groupColIdx);
***************
*** 140,146 ****
* to change interface to plan_union_queries to pass that info back!
*/
}
! else if ((rt_index = first_inherit_rt_entry(rangetable)) != -1)
{
List *sub_tlist;

--- 141,147 ----
  		 * to change interface to plan_union_queries to pass that info back!
  		 */
  	}
! 	else if ((rt_index = first_inherit_rt_entry(rangetable)) != -1 && has_inheritors(rt_fetch(rt_index, parse->rtable)->relid))
  	{
  		List	   *sub_tlist;

Index: src/backend/optimizer/prep/prepunion.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/optimizer/prep/prepunion.c,v
retrieving revision 1.43
diff -c -r1.43 prepunion.c
*** src/backend/optimizer/prep/prepunion.c	2000/02/03 06:12:19	1.43
--- src/backend/optimizer/prep/prepunion.c	2000/02/05 03:13:23
***************
*** 25,30 ****
--- 25,33 ----
  #include "parser/parse_clause.h"
  #include "parser/parsetree.h"
  #include "utils/lsyscache.h"
+ #include "access/heapam.h"
+ #include "catalog/catname.h"
+ #include "utils/syscache.h"

  typedef struct {
  	Index		rt_index;
***************
*** 45,50 ****
--- 48,54 ----
  static Append *make_append(List *appendplans, List *unionrtables,
  						   Index rt_index,
  						   List *inheritrtable, List *tlist);
+ bool has_inheritors(Oid relationId);

  /*
***************
*** 352,357 ****
--- 356,386 ----

  	*union_rtentriesPtr = union_rtentries;
  	return union_plans;
+ }
+ 
+ bool has_inheritors(Oid relationId)
+ {
+         bool rtn;
+         Relation        relationRelation;
+         HeapTuple       tuple;
+ 
+         /*
+          * Lock a relation given its Oid. Go to the RelationRelation (i.e.
+          * pg_relation), find the appropriate tuple, and add the specified
+          * lock to it.
+          */
+         relationRelation = heap_openr(RelationRelationName, NoLock);
+         tuple = SearchSysCacheTupleCopy(RELOID,
+                                         ObjectIdGetDatum(relationId),
+                                         0, 0, 0)
+ ;
+ /*        Assert(HeapTupleIsValid(tuple)); */
+ 
+         rtn = ((Form_pg_class) GETSTRUCT(tuple))->relhassubclass;
+ 
+         heap_freetuple(tuple);
+         heap_close(relationRelation, NoLock);
+         return rtn;
  }

  /*
Index: src/backend/parser/gram.y
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.139
diff -c -r2.139 gram.y
*** src/backend/parser/gram.y	2000/02/04 18:49:33	2.139
--- src/backend/parser/gram.y	2000/02/05 03:13:39
***************
*** 3553,3562 ****

  relation_expr:	relation_name
  				{
! 					/* normal relations */
  					$$ = makeNode(RelExpr);
  					$$->relname = $1;
! 					$$->inh = FALSE;
  				}
  		| relation_name '*'				  %prec '='
  				{
--- 3553,3563 ----

  relation_expr:	relation_name
  				{
!     				/* default inheritance */
!                     extern bool examine_subclass;
  					$$ = makeNode(RelExpr);
  					$$->relname = $1;
! 					$$->inh = examine_subclass;
  				}
  		| relation_name '*'				  %prec '='
  				{
***************
*** 3565,3570 ****
--- 3566,3578 ----
  					$$->relname = $1;
  					$$->inh = TRUE;
  				}
+         | ONLY relation_name
+                 {
+ 					/* no inheritance */
+ 					$$ = makeNode(RelExpr);
+ 					$$->relname = $2;
+ 					$$->inh = FALSE;
+                 }

  opt_array_bounds:	'[' ']' opt_array_bounds
  				{  $$ = lcons(makeInteger(-1), $3); }
Index: src/include/catalog/pg_attribute.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/include/catalog/pg_attribute.h,v
retrieving revision 1.53
diff -c -r1.53 pg_attribute.h
*** src/include/catalog/pg_attribute.h	2000/01/26 05:57:57	1.53
--- src/include/catalog/pg_attribute.h	2000/02/05 03:13:39
***************
*** 402,408 ****
  { 1259, {"relrefs"},	   21, 0,	2, 16, 0, -1, -1, '\001', 'p', '\0', 's', '\0', '\0' }, \
  { 1259, {"relhaspkey"},    16, 0,	1, 17, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
  { 1259, {"relhasrules"},   16, 0,	1, 18, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
! { 1259, {"relacl"},		 1034, 0,  -1, 19, 0, -1, -1,	'\0', 'p', '\0', 'i', '\0', '\0' }

  DATA(insert OID = 0 ( 1259 relname			19 0 NAMEDATALEN   1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 reltype			26 0  4   2 0 -1 -1 t p f i f f));
--- 402,409 ----
  { 1259, {"relrefs"},	   21, 0,	2, 16, 0, -1, -1, '\001', 'p', '\0', 's', '\0', '\0' }, \
  { 1259, {"relhaspkey"},    16, 0,	1, 17, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
  { 1259, {"relhasrules"},   16, 0,	1, 18, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
! { 1259, {"relhassubclass"},16, 0,	1, 19, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
! { 1259, {"relacl"},		 1034, 0,  -1, 20, 0, -1, -1,	'\0', 'p', '\0', 'i', '\0', '\0' }

  DATA(insert OID = 0 ( 1259 relname			19 0 NAMEDATALEN   1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 reltype			26 0  4   2 0 -1 -1 t p f i f f));
***************
*** 422,428 ****
  DATA(insert OID = 0 ( 1259 relrefs			21 0  2  16 0 -1 -1 t p f s f f));
  DATA(insert OID = 0 ( 1259 relhaspkey		16 0  1  17 0 -1 -1 t p f c f f));
  DATA(insert OID = 0 ( 1259 relhasrules		16 0  1  18 0 -1 -1 t p f c f f));
! DATA(insert OID = 0 ( 1259 relacl		  1034 0 -1  19 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 ctid				27 0  6  -1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 oid				26 0  4  -2 0 -1 -1 t p f i f f));
  DATA(insert OID = 0 ( 1259 xmin				28 0  4  -3 0 -1 -1 t p f i f f));
--- 423,430 ----
  DATA(insert OID = 0 ( 1259 relrefs			21 0  2  16 0 -1 -1 t p f s f f));
  DATA(insert OID = 0 ( 1259 relhaspkey		16 0  1  17 0 -1 -1 t p f c f f));
  DATA(insert OID = 0 ( 1259 relhasrules		16 0  1  18 0 -1 -1 t p f c f f));
! DATA(insert OID = 0 ( 1259 relhassubclass	16 0  1   19 0 -1 -1 t p f c f f));
! DATA(insert OID = 0 ( 1259 relacl		  1034 0 -1  20 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 ctid				27 0  6  -1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 oid				26 0  4  -2 0 -1 -1 t p f i f f));
  DATA(insert OID = 0 ( 1259 xmin				28 0  4  -3 0 -1 -1 t p f i f f));
Index: src/include/catalog/pg_class.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/include/catalog/pg_class.h,v
retrieving revision 1.33
diff -c -r1.33 pg_class.h
*** src/include/catalog/pg_class.h	2000/01/26 05:57:57	1.33
--- src/include/catalog/pg_class.h	2000/02/05 03:13:40
***************
*** 78,88 ****
  	int2		relrefs;		/* # of references to this relation */
  	bool		relhaspkey;		/* has PRIMARY KEY */
  	bool		relhasrules;
  	aclitem		relacl[1];		/* this is here for the catalog */
  } FormData_pg_class;

#define CLASS_TUPLE_SIZE \
! (offsetof(FormData_pg_class,relhasrules) + sizeof(bool))

  /* ----------------
   *		Form_pg_class corresponds to a pointer to a tuple with
--- 78,89 ----
  	int2		relrefs;		/* # of references to this relation */
  	bool		relhaspkey;		/* has PRIMARY KEY */
  	bool		relhasrules;
+ 	bool		relhassubclass;
  	aclitem		relacl[1];		/* this is here for the catalog */
  } FormData_pg_class;

#define CLASS_TUPLE_SIZE \
! (offsetof(FormData_pg_class,relhassubclass) + sizeof(bool))

  /* ----------------
   *		Form_pg_class corresponds to a pointer to a tuple with
***************
*** 102,109 ****
   *		relacl field.
   * ----------------
   */
! #define Natts_pg_class_fixed			18
! #define Natts_pg_class					19
  #define Anum_pg_class_relname			1
  #define Anum_pg_class_reltype			2
  #define Anum_pg_class_relowner			3
--- 103,110 ----
   *		relacl field.
   * ----------------
   */
! #define Natts_pg_class_fixed			19
! #define Natts_pg_class					20
  #define Anum_pg_class_relname			1
  #define Anum_pg_class_reltype			2
  #define Anum_pg_class_relowner			3
***************
*** 122,128 ****
  #define Anum_pg_class_relrefs			16
  #define Anum_pg_class_relhaspkey		17
  #define Anum_pg_class_relhasrules		18
! #define Anum_pg_class_relacl			19

  /* ----------------
   *		initial contents of pg_class
--- 123,130 ----
  #define Anum_pg_class_relrefs			16
  #define Anum_pg_class_relhaspkey		17
  #define Anum_pg_class_relhasrules		18
! #define Anum_pg_class_relhassubclass		19
! #define Anum_pg_class_relacl			20

  /* ----------------
   *		initial contents of pg_class
***************
*** 135,141 ****
  DESCR("");
  DATA(insert OID = 1255 (  pg_proc 81		  PGUID 0 0 0 0 f f r 16 0 0 0 0 0 f f _null_ ));
  DESCR("");
! DATA(insert OID = 1259 (  pg_class 83		  PGUID 0 0 0 0 f f r 19 0 0 0 0 0 f f _null_ ));
  DESCR("");
  DATA(insert OID = 1260 (  pg_shadow 86		  PGUID 0 0 0 0 f t r 8  0 0 0 0 0 f f _null_ ));
  DESCR("");
--- 137,143 ----
  DESCR("");
  DATA(insert OID = 1255 (  pg_proc 81		  PGUID 0 0 0 0 f f r 16 0 0 0 0 0 f f _null_ ));
  DESCR("");
! DATA(insert OID = 1259 (  pg_class 83		  PGUID 0 0 0 0 f f r 20 0 0 0 0 0 f f _null_ ));
  DESCR("");
  DATA(insert OID = 1260 (  pg_shadow 86		  PGUID 0 0 0 0 f t r 8  0 0 0 0 0 f f _null_ ));
  DESCR("");

--------------A7B802EC4868B515DDDB4FFA--

From bouncefilter Fri Feb 4 23:41:59 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA60445
for <hackers@postgreSQL.org>; Fri, 4 Feb 2000 23:41:24 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id UAA16034;
Fri, 4 Feb 2000 20:40:26 -0800 (PST)
Message-Id: <3.0.1.32.20000204203823.01030d30@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 04 Feb 2000 20:38:23 -0800
To: Chris <chris@bitmead.com>, Postgres Hackers List <hackers@postgreSQL.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Patch attached...
In-Reply-To: <389B9ACB.9F929BAE@bitmead.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:36 PM 2/5/00 +1100, Chris wrote:

*) The overhead for non-inheritance has
been cut down to 30 microseconds (on a pc).

What kind of PC? I'm getting 4,000 microseconds doing
simple selects on a classic P200 (no L2 cache) through
AOLserver and Tcl scripts, which probably means more like
2,000 microseconds for PG alone. But without knowing your
PC, I have no way to scale. For instance, my P500e that
I just built gets between 3-6x performance over my P200.

What's an acceptable level for overhead? I have no personal
desire to eat any overhead, in all honesty. 2000/30 < 1%
but without knowledge of the actual PC platform (which certainly
you must know vary widely in performance) I have no way to
scale. If your PC platform is closer to my P500e than my
(classic) P200 (not pro, no L2 cache) then the overhead is
more like 2-3%. That's measurable.

And if SQL92 compliance is the goal, why must ANY degradation
of performance be acceptable unless there are very, very strong
reasons to do so (reasons that impact the target audience).

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Feb 5 00:02:00 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA63790
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 00:01:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA16566;
Sat, 5 Feb 2000 00:00:32 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002050500.AAA16566@candle.pha.pa.us>
Subject: Re: [HACKERS] Patch attached...
In-Reply-To: <3.0.1.32.20000204203823.01030d30@mail.pacifier.com> from Don
Baccus at "Feb 4, 2000 08:38:23 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Sat, 5 Feb 2000 00:00:32 -0500 (EST)
CC: Chris <chris@bitmead.com>, Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

*) The overhead for non-inheritance has
been cut down to 30 microseconds (on a pc).

We actually have to see how you have implemented it. I am not so
interested in timings as in your method. It can be done fast, or it can
be done sloppy. I will check the patch.

And if SQL92 compliance is the goal, why must ANY degradation
of performance be acceptable unless there are very, very strong
reasons to do so (reasons that impact the target audience).

Agreed.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Feb 5 00:06:59 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA67382
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 00:06:21 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA16626;
Sat, 5 Feb 2000 00:05:50 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002050505.AAA16626@candle.pha.pa.us>
Subject: Re: [HACKERS] Patch attached...
In-Reply-To: <389B9ACB.9F929BAE@bitmead.com> from Chris at "Feb 5,
2000 02:36:43 pm"
To: Chris <chris@bitmead.com>
Date: Sat, 5 Feb 2000 00:05:49 -0500 (EST)
CC: Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Attached is a patch for the ONLY inheritance
functionality...

*) It includes a SET compatibility mode.
*) The overhead for non-inheritance has
been cut down to 30 microseconds (on a pc).
*) It needs an initdb.

Comments welcome.

One problem is that you use SearchSysCacheTupleCopy while
SearchSysCacheTuple is more appropriate. You need Copy only when you
are going to be using the cache tuple for an extended period. Looks
like the rest of that particular function is OK.

However, I have received an objection from someone on another issue
related to the patch. There are no documentation changes for that
patch. That includes the SET manual page, and any other place
Inheritance is mentioned. You also need to update
include/catalog/catversion.h because initdb is required.

I will wait for a new patch that has these changes, and any others
mentioned by people. Thanks.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Feb 5 00:08:59 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA67597
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 00:08:05 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA16644;
Sat, 5 Feb 2000 00:07:41 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002050507.AAA16644@candle.pha.pa.us>
Subject: Re: [HACKERS] Patch attached...
In-Reply-To: <389B9ACB.9F929BAE@bitmead.com> from Chris at "Feb 5,
2000 02:36:43 pm"
To: Chris <chris@bitmead.com>
Date: Sat, 5 Feb 2000 00:07:41 -0500 (EST)
CC: Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

FYI the SearchSysCacheTupleCopy call that I was objecting to was in
function has_inheritors. Looks like you clearly are on the right track
with the patch. There is some tricky code in there, and it looks pretty
good.

Attached is a patch for the ONLY inheritance
functionality...

*) It includes a SET compatibility mode.
*) The overhead for non-inheritance has
been cut down to 30 microseconds (on a pc).
*) It needs an initdb.

Comments welcome.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Feb 5 01:00:00 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA83228
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 00:59:58 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id QAA22091;
Sat, 5 Feb 2000 16:59:48 +1100
Sender: chris@tech.com.au
Message-ID: <389BBC52.7FBAED10@bitmead.com>
Date: Sat, 05 Feb 2000 16:59:46 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Patch attached...
References: <3.0.1.32.20000204203823.01030d30@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

At 02:36 PM 2/5/00 +1100, Chris wrote:

*) The overhead for non-inheritance has
been cut down to 30 microseconds (on a pc).

What kind of PC?

Cerelon 400, 64MB, IDE disk.

--
Chris Bitmead
mailto:chris@bitmead.com

From bouncefilter Sat Feb 5 03:36:02 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA67382
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 03:34:47 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id TAA22870
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 19:32:56 +1100
Sender: chris@tech.com.au
Message-ID: <389BE038.72172703@bitmead.com>
Date: Sat, 05 Feb 2000 19:32:56 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: New Improved Patch
References: <200002050505.AAA16626@candle.pha.pa.us>
Content-Type: multipart/mixed; boundary="------------246A7F2DAD82630755FAC9D1"

This is a multi-part message in MIME format.
--------------246A7F2DAD82630755FAC9D1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks Bruce! That suggestion with SearchSysCacheTuple makes a big
difference! I am no longer able to measure ANY performance difference
between inherited and non-inherited while doing one million queries.

Attached is a patch that incorporates your suggestions.
--------------246A7F2DAD82630755FAC9D1
Content-Type: text/plain; charset=us-ascii;
name="patch.only"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="patch.only"

? pgsql/src/config.log
? pgsql/src/config.cache
? pgsql/src/config.status
? pgsql/src/GNUmakefile
? pgsql/src/Makefile.global
? pgsql/src/backend/fmgr.h
? pgsql/src/backend/parse.h
? pgsql/src/backend/postgres
? pgsql/src/backend/global1.bki.source
? pgsql/src/backend/local1_template1.bki.source
? pgsql/src/backend/global1.description
? pgsql/src/backend/local1_template1.description
? pgsql/src/backend/1
? pgsql/src/backend/catalog/genbki.sh
? pgsql/src/backend/catalog/global1.bki.source
? pgsql/src/backend/catalog/global1.description
? pgsql/src/backend/catalog/local1_template1.bki.source
? pgsql/src/backend/catalog/local1_template1.description
? pgsql/src/backend/port/Makefile
? pgsql/src/backend/utils/Gen_fmgrtab.sh
? pgsql/src/backend/utils/fmgr.h
? pgsql/src/backend/utils/fmgrtab.c
? pgsql/src/bin/initdb/initdb
? pgsql/src/bin/initlocation/initlocation
? pgsql/src/bin/ipcclean/ipcclean
? pgsql/src/bin/pg_ctl/pg_ctl
? pgsql/src/bin/pg_dump/Makefile
? pgsql/src/bin/pg_dump/pg_dump
? pgsql/src/bin/pg_id/pg_id
? pgsql/src/bin/pg_passwd/pg_passwd
? pgsql/src/bin/pg_version/Makefile
? pgsql/src/bin/pg_version/pg_version
? pgsql/src/bin/pgtclsh/mkMakefile.tcldefs.sh
? pgsql/src/bin/pgtclsh/mkMakefile.tkdefs.sh
? pgsql/src/bin/psql/Makefile
? pgsql/src/bin/psql/psql
? pgsql/src/bin/scripts/createlang
? pgsql/src/include/version.h
? pgsql/src/include/config.h
? pgsql/src/interfaces/ecpg/lib/Makefile
? pgsql/src/interfaces/ecpg/lib/libecpg.so.3.0.10
? pgsql/src/interfaces/ecpg/preproc/ecpg
? pgsql/src/interfaces/libpgeasy/Makefile
? pgsql/src/interfaces/libpgeasy/libpgeasy.so.2.1
? pgsql/src/interfaces/libpgtcl/Makefile
? pgsql/src/interfaces/libpq/Makefile
? pgsql/src/interfaces/libpq/libpq.so.2.1
? pgsql/src/interfaces/libpq++/Makefile
? pgsql/src/interfaces/libpq++/libpq++.so.3.1
? pgsql/src/interfaces/odbc/GNUmakefile
? pgsql/src/interfaces/odbc/Makefile.global
? pgsql/src/pl/plpgsql/src/Makefile
? pgsql/src/pl/plpgsql/src/mklang.sql
? pgsql/src/pl/plpgsql/src/libplpgsql.so.1.0
? pgsql/src/pl/tcl/mkMakefile.tcldefs.sh
? pgsql/src/test/regress/GNUmakefile
Index: pgsql/doc/src/sgml/advanced.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/advanced.sgml,v
retrieving revision 1.7
diff -c -r1.7 advanced.sgml
*** pgsql/doc/src/sgml/advanced.sgml	1999/10/04 15:18:53	1.7
--- pgsql/doc/src/sgml/advanced.sgml	2000/02/05 08:24:35
***************
*** 56,93 ****
       </para>
      </note>

! For example, the following query finds
! all the cities that are situated at an attitude of 500ft or higher:
!
! <programlisting>
! SELECT name, altitude
! FROM cities
! WHERE altitude &gt; 500;

+----------+----------+
|name | altitude |
+----------+----------+
|Las Vegas | 2174 |
+----------+----------+
|Mariposa | 1953 |
+----------+----------+
! </programlisting>
! </para>

! <para>
! On the other hand, to find the names of all cities,
! including state capitals, that are located at an altitude
! over 500ft, the query is:
!
! <programlisting>
! SELECT c.name, c.altitude
! FROM cities* c
! WHERE c.altitude > 500;
! </programlisting>

-     which returns:
-      
-     <programlisting>
  +----------+----------+
  |name      | altitude |
  +----------+----------+
--- 56,97 ----
       </para>
      </note>

! <para>
! For example, the following query finds the names of all cities,
! including state capitals, that are located at an altitude
! over 500ft, the query is:
!
! <programlisting>
! SELECT c.name, c.altitude
! FROM cities c
! WHERE c.altitude > 500;
! </programlisting>

+    which returns:
+ 
+    <programlisting>
  +----------+----------+
  |name      | altitude |
  +----------+----------+
  |Las Vegas | 2174     |
  +----------+----------+
  |Mariposa  | 1953     |
+ +----------+----------+
+ |Madison   | 845      |
  +----------+----------+
!    </programlisting>
!   </para>

! <para>
! On the other hand, the following query finds
! all the cities, but not capital cities
! that are situated at an attitude of 500ft or higher:
!
! <programlisting>
! SELECT name, altitude
! FROM ONLY cities
! WHERE altitude &gt; 500;

+----------+----------+
|name | altitude |
+----------+----------+
***************
*** 95,112 ****
+----------+----------+
|Mariposa | 1953 |
+----------+----------+
! |Madison | 845 |
! +----------+----------+
! </programlisting>

! Here the <quote>*</quote> after cities indicates that the query should
! be run over cities and all classes below cities in the
! inheritance hierarchy. Many of the commands that we
! have already discussed (<command>select</command>,
! <command>and>up</command>and> and <command>delete</command>)
! support this <quote>*</quote> notation, as do others, like
! <command>alter</command>.
! </para>
</sect1>

    <sect1>
--- 99,129 ----
  +----------+----------+
  |Mariposa  | 1953     |
  +----------+----------+
!    </programlisting>         
!   </para>
! 

! Here the <quote>ONLY</quote> before cities indicates that the query should
! be run over only cities and not classes below cities in the
! inheritance hierarchy. Many of the commands that we
! have already discussed -- <command>SELECT</command>,
! <command>UPDATE</command> and <command>DELETE</command> --
! support this <quote>ONLY</quote> notation, as do others, like
! <command>ALTER TABLE</command>.
! </para>
! <para>
! Deprecated: In previous versions of postgres, the default was not to
! get access to child classes. By experience this was found to be error
! prone. Under the old syntax, to get the sub-classes you append "*"
! to the table name. For example
! <programlisting>
! SELECT * from cities*;
! </programlisting>
! This old behaviour is still available by using a SET command...
! <programlisting>
! SET EXAMINE_SUBCLASS TO 'on';
! </programlisting>
! </para>
</sect1>

    <sect1>
Index: pgsql/doc/src/sgml/catalogs.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v
retrieving revision 2.3
diff -c -r2.3 catalogs.sgml
*** pgsql/doc/src/sgml/catalogs.sgml	2000/01/22 23:50:08	2.3
--- pgsql/doc/src/sgml/catalogs.sgml	2000/02/05 08:24:37
***************
*** 192,197 ****
--- 192,199 ----
  			   2=main memory */
       int2vector relkey		/* - unused */
       oidvector  relkeyop	/* - unused */
+      bool       relhassubclass	/* does the class have a subclass?
+ 				    */
       aclitem    relacl[1]	/* access control lists */
  .fi
  .nf M
Index: pgsql/doc/src/sgml/inherit.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v
retrieving revision 1.4
diff -c -r1.4 inherit.sgml
*** pgsql/doc/src/sgml/inherit.sgml	1999/08/08 04:21:33	1.4
--- pgsql/doc/src/sgml/inherit.sgml	2000/02/05 08:24:37
***************
*** 37,50 ****
      </para>
     </note>

! For example, the following query finds
! all the cities that are situated at an attitude of 500ft or higher:

<programlisting>
! SELECT name, altitude
! FROM cities
! WHERE altitude &gt; 500;

  +----------+----------+
  |name      | altitude |
  +----------+----------+
--- 37,56 ----
      </para>
     </note>

! <para>
! For example, the following query finds the names of all cities,
! including state capitals, that are located at an altitude
! over 500ft, the query is:

<programlisting>
! SELECT c.name, c.altitude
! FROM cities c
! WHERE c.altitude > 500;
! </programlisting>
!
! which returns:

+ <programlisting>
+----------+----------+
|name | altitude |
+----------+----------+
***************
*** 52,92 ****
+----------+----------+
|Mariposa | 1953 |
+----------+----------+
! </programlisting>
</para>

<para>
! On the other hand, to find the names of all cities,
! including state capitals, that are located at an altitude
! over 500ft, the query is:

<programlisting>
! SELECT c.name, c.altitude
! FROM cities* c
! WHERE c.altitude > 500;
! </programlisting>
!
! which returns:

-    <programlisting>
  +----------+----------+
  |name      | altitude |
  +----------+----------+
  |Las Vegas | 2174     |
  +----------+----------+
  |Mariposa  | 1953     |
- +----------+----------+
- |Madison   | 845      |
  +----------+----------+
!    </programlisting>

! Here the <quote>*</quote> after cities indicates that the query should
! be run over cities and all classes below cities in the
inheritance hierarchy. Many of the commands that we
have already discussed -- <command>SELECT</command>,
<command>UPDATE</command> and <command>DELETE</command> --
! support this <quote>*</quote> notation, as do others, like
<command>ALTER TABLE</command>.
</para>
</chapter>

--- 58,109 ----
  +----------+----------+
  |Mariposa  | 1953     |
  +----------+----------+
! |Madison   | 845      |
! +----------+----------+
!    </programlisting>
    </para>

<para>
! On the other hand, the following query finds
! all the cities, but not capital cities
! that are situated at an attitude of 500ft or higher:

<programlisting>
! SELECT name, altitude
! FROM ONLY cities
! WHERE altitude &gt; 500;

+----------+----------+
|name | altitude |
+----------+----------+
|Las Vegas | 2174 |
+----------+----------+
|Mariposa | 1953 |
+----------+----------+
! </programlisting>
! </para>

! 
!    Here the <quote>ONLY</quote> before cities indicates that the query should
!    be  run over only cities and not classes below cities in the
     inheritance hierarchy.  Many of the  commands  that  we
     have  already discussed -- <command>SELECT</command>,
     <command>UPDATE</command> and <command>DELETE</command> --
!    support this <quote>ONLY</quote> notation, as do others, like
     <command>ALTER TABLE</command>.
+   </para>
+   <para>
+   Deprecated: In previous versions of postgres, the default was not to
+   get access to child classes. By experience this was found to be error
+   prone. Under the old syntax, to get the sub-classes you append "*"
+   to the table name. For example
+    <programlisting>
+    SELECT * from cities*;
+    </programlisting>     
+    This old behaviour is still available by using a SET command...    
+    <programlisting>
+    SET EXAMINE_SUBCLASS TO 'on';
+    </programlisting>     
    </para>
   </chapter>

Index: pgsql/doc/src/sgml/ref/alter_table.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/alter_table.sgml,v
retrieving revision 1.10
diff -c -r1.10 alter_table.sgml
*** pgsql/doc/src/sgml/ref/alter_table.sgml	2000/01/29 16:58:27	1.10
--- pgsql/doc/src/sgml/ref/alter_table.sgml	2000/02/05 08:24:38
***************
*** 23,35 ****
     <date>1999-07-20</date>
    </refsynopsisdivinfo>
    <synopsis>
! ALTER TABLE <replaceable class="PARAMETER">table</replaceable> [ * ]
      ADD [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> <replaceable
      class="PARAMETER">type</replaceable>
! ALTER TABLE <replaceable class="PARAMETER">table</replaceable> [ * ]
      ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> { SET DEFAULT <replaceable
      class="PARAMETER">value</replaceable> | DROP DEFAULT }
! ALTER TABLE <replaceable class="PARAMETER">table</replaceable> [ * ]
      RENAME [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> TO <replaceable
      class="PARAMETER">newcolumn</replaceable>
  ALTER TABLE <replaceable class="PARAMETER">table</replaceable>
--- 23,35 ----
     <date>1999-07-20</date>
    </refsynopsisdivinfo>
    <synopsis>
! ALTER TABLE [ ONLY ]<replaceable class="PARAMETER">table</replaceable> [ * ]
      ADD [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> <replaceable
      class="PARAMETER">type</replaceable>
! ALTER TABLE [ ONLY ]<replaceable class="PARAMETER">table</replaceable> [ * ]
      ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> { SET DEFAULT <replaceable
      class="PARAMETER">value</replaceable> | DROP DEFAULT }
! ALTER TABLE [ ONLY ]<replaceable class="PARAMETER">table</replaceable> [ * ]
      RENAME [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> TO <replaceable
      class="PARAMETER">newcolumn</replaceable>
  ALTER TABLE <replaceable class="PARAMETER">table</replaceable>
***************
*** 162,178 ****
     </para>

<para>
! <quote>*</quote> following a name of a table indicates that the statement
! should be run over that table and all tables below it in the
inheritance hierarchy;
! by default, the attribute will not be added to or renamed in any of the subclasses.

! This should always be done when adding or modifying an attribute in a
! superclass. If it is not, queries on the inheritance hierarchy
such as

<programlisting>
! SELECT <replaceable>NewColumn</replaceable> FROM <replaceable>SuperClass</replaceable>*
</programlisting>

      will not work because the subclasses will be missing an attribute
--- 162,178 ----
     </para>

<para>
! <quote>ONLY</quote> preceeding the name of a table indicates that the statement
! should be run over only that table and not tables below it in the
inheritance hierarchy;
! by default, the attribute will be added to or renamed in any of the subclasses.

! It is recommended to never use the ONLY feature however.
! If it is, queries on the inheritance hierarchy
such as

<programlisting>
! SELECT <replaceable>NewColumn</replaceable> FROM <replaceable>SuperClass</replaceable>
</programlisting>

      will not work because the subclasses will be missing an attribute
Index: pgsql/doc/src/sgml/ref/select.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v
retrieving revision 1.24
diff -c -r1.24 select.sgml
*** pgsql/doc/src/sgml/ref/select.sgml	2000/01/27 18:11:25	1.24
--- pgsql/doc/src/sgml/ref/select.sgml	2000/02/05 08:24:40
***************
*** 25,31 ****
  SELECT [ ALL | DISTINCT [ ON ( <replaceable class="PARAMETER">expression</replaceable> [, ...] ) ] ]
      <replaceable class="PARAMETER">expression</replaceable> [ AS <replaceable class="PARAMETER">name</replaceable> ] [, ...]
      [ INTO [ TEMPORARY | TEMP ] [ TABLE ] <replaceable class="PARAMETER">new_table</replaceable> ]
!     [ FROM <replaceable class="PARAMETER">table</replaceable> [ <replaceable class="PARAMETER">alias</replaceable> ] [, ...] ]
      [ WHERE <replaceable class="PARAMETER">condition</replaceable> ]
      [ GROUP BY <replaceable class="PARAMETER">column</replaceable> [, ...] ]
      [ HAVING <replaceable class="PARAMETER">condition</replaceable> [, ...] ]
--- 25,31 ----
  SELECT [ ALL | DISTINCT [ ON ( <replaceable class="PARAMETER">expression</replaceable> [, ...] ) ] ]
      <replaceable class="PARAMETER">expression</replaceable> [ AS <replaceable class="PARAMETER">name</replaceable> ] [, ...]
      [ INTO [ TEMPORARY | TEMP ] [ TABLE ] <replaceable class="PARAMETER">new_table</replaceable> ]
!     [ FROM [ ONLY ]<replaceable class="PARAMETER">table</replaceable> [ <replaceable class="PARAMETER">alias</replaceable> ] [, ...] ]
      [ WHERE <replaceable class="PARAMETER">condition</replaceable> ]
      [ GROUP BY <replaceable class="PARAMETER">column</replaceable> [, ...] ]
      [ HAVING <replaceable class="PARAMETER">condition</replaceable> [, ...] ]
***************
*** 198,203 ****
--- 198,210 ----
     Candidates for selection are rows which satisfy the WHERE condition;
     if WHERE is omitted, all rows are candidates.
     (See <xref linkend="sql-where" endterm="sql-where-title">.)
+   </para>
+   <para>
+   <command>ONLY</command> will eliminate rows from subclasses of the table.
+   This was previously the default result, and getting subclasses was
+   obtained by appending <command>*</command> to the table name.
+   The old behaviour is available via the command 
+   <command>SET EXAMINE_SUBCLASS TO 'on';</command>
    </para>

    <para>
Index: pgsql/doc/src/sgml/ref/set.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/set.sgml,v
retrieving revision 1.28
diff -c -r1.28 set.sgml
*** pgsql/doc/src/sgml/ref/set.sgml	1999/07/22 15:09:15	1.28
--- pgsql/doc/src/sgml/ref/set.sgml	2000/02/05 08:24:41
***************
*** 443,448 ****
--- 443,482 ----
  	  </listitem>
  	 </varlistentry>

+      <varlistentry>
+       <term>EXAMINE_SUBCLASS</term>
+       <listitem>
+        <para>
+ 	Sets the inheritance query syntax to the traditional postgres style.
+ 	
+ 	<variablelist>
+ 	 <varlistentry>
+ 	  <term><replaceable class="parameter">OFF</replaceable></term>
+ 	  <listitem>
+ 	   <para>
+        Changes the behaviour of SELECT so that it no longer automatically
+        examines sub-classes. (See SELECT). By default a SELECT on a table
+        will also return subclass tuples unless specifying ONLY tablename.
+        Setting this returns postgres to the traditional behaviour of
+        only returning subclasses when appending "*" to the tablename.
+ 	   </para>
+ 	  </listitem>
+ 	 </varlistentry>
+ 	 
+ 	 <varlistentry>
+ 	  <term>ON</term>
+ 	  <listitem>
+ 	   <para>
+        Returns SELECT to the behaviour of automatically returning
+        results from sub-classes.
+ 	   </para>
+ 	  </listitem>
+ 	 </varlistentry>
+ 	</variablelist>
+        </para>
+       </listitem>
+      </varlistentry>
+ 
  	 <varlistentry>
  	  <term>OFF</term>
  	  <listitem>
Index: pgsql/src/backend/commands/creatinh.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/commands/creatinh.c,v
retrieving revision 1.56
diff -c -r1.56 creatinh.c
*** pgsql/src/backend/commands/creatinh.c	2000/01/29 16:58:34	1.56
--- pgsql/src/backend/commands/creatinh.c	2000/02/05 08:24:44
***************
*** 35,40 ****
--- 35,43 ----
                              const char *attributeType, List *schema);
  static List *MergeAttributes(List *schema, List *supers, List **supconstr);
  static void StoreCatalogInheritance(Oid relationId, List *supers);
+ static void
+ setRelhassubclassInRelation(Oid relationId, bool relhassubclass);
+ 

  /* ----------------------------------------------------------------
   *		DefineRelation
***************
*** 323,328 ****
--- 326,332 ----
  		TupleConstr *constr;

relation = heap_openr(name, AccessShareLock);
+ setRelhassubclassInRelation(relation->rd_id, true);
tupleDesc = RelationGetDescr(relation);
constr = tupleDesc->constr;

***************
*** 655,657 ****
--- 659,698 ----
  	}
  	return false;
  }
+ 
+ 
+ static void
+ setRelhassubclassInRelation(Oid relationId, bool relhassubclass)
+ {
+         Relation        relationRelation;
+         HeapTuple       tuple;
+         Relation        idescs[Num_pg_class_indices];
+ 
+         /*
+          * Lock a relation given its Oid. Go to the RelationRelation (i.e.
+          * pg_relation), find the appropriate tuple, and add the specified
+          * lock to it.
+          */
+         relationRelation = heap_openr(RelationRelationName, RowExclusiveLock);
+         tuple = SearchSysCacheTuple(RELOID,
+                                     ObjectIdGetDatum(relationId),
+                                     0, 0, 0)
+ ;
+         Assert(HeapTupleIsValid(tuple));
+ 
+         ((Form_pg_class) GETSTRUCT(tuple))->relhassubclass = relhassubclass;
+         heap_update(relationRelation, &tuple->t_self, tuple, NULL);
+ 
+         /* keep the catalog indices up to date */
+         CatalogOpenIndices(Num_pg_class_indices, Name_pg_class_indices, idescs);
+         CatalogIndexInsert(idescs, Num_pg_class_indices, relationRelation, tuple
+ );
+         CatalogCloseIndices(Num_pg_class_indices, idescs);
+ 
+         /*        heap_freetuple(tuple); */
+         heap_close(relationRelation, RowExclusiveLock);
+ }
+ 
+ 
+ 
+ 
Index: pgsql/src/backend/commands/variable.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/commands/variable.c,v
retrieving revision 1.28
diff -c -r1.28 variable.c
*** pgsql/src/backend/commands/variable.c	2000/01/22 23:50:10	1.28
--- pgsql/src/backend/commands/variable.c	2000/02/05 08:24:45
***************
*** 48,53 ****
--- 48,56 ----

extern bool _use_keyset_query_optimizer;

+ #define examine_subclass_default true
+ bool examine_subclass = examine_subclass_default;
+ 
  /*
   *
   * Get_Token
***************
*** 228,233 ****
--- 231,274 ----
  	geqo_rels = GEQO_RELS;
  	return TRUE;
  }
+ /*
+  *
+  * EXAMINE_SUBCLASS
+  *
+  */
+ #define EXAMINE_SUBCLASS "EXAMINE_SUBCLASS"
+ 
+ static bool
+ parse_examine_subclass(const char *value)
+ {
+     if (strcasecmp(value, "on") == 0)
+         examine_subclass = true;
+     else if (strcasecmp(value, "off") == 0)
+         examine_subclass = false;
+     else if (strcasecmp(value, "default") == 0) 
+         examine_subclass = examine_subclass_default;
+ 	else
+ 		elog(ERROR, "Bad value for %s (%s)", EXAMINE_SUBCLASS, value);
+ 	return TRUE;
+ }
+ 
+ static bool
+ show_examine_subclass()
+ {
+     
+ 	if (examine_subclass)
+ 		elog(NOTICE, "%s is ON", EXAMINE_SUBCLASS);
+ 	else
+ 		elog(NOTICE, "%s is OFF", EXAMINE_SUBCLASS);
+ 	return TRUE;
+ }
+ 
+ static bool
+ reset_examine_subclass(void)
+ {
+     examine_subclass = examine_subclass_default;
+ 	return TRUE;
+ }

  /*
   *
***************
*** 600,605 ****
--- 641,649 ----
  	{
  		"pg_options", parse_pg_options, show_pg_options, reset_pg_options
  	},
+     {
+ 		EXAMINE_SUBCLASS, parse_examine_subclass, show_examine_subclass, reset_examine_subclass
+     },
  	{
  		NULL, NULL, NULL, NULL
  	}
Index: pgsql/src/backend/optimizer/plan/planner.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v
retrieving revision 1.74
diff -c -r1.74 planner.c
*** pgsql/src/backend/optimizer/plan/planner.c	2000/01/27 18:11:31	1.74
--- pgsql/src/backend/optimizer/plan/planner.c	2000/02/05 08:24:48
***************
*** 35,40 ****
--- 35,41 ----
  #include "utils/builtins.h"
  #include "utils/lsyscache.h"
  #include "utils/syscache.h"
+ #include "parser/parsetree.h"

static List *make_subplanTargetList(Query *parse, List *tlist,
AttrNumber **groupColIdx);
***************
*** 140,146 ****
* to change interface to plan_union_queries to pass that info back!
*/
}
! else if ((rt_index = first_inherit_rt_entry(rangetable)) != -1)
{
List *sub_tlist;

--- 141,147 ----
  		 * to change interface to plan_union_queries to pass that info back!
  		 */
  	}
! 	else if ((rt_index = first_inherit_rt_entry(rangetable)) != -1 && has_inheritors(rt_fetch(rt_index, parse->rtable)->relid))
  	{
  		List	   *sub_tlist;

Index: pgsql/src/backend/optimizer/prep/prepunion.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/optimizer/prep/prepunion.c,v
retrieving revision 1.43
diff -c -r1.43 prepunion.c
*** pgsql/src/backend/optimizer/prep/prepunion.c	2000/02/03 06:12:19	1.43
--- pgsql/src/backend/optimizer/prep/prepunion.c	2000/02/05 08:24:49
***************
*** 25,30 ****
--- 25,33 ----
  #include "parser/parse_clause.h"
  #include "parser/parsetree.h"
  #include "utils/lsyscache.h"
+ #include "access/heapam.h"
+ #include "catalog/catname.h"
+ #include "utils/syscache.h"

  typedef struct {
  	Index		rt_index;
***************
*** 45,50 ****
--- 48,54 ----
  static Append *make_append(List *appendplans, List *unionrtables,
  						   Index rt_index,
  						   List *inheritrtable, List *tlist);
+ bool has_inheritors(Oid relationId);

  /*
***************
*** 352,357 ****
--- 356,386 ----

  	*union_rtentriesPtr = union_rtentries;
  	return union_plans;
+ }
+ 
+ bool has_inheritors(Oid relationId)
+ {
+         bool rtn;
+         Relation        relationRelation;
+         HeapTuple       tuple;
+ 
+         /*
+          * Lock a relation given its Oid. Go to the RelationRelation (i.e.
+          * pg_relation), find the appropriate tuple, and add the specified
+          * lock to it.
+          */
+         relationRelation = heap_openr(RelationRelationName, NoLock);
+         tuple = SearchSysCacheTuple(RELOID,
+                                  ObjectIdGetDatum(relationId),
+                                  0, 0, 0)
+ ;
+ /*        Assert(HeapTupleIsValid(tuple)); */
+ 
+         rtn = ((Form_pg_class) GETSTRUCT(tuple))->relhassubclass;
+ 
+         /*         heap_freetuple(tuple); */
+         heap_close(relationRelation, NoLock);
+         return rtn;
  }

  /*
Index: pgsql/src/backend/parser/gram.y
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.139
diff -c -r2.139 gram.y
*** pgsql/src/backend/parser/gram.y	2000/02/04 18:49:33	2.139
--- pgsql/src/backend/parser/gram.y	2000/02/05 08:25:00
***************
*** 811,868 ****

AlterTableStmt:
/* ALTER TABLE <name> ADD [COLUMN] <coldef> */
ALTER TABLE relation_name opt_inh_star ADD opt_column columnDef
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'A';
n->relname = $3;
! n->inh = $4;
n->def = $7;
$$ = (Node *)n;
}
/* ALTER TABLE <name> ALTER [COLUMN] <colname> {SET DEFAULT <expr>|DROP DEFAULT} */
| ALTER TABLE relation_name opt_inh_star ALTER opt_column ColId alter_column_action
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'T';
n->relname = $3;
! n->inh = $4;
n->name = $7;
n->def = $8;
$$ = (Node *)n;
}
/* ALTER TABLE <name> DROP [COLUMN] <name> {RESTRICT|CASCADE} */
| ALTER TABLE relation_name opt_inh_star DROP opt_column ColId drop_behavior
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'D';
n->relname = $3;
! n->inh = $4;
n->name = $7;
n->behavior = $8;
$$ = (Node *)n;
}
/* ALTER TABLE <name> ADD CONSTRAINT ... */
| ALTER TABLE relation_name opt_inh_star ADD TableConstraint
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'C';
n->relname = $3;
! n->inh = $4;
n->def = $6;
$$ = (Node *)n;
}
/* ALTER TABLE <name> DROP CONSTRAINT <name> {RESTRICT|CASCADE} */
| ALTER TABLE relation_name opt_inh_star DROP CONSTRAINT name drop_behavior
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'X';
n->relname = $3;
! n->inh = $4;
n->name = $7;
n->behavior = $8;
$$ = (Node *)n;
}
;

  alter_column_action:
--- 811,926 ----

  AlterTableStmt:
  /* ALTER TABLE <name> ADD [COLUMN] <coldef> */
+         /* "*" deprecated */
          ALTER TABLE relation_name opt_inh_star ADD opt_column columnDef
  	{
+         extern bool examine_subclass;
  		AlterTableStmt *n = makeNode(AlterTableStmt);
                  n->subtype = 'A';
  		n->relname = $3;
! 		n->inh = $4 || examine_subclass;
  		n->def = $7;
  		$$ = (Node *)n;
  	}
+     |    ALTER TABLE ONLY relation_name ADD opt_column columnDef
+ 	{
+ 		AlterTableStmt *n = makeNode(AlterTableStmt);
+                 n->subtype = 'A';
+ 		n->relname = $4;
+ 		n->inh = FALSE;
+ 		n->def = $7;
+ 		$$ = (Node *)n;
+ 	}
  /* ALTER TABLE <name> ALTER [COLUMN] <colname> {SET DEFAULT <expr>|DROP DEFAULT} */
+         /* "*" deprecated */
        | ALTER TABLE relation_name opt_inh_star ALTER opt_column ColId alter_column_action
          {
+         extern bool examine_subclass;
                  AlterTableStmt *n = makeNode(AlterTableStmt);
                  n->subtype = 'T';
                  n->relname = $3;
!                 n->inh = $4 || examine_subclass;
                  n->name = $7;
                  n->def = $8;
                  $$ = (Node *)n;
          }
+       | ALTER TABLE ONLY relation_name ALTER opt_column ColId alter_column_action
+         {
+                 AlterTableStmt *n = makeNode(AlterTableStmt);
+                 n->subtype = 'T';
+                 n->relname = $4;
+                 n->inh = FALSE;
+                 n->name = $7;
+                 n->def = $8;
+                 $$ = (Node *)n;
+         }
  /* ALTER TABLE <name> DROP [COLUMN] <name> {RESTRICT|CASCADE} */
+         /* "*" deprecated */
        | ALTER TABLE relation_name opt_inh_star DROP opt_column ColId drop_behavior
          {
+         extern bool examine_subclass;
                  AlterTableStmt *n = makeNode(AlterTableStmt);
                  n->subtype = 'D';
                  n->relname = $3;
!                 n->inh = $4 || examine_subclass;
                  n->name = $7;
                  n->behavior = $8;
                  $$ = (Node *)n;
          }
+       | ALTER TABLE ONLY relation_name DROP opt_column ColId drop_behavior
+         {
+                 AlterTableStmt *n = makeNode(AlterTableStmt);
+                 n->subtype = 'D';
+                 n->relname = $4;
+                 n->inh = FALSE;
+                 n->name = $7;
+                 n->behavior = $8;
+                 $$ = (Node *)n;
+         }
  /* ALTER TABLE <name> ADD CONSTRAINT ... */
+         /* "*" deprecated */
        | ALTER TABLE relation_name opt_inh_star ADD TableConstraint
          {
+         extern bool examine_subclass;
                  AlterTableStmt *n = makeNode(AlterTableStmt);
                  n->subtype = 'C';
                  n->relname = $3;
!                 n->inh = $4 || examine_subclass;
                  n->def = $6;
                  $$ = (Node *)n;
          }
+       | ALTER TABLE ONLY relation_name ADD TableConstraint
+         {
+                 AlterTableStmt *n = makeNode(AlterTableStmt);
+                 n->subtype = 'C';
+                 n->relname = $4;
+                 n->inh = FALSE;
+                 n->def = $6;
+                 $$ = (Node *)n;
+         }
  /* ALTER TABLE <name> DROP CONSTRAINT <name> {RESTRICT|CASCADE} */
+         /* "*" deprecated */
        | ALTER TABLE relation_name opt_inh_star DROP CONSTRAINT name drop_behavior
          {
+         extern bool examine_subclass;
                  AlterTableStmt *n = makeNode(AlterTableStmt);
                  n->subtype = 'X';
                  n->relname = $3;
!                 n->inh = $4 || examine_subclass;
                  n->name = $7;
                  n->behavior = $8;
                  $$ = (Node *)n;
          }
+       | ALTER TABLE ONLY relation_name DROP CONSTRAINT name drop_behavior
+         {
+                 AlterTableStmt *n = makeNode(AlterTableStmt);
+                 n->subtype = 'X';
+                 n->relname = $4;
+                 n->inh = FALSE;
+                 n->name = $7;
+                 n->behavior = $8;
+                 $$ = (Node *)n;
+         }
          ;

alter_column_action:
***************
*** 2380,2390 ****
*****************************************************************************/

  RenameStmt:  ALTER TABLE relation_name opt_inh_star
  				  RENAME opt_column opt_name TO name
  				{
  					RenameStmt *n = makeNode(RenameStmt);
  					n->relname = $3;
! 					n->inh = $4;
  					n->column = $7;
  					n->newname = $9;
  					$$ = (Node *)n;
--- 2438,2460 ----
   *****************************************************************************/

  RenameStmt:  ALTER TABLE relation_name opt_inh_star
+         /* "*" deprecated */
  				  RENAME opt_column opt_name TO name
  				{
+                     extern bool examine_subclass;
  					RenameStmt *n = makeNode(RenameStmt);
  					n->relname = $3;
! 					n->inh = $4 || examine_subclass;
! 					n->column = $7;
! 					n->newname = $9;
! 					$$ = (Node *)n;
! 				}
!       | ALTER TABLE ONLY relation_name
! 				  RENAME opt_column opt_name TO name
! 				{
! 					RenameStmt *n = makeNode(RenameStmt);
! 					n->relname = $4;
! 					n->inh = FALSE;
  					n->column = $7;
  					n->newname = $9;
  					$$ = (Node *)n;
***************
*** 3553,3562 ****

  relation_expr:	relation_name
  				{
! 					/* normal relations */
  					$$ = makeNode(RelExpr);
  					$$->relname = $1;
! 					$$->inh = FALSE;
  				}
  		| relation_name '*'				  %prec '='
  				{
--- 3623,3633 ----

  relation_expr:	relation_name
  				{
!     				/* default inheritance */
!                     extern bool examine_subclass;
  					$$ = makeNode(RelExpr);
  					$$->relname = $1;
! 					$$->inh = examine_subclass;
  				}
  		| relation_name '*'				  %prec '='
  				{
***************
*** 3565,3570 ****
--- 3636,3648 ----
  					$$->relname = $1;
  					$$->inh = TRUE;
  				}
+         | ONLY relation_name
+                 {
+ 					/* no inheritance */
+ 					$$ = makeNode(RelExpr);
+ 					$$->relname = $2;
+ 					$$->inh = FALSE;
+                 }

  opt_array_bounds:	'[' ']' opt_array_bounds
  				{  $$ = lcons(makeInteger(-1), $3); }
Index: pgsql/src/include/catalog/catversion.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/include/catalog/catversion.h,v
retrieving revision 1.13
diff -c -r1.13 catversion.h
*** pgsql/src/include/catalog/catversion.h	2000/01/27 18:11:40	1.13
--- pgsql/src/include/catalog/catversion.h	2000/02/05 08:25:05
***************
*** 53,58 ****
   */

/* yyyymmddN */
! #define CATALOG_VERSION_NO 200001271

  #endif
--- 53,58 ----
   */

/* yyyymmddN */
! #define CATALOG_VERSION_NO 200002050

  #endif
Index: pgsql/src/include/catalog/pg_attribute.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/include/catalog/pg_attribute.h,v
retrieving revision 1.53
diff -c -r1.53 pg_attribute.h
*** pgsql/src/include/catalog/pg_attribute.h	2000/01/26 05:57:57	1.53
--- pgsql/src/include/catalog/pg_attribute.h	2000/02/05 08:25:09
***************
*** 402,408 ****
  { 1259, {"relrefs"},	   21, 0,	2, 16, 0, -1, -1, '\001', 'p', '\0', 's', '\0', '\0' }, \
  { 1259, {"relhaspkey"},    16, 0,	1, 17, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
  { 1259, {"relhasrules"},   16, 0,	1, 18, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
! { 1259, {"relacl"},		 1034, 0,  -1, 19, 0, -1, -1,	'\0', 'p', '\0', 'i', '\0', '\0' }

  DATA(insert OID = 0 ( 1259 relname			19 0 NAMEDATALEN   1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 reltype			26 0  4   2 0 -1 -1 t p f i f f));
--- 402,409 ----
  { 1259, {"relrefs"},	   21, 0,	2, 16, 0, -1, -1, '\001', 'p', '\0', 's', '\0', '\0' }, \
  { 1259, {"relhaspkey"},    16, 0,	1, 17, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
  { 1259, {"relhasrules"},   16, 0,	1, 18, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
! { 1259, {"relhassubclass"},16, 0,	1, 19, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
! { 1259, {"relacl"},		 1034, 0,  -1, 20, 0, -1, -1,	'\0', 'p', '\0', 'i', '\0', '\0' }

  DATA(insert OID = 0 ( 1259 relname			19 0 NAMEDATALEN   1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 reltype			26 0  4   2 0 -1 -1 t p f i f f));
***************
*** 422,428 ****
  DATA(insert OID = 0 ( 1259 relrefs			21 0  2  16 0 -1 -1 t p f s f f));
  DATA(insert OID = 0 ( 1259 relhaspkey		16 0  1  17 0 -1 -1 t p f c f f));
  DATA(insert OID = 0 ( 1259 relhasrules		16 0  1  18 0 -1 -1 t p f c f f));
! DATA(insert OID = 0 ( 1259 relacl		  1034 0 -1  19 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 ctid				27 0  6  -1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 oid				26 0  4  -2 0 -1 -1 t p f i f f));
  DATA(insert OID = 0 ( 1259 xmin				28 0  4  -3 0 -1 -1 t p f i f f));
--- 423,430 ----
  DATA(insert OID = 0 ( 1259 relrefs			21 0  2  16 0 -1 -1 t p f s f f));
  DATA(insert OID = 0 ( 1259 relhaspkey		16 0  1  17 0 -1 -1 t p f c f f));
  DATA(insert OID = 0 ( 1259 relhasrules		16 0  1  18 0 -1 -1 t p f c f f));
! DATA(insert OID = 0 ( 1259 relhassubclass	16 0  1   19 0 -1 -1 t p f c f f));
! DATA(insert OID = 0 ( 1259 relacl		  1034 0 -1  20 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 ctid				27 0  6  -1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 oid				26 0  4  -2 0 -1 -1 t p f i f f));
  DATA(insert OID = 0 ( 1259 xmin				28 0  4  -3 0 -1 -1 t p f i f f));
Index: pgsql/src/include/catalog/pg_class.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/include/catalog/pg_class.h,v
retrieving revision 1.33
diff -c -r1.33 pg_class.h
*** pgsql/src/include/catalog/pg_class.h	2000/01/26 05:57:57	1.33
--- pgsql/src/include/catalog/pg_class.h	2000/02/05 08:25:09
***************
*** 78,88 ****
  	int2		relrefs;		/* # of references to this relation */
  	bool		relhaspkey;		/* has PRIMARY KEY */
  	bool		relhasrules;
  	aclitem		relacl[1];		/* this is here for the catalog */
  } FormData_pg_class;

#define CLASS_TUPLE_SIZE \
! (offsetof(FormData_pg_class,relhasrules) + sizeof(bool))

  /* ----------------
   *		Form_pg_class corresponds to a pointer to a tuple with
--- 78,89 ----
  	int2		relrefs;		/* # of references to this relation */
  	bool		relhaspkey;		/* has PRIMARY KEY */
  	bool		relhasrules;
+ 	bool		relhassubclass;
  	aclitem		relacl[1];		/* this is here for the catalog */
  } FormData_pg_class;

#define CLASS_TUPLE_SIZE \
! (offsetof(FormData_pg_class,relhassubclass) + sizeof(bool))

  /* ----------------
   *		Form_pg_class corresponds to a pointer to a tuple with
***************
*** 102,109 ****
   *		relacl field.
   * ----------------
   */
! #define Natts_pg_class_fixed			18
! #define Natts_pg_class					19
  #define Anum_pg_class_relname			1
  #define Anum_pg_class_reltype			2
  #define Anum_pg_class_relowner			3
--- 103,110 ----
   *		relacl field.
   * ----------------
   */
! #define Natts_pg_class_fixed			19
! #define Natts_pg_class					20
  #define Anum_pg_class_relname			1
  #define Anum_pg_class_reltype			2
  #define Anum_pg_class_relowner			3
***************
*** 122,128 ****
  #define Anum_pg_class_relrefs			16
  #define Anum_pg_class_relhaspkey		17
  #define Anum_pg_class_relhasrules		18
! #define Anum_pg_class_relacl			19

  /* ----------------
   *		initial contents of pg_class
--- 123,130 ----
  #define Anum_pg_class_relrefs			16
  #define Anum_pg_class_relhaspkey		17
  #define Anum_pg_class_relhasrules		18
! #define Anum_pg_class_relhassubclass		19
! #define Anum_pg_class_relacl			20

  /* ----------------
   *		initial contents of pg_class
***************
*** 135,141 ****
  DESCR("");
  DATA(insert OID = 1255 (  pg_proc 81		  PGUID 0 0 0 0 f f r 16 0 0 0 0 0 f f _null_ ));
  DESCR("");
! DATA(insert OID = 1259 (  pg_class 83		  PGUID 0 0 0 0 f f r 19 0 0 0 0 0 f f _null_ ));
  DESCR("");
  DATA(insert OID = 1260 (  pg_shadow 86		  PGUID 0 0 0 0 f t r 8  0 0 0 0 0 f f _null_ ));
  DESCR("");
--- 137,143 ----
  DESCR("");
  DATA(insert OID = 1255 (  pg_proc 81		  PGUID 0 0 0 0 f f r 16 0 0 0 0 0 f f _null_ ));
  DESCR("");
! DATA(insert OID = 1259 (  pg_class 83		  PGUID 0 0 0 0 f f r 20 0 0 0 0 0 f f _null_ ));
  DESCR("");
  DATA(insert OID = 1260 (  pg_shadow 86		  PGUID 0 0 0 0 f t r 8  0 0 0 0 0 f f _null_ ));
  DESCR("");

--------------246A7F2DAD82630755FAC9D1--

From bouncefilter Sat Feb 5 03:46:02 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA69387
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 03:45:59 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id TAA22970
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 19:45:55 +1100
Sender: chris@tech.com.au
Message-ID: <389BE343.25FFD459@bitmead.com>
Date: Sat, 05 Feb 2000 19:45:55 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: New improved patch
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks Bruce! That suggestion with SearchSysCacheTuple makes a big
difference! I am no longer able to measure ANY performance difference
between inherited and
non-inherited while doing one million queries.

The patch is too big to email, so it's up for ftp here...

ftp://www.tech.com.au/pub/patch.only

--
Chris Bitmead
mailto:chris@bitmead.com

From bouncefilter Sat Feb 5 04:18:02 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA76761
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 04:17:19 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
EAA22818;
Sat, 5 Feb 2000 04:16:10 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002050916.EAA22818@candle.pha.pa.us>
Subject: Re: [HACKERS] New improved patch^N
In-Reply-To: <389BE343.25FFD459@bitmead.com> from Chris at "Feb 5,
2000 07:45:55 pm"
To: Chris <chris@bitmead.com>
Date: Sat, 5 Feb 2000 04:16:10 -0500 (EST)
CC: Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thanks Bruce! That suggestion with SearchSysCacheTuple makes a big
difference! I am no longer able to measure ANY performance difference
between inherited and
non-inherited while doing one million queries.

The patch is too big to email, so it's up for ftp here...

ftp://www.tech.com.au/pub/patch.only

I am getting a failure trying to retrieve this. It says server not
found. Also, are the documentation changes in there?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Feb 5 04:23:03 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA77233
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 04:22:12 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id UAA23196;
Sat, 5 Feb 2000 20:21:48 +1100
Sender: chris@tech.com.au
Message-ID: <389BEBAB.B1BEFC6D@bitmead.com>
Date: Sat, 05 Feb 2000 20:21:47 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] New improved patch^N
References: <200002050916.EAA22818@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

I am getting a failure trying to retrieve this. It
says server not found.

That's strange. I'll email you the patch in a separate email.

Also, are the documentation
changes in there?

Yes.

--
Bruce Momjian                        |  http://www.op.net/~candle
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

--
Chris Bitmead
mailto:chris@bitmead.com
http://www.techphoto.org - Photography News, Stuff that Matters

From bouncefilter Sat Feb 5 04:32:02 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA80461
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 04:31:36 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
EAA24979;
Sat, 5 Feb 2000 04:31:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002050931.EAA24979@candle.pha.pa.us>
Subject: Re: [HACKERS] New improved patch^N
In-Reply-To: <389BE343.25FFD459@bitmead.com> from Chris at "Feb 5,
2000 07:45:55 pm"
To: Chris <chris@bitmead.com>
Date: Sat, 5 Feb 2000 04:31:02 -0500 (EST)
CC: Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM949743062-22250-0_
Content-Transfer-Encoding: 7bit

--ELM949743062-22250-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thanks Bruce! That suggestion with SearchSysCacheTuple makes a big
difference! I am no longer able to measure ANY performance difference
between inherited and
non-inherited while doing one million queries.

The patch is too big to email, so it's up for ftp here...

ftp://www.tech.com.au/pub/patch.only

Never mind. Got it. I am attaching it here for people to review.
Let's see what people say now. I see documentation changes in there
too. Great.

Gee, I didn't know catalog.sgml existed. I wonder if it is up-to-date?
No, pg_database doesn't show "encoding". Man, this is really old. I
see pg_platter, which we have never had. I deals with jukebox platter
inventory. pg_class shows things like relpreserved, which deals with
time travel. I suggest we remove this file and tell people to look in
include/catalog/*.h and use \dS. Comments?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

--ELM949743062-22250-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/root/patch.only"
Content-Transfer-Encoding: 7bit

? pgsql/src/config.log
? pgsql/src/config.cache
? pgsql/src/config.status
? pgsql/src/GNUmakefile
? pgsql/src/Makefile.global
? pgsql/src/backend/fmgr.h
? pgsql/src/backend/parse.h
? pgsql/src/backend/postgres
? pgsql/src/backend/global1.bki.source
? pgsql/src/backend/local1_template1.bki.source
? pgsql/src/backend/global1.description
? pgsql/src/backend/local1_template1.description
? pgsql/src/backend/1
? pgsql/src/backend/catalog/genbki.sh
? pgsql/src/backend/catalog/global1.bki.source
? pgsql/src/backend/catalog/global1.description
? pgsql/src/backend/catalog/local1_template1.bki.source
? pgsql/src/backend/catalog/local1_template1.description
? pgsql/src/backend/port/Makefile
? pgsql/src/backend/utils/Gen_fmgrtab.sh
? pgsql/src/backend/utils/fmgr.h
? pgsql/src/backend/utils/fmgrtab.c
? pgsql/src/bin/initdb/initdb
? pgsql/src/bin/initlocation/initlocation
? pgsql/src/bin/ipcclean/ipcclean
? pgsql/src/bin/pg_ctl/pg_ctl
? pgsql/src/bin/pg_dump/Makefile
? pgsql/src/bin/pg_dump/pg_dump
? pgsql/src/bin/pg_id/pg_id
? pgsql/src/bin/pg_passwd/pg_passwd
? pgsql/src/bin/pg_version/Makefile
? pgsql/src/bin/pg_version/pg_version
? pgsql/src/bin/pgtclsh/mkMakefile.tcldefs.sh
? pgsql/src/bin/pgtclsh/mkMakefile.tkdefs.sh
? pgsql/src/bin/psql/Makefile
? pgsql/src/bin/psql/psql
? pgsql/src/bin/scripts/createlang
? pgsql/src/include/version.h
? pgsql/src/include/config.h
? pgsql/src/interfaces/ecpg/lib/Makefile
? pgsql/src/interfaces/ecpg/lib/libecpg.so.3.0.10
? pgsql/src/interfaces/ecpg/preproc/ecpg
? pgsql/src/interfaces/libpgeasy/Makefile
? pgsql/src/interfaces/libpgeasy/libpgeasy.so.2.1
? pgsql/src/interfaces/libpgtcl/Makefile
? pgsql/src/interfaces/libpq/Makefile
? pgsql/src/interfaces/libpq/libpq.so.2.1
? pgsql/src/interfaces/libpq++/Makefile
? pgsql/src/interfaces/libpq++/libpq++.so.3.1
? pgsql/src/interfaces/odbc/GNUmakefile
? pgsql/src/interfaces/odbc/Makefile.global
? pgsql/src/pl/plpgsql/src/Makefile
? pgsql/src/pl/plpgsql/src/mklang.sql
? pgsql/src/pl/plpgsql/src/libplpgsql.so.1.0
? pgsql/src/pl/tcl/mkMakefile.tcldefs.sh
? pgsql/src/test/regress/GNUmakefile
Index: pgsql/doc/src/sgml/advanced.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/advanced.sgml,v
retrieving revision 1.7
diff -c -r1.7 advanced.sgml
*** pgsql/doc/src/sgml/advanced.sgml	1999/10/04 15:18:53	1.7
--- pgsql/doc/src/sgml/advanced.sgml	2000/02/05 08:24:35
***************
*** 56,93 ****
       </para>
      </note>

! For example, the following query finds
! all the cities that are situated at an attitude of 500ft or higher:
!
! <programlisting>
! SELECT name, altitude
! FROM cities
! WHERE altitude &gt; 500;

+----------+----------+
|name | altitude |
+----------+----------+
|Las Vegas | 2174 |
+----------+----------+
|Mariposa | 1953 |
+----------+----------+
! </programlisting>
! </para>

! <para>
! On the other hand, to find the names of all cities,
! including state capitals, that are located at an altitude
! over 500ft, the query is:
!
! <programlisting>
! SELECT c.name, c.altitude
! FROM cities* c
! WHERE c.altitude > 500;
! </programlisting>

-     which returns:
-      
-     <programlisting>
  +----------+----------+
  |name      | altitude |
  +----------+----------+
--- 56,97 ----
       </para>
      </note>

! <para>
! For example, the following query finds the names of all cities,
! including state capitals, that are located at an altitude
! over 500ft, the query is:
!
! <programlisting>
! SELECT c.name, c.altitude
! FROM cities c
! WHERE c.altitude > 500;
! </programlisting>

+    which returns:
+ 
+    <programlisting>
  +----------+----------+
  |name      | altitude |
  +----------+----------+
  |Las Vegas | 2174     |
  +----------+----------+
  |Mariposa  | 1953     |
+ +----------+----------+
+ |Madison   | 845      |
  +----------+----------+
!    </programlisting>
!   </para>

! <para>
! On the other hand, the following query finds
! all the cities, but not capital cities
! that are situated at an attitude of 500ft or higher:
!
! <programlisting>
! SELECT name, altitude
! FROM ONLY cities
! WHERE altitude &gt; 500;

+----------+----------+
|name | altitude |
+----------+----------+
***************
*** 95,112 ****
+----------+----------+
|Mariposa | 1953 |
+----------+----------+
! |Madison | 845 |
! +----------+----------+
! </programlisting>

! Here the <quote>*</quote> after cities indicates that the query should
! be run over cities and all classes below cities in the
! inheritance hierarchy. Many of the commands that we
! have already discussed (<command>select</command>,
! <command>and>up</command>and> and <command>delete</command>)
! support this <quote>*</quote> notation, as do others, like
! <command>alter</command>.
! </para>
</sect1>

    <sect1>
--- 99,129 ----
  +----------+----------+
  |Mariposa  | 1953     |
  +----------+----------+
!    </programlisting>         
!   </para>
! 

! Here the <quote>ONLY</quote> before cities indicates that the query should
! be run over only cities and not classes below cities in the
! inheritance hierarchy. Many of the commands that we
! have already discussed -- <command>SELECT</command>,
! <command>UPDATE</command> and <command>DELETE</command> --
! support this <quote>ONLY</quote> notation, as do others, like
! <command>ALTER TABLE</command>.
! </para>
! <para>
! Deprecated: In previous versions of postgres, the default was not to
! get access to child classes. By experience this was found to be error
! prone. Under the old syntax, to get the sub-classes you append "*"
! to the table name. For example
! <programlisting>
! SELECT * from cities*;
! </programlisting>
! This old behaviour is still available by using a SET command...
! <programlisting>
! SET EXAMINE_SUBCLASS TO 'on';
! </programlisting>
! </para>
</sect1>

    <sect1>
Index: pgsql/doc/src/sgml/catalogs.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v
retrieving revision 2.3
diff -c -r2.3 catalogs.sgml
*** pgsql/doc/src/sgml/catalogs.sgml	2000/01/22 23:50:08	2.3
--- pgsql/doc/src/sgml/catalogs.sgml	2000/02/05 08:24:37
***************
*** 192,197 ****
--- 192,199 ----
  			   2=main memory */
       int2vector relkey		/* - unused */
       oidvector  relkeyop	/* - unused */
+      bool       relhassubclass	/* does the class have a subclass?
+ 				    */
       aclitem    relacl[1]	/* access control lists */
  .fi
  .nf M
Index: pgsql/doc/src/sgml/inherit.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v
retrieving revision 1.4
diff -c -r1.4 inherit.sgml
*** pgsql/doc/src/sgml/inherit.sgml	1999/08/08 04:21:33	1.4
--- pgsql/doc/src/sgml/inherit.sgml	2000/02/05 08:24:37
***************
*** 37,50 ****
      </para>
     </note>

! For example, the following query finds
! all the cities that are situated at an attitude of 500ft or higher:

<programlisting>
! SELECT name, altitude
! FROM cities
! WHERE altitude &gt; 500;

  +----------+----------+
  |name      | altitude |
  +----------+----------+
--- 37,56 ----
      </para>
     </note>

! <para>
! For example, the following query finds the names of all cities,
! including state capitals, that are located at an altitude
! over 500ft, the query is:

<programlisting>
! SELECT c.name, c.altitude
! FROM cities c
! WHERE c.altitude > 500;
! </programlisting>
!
! which returns:

+ <programlisting>
+----------+----------+
|name | altitude |
+----------+----------+
***************
*** 52,92 ****
+----------+----------+
|Mariposa | 1953 |
+----------+----------+
! </programlisting>
</para>

<para>
! On the other hand, to find the names of all cities,
! including state capitals, that are located at an altitude
! over 500ft, the query is:

<programlisting>
! SELECT c.name, c.altitude
! FROM cities* c
! WHERE c.altitude > 500;
! </programlisting>
!
! which returns:

-    <programlisting>
  +----------+----------+
  |name      | altitude |
  +----------+----------+
  |Las Vegas | 2174     |
  +----------+----------+
  |Mariposa  | 1953     |
- +----------+----------+
- |Madison   | 845      |
  +----------+----------+
!    </programlisting>

! Here the <quote>*</quote> after cities indicates that the query should
! be run over cities and all classes below cities in the
inheritance hierarchy. Many of the commands that we
have already discussed -- <command>SELECT</command>,
<command>UPDATE</command> and <command>DELETE</command> --
! support this <quote>*</quote> notation, as do others, like
<command>ALTER TABLE</command>.
</para>
</chapter>

--- 58,109 ----
  +----------+----------+
  |Mariposa  | 1953     |
  +----------+----------+
! |Madison   | 845      |
! +----------+----------+
!    </programlisting>
    </para>

<para>
! On the other hand, the following query finds
! all the cities, but not capital cities
! that are situated at an attitude of 500ft or higher:

<programlisting>
! SELECT name, altitude
! FROM ONLY cities
! WHERE altitude &gt; 500;

+----------+----------+
|name | altitude |
+----------+----------+
|Las Vegas | 2174 |
+----------+----------+
|Mariposa | 1953 |
+----------+----------+
! </programlisting>
! </para>

! 
!    Here the <quote>ONLY</quote> before cities indicates that the query should
!    be  run over only cities and not classes below cities in the
     inheritance hierarchy.  Many of the  commands  that  we
     have  already discussed -- <command>SELECT</command>,
     <command>UPDATE</command> and <command>DELETE</command> --
!    support this <quote>ONLY</quote> notation, as do others, like
     <command>ALTER TABLE</command>.
+   </para>
+   <para>
+   Deprecated: In previous versions of postgres, the default was not to
+   get access to child classes. By experience this was found to be error
+   prone. Under the old syntax, to get the sub-classes you append "*"
+   to the table name. For example
+    <programlisting>
+    SELECT * from cities*;
+    </programlisting>     
+    This old behaviour is still available by using a SET command...    
+    <programlisting>
+    SET EXAMINE_SUBCLASS TO 'on';
+    </programlisting>     
    </para>
   </chapter>

Index: pgsql/doc/src/sgml/ref/alter_table.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/alter_table.sgml,v
retrieving revision 1.10
diff -c -r1.10 alter_table.sgml
*** pgsql/doc/src/sgml/ref/alter_table.sgml	2000/01/29 16:58:27	1.10
--- pgsql/doc/src/sgml/ref/alter_table.sgml	2000/02/05 08:24:38
***************
*** 23,35 ****
     <date>1999-07-20</date>
    </refsynopsisdivinfo>
    <synopsis>
! ALTER TABLE <replaceable class="PARAMETER">table</replaceable> [ * ]
      ADD [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> <replaceable
      class="PARAMETER">type</replaceable>
! ALTER TABLE <replaceable class="PARAMETER">table</replaceable> [ * ]
      ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> { SET DEFAULT <replaceable
      class="PARAMETER">value</replaceable> | DROP DEFAULT }
! ALTER TABLE <replaceable class="PARAMETER">table</replaceable> [ * ]
      RENAME [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> TO <replaceable
      class="PARAMETER">newcolumn</replaceable>
  ALTER TABLE <replaceable class="PARAMETER">table</replaceable>
--- 23,35 ----
     <date>1999-07-20</date>
    </refsynopsisdivinfo>
    <synopsis>
! ALTER TABLE [ ONLY ]<replaceable class="PARAMETER">table</replaceable> [ * ]
      ADD [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> <replaceable
      class="PARAMETER">type</replaceable>
! ALTER TABLE [ ONLY ]<replaceable class="PARAMETER">table</replaceable> [ * ]
      ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> { SET DEFAULT <replaceable
      class="PARAMETER">value</replaceable> | DROP DEFAULT }
! ALTER TABLE [ ONLY ]<replaceable class="PARAMETER">table</replaceable> [ * ]
      RENAME [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> TO <replaceable
      class="PARAMETER">newcolumn</replaceable>
  ALTER TABLE <replaceable class="PARAMETER">table</replaceable>
***************
*** 162,178 ****
     </para>

<para>
! <quote>*</quote> following a name of a table indicates that the statement
! should be run over that table and all tables below it in the
inheritance hierarchy;
! by default, the attribute will not be added to or renamed in any of the subclasses.

! This should always be done when adding or modifying an attribute in a
! superclass. If it is not, queries on the inheritance hierarchy
such as

<programlisting>
! SELECT <replaceable>NewColumn</replaceable> FROM <replaceable>SuperClass</replaceable>*
</programlisting>

      will not work because the subclasses will be missing an attribute
--- 162,178 ----
     </para>

<para>
! <quote>ONLY</quote> preceeding the name of a table indicates that the statement
! should be run over only that table and not tables below it in the
inheritance hierarchy;
! by default, the attribute will be added to or renamed in any of the subclasses.

! It is recommended to never use the ONLY feature however.
! If it is, queries on the inheritance hierarchy
such as

<programlisting>
! SELECT <replaceable>NewColumn</replaceable> FROM <replaceable>SuperClass</replaceable>
</programlisting>

      will not work because the subclasses will be missing an attribute
Index: pgsql/doc/src/sgml/ref/select.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v
retrieving revision 1.24
diff -c -r1.24 select.sgml
*** pgsql/doc/src/sgml/ref/select.sgml	2000/01/27 18:11:25	1.24
--- pgsql/doc/src/sgml/ref/select.sgml	2000/02/05 08:24:40
***************
*** 25,31 ****
  SELECT [ ALL | DISTINCT [ ON ( <replaceable class="PARAMETER">expression</replaceable> [, ...] ) ] ]
      <replaceable class="PARAMETER">expression</replaceable> [ AS <replaceable class="PARAMETER">name</replaceable> ] [, ...]
      [ INTO [ TEMPORARY | TEMP ] [ TABLE ] <replaceable class="PARAMETER">new_table</replaceable> ]
!     [ FROM <replaceable class="PARAMETER">table</replaceable> [ <replaceable class="PARAMETER">alias</replaceable> ] [, ...] ]
      [ WHERE <replaceable class="PARAMETER">condition</replaceable> ]
      [ GROUP BY <replaceable class="PARAMETER">column</replaceable> [, ...] ]
      [ HAVING <replaceable class="PARAMETER">condition</replaceable> [, ...] ]
--- 25,31 ----
  SELECT [ ALL | DISTINCT [ ON ( <replaceable class="PARAMETER">expression</replaceable> [, ...] ) ] ]
      <replaceable class="PARAMETER">expression</replaceable> [ AS <replaceable class="PARAMETER">name</replaceable> ] [, ...]
      [ INTO [ TEMPORARY | TEMP ] [ TABLE ] <replaceable class="PARAMETER">new_table</replaceable> ]
!     [ FROM [ ONLY ]<replaceable class="PARAMETER">table</replaceable> [ <replaceable class="PARAMETER">alias</replaceable> ] [, ...] ]
      [ WHERE <replaceable class="PARAMETER">condition</replaceable> ]
      [ GROUP BY <replaceable class="PARAMETER">column</replaceable> [, ...] ]
      [ HAVING <replaceable class="PARAMETER">condition</replaceable> [, ...] ]
***************
*** 198,203 ****
--- 198,210 ----
     Candidates for selection are rows which satisfy the WHERE condition;
     if WHERE is omitted, all rows are candidates.
     (See <xref linkend="sql-where" endterm="sql-where-title">.)
+   </para>
+   <para>
+   <command>ONLY</command> will eliminate rows from subclasses of the table.
+   This was previously the default result, and getting subclasses was
+   obtained by appending <command>*</command> to the table name.
+   The old behaviour is available via the command 
+   <command>SET EXAMINE_SUBCLASS TO 'on';</command>
    </para>

    <para>
Index: pgsql/doc/src/sgml/ref/set.sgml
===================================================================
RCS file: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/set.sgml,v
retrieving revision 1.28
diff -c -r1.28 set.sgml
*** pgsql/doc/src/sgml/ref/set.sgml	1999/07/22 15:09:15	1.28
--- pgsql/doc/src/sgml/ref/set.sgml	2000/02/05 08:24:41
***************
*** 443,448 ****
--- 443,482 ----
  	  </listitem>
  	 </varlistentry>

+      <varlistentry>
+       <term>EXAMINE_SUBCLASS</term>
+       <listitem>
+        <para>
+ 	Sets the inheritance query syntax to the traditional postgres style.
+ 	
+ 	<variablelist>
+ 	 <varlistentry>
+ 	  <term><replaceable class="parameter">OFF</replaceable></term>
+ 	  <listitem>
+ 	   <para>
+        Changes the behaviour of SELECT so that it no longer automatically
+        examines sub-classes. (See SELECT). By default a SELECT on a table
+        will also return subclass tuples unless specifying ONLY tablename.
+        Setting this returns postgres to the traditional behaviour of
+        only returning subclasses when appending "*" to the tablename.
+ 	   </para>
+ 	  </listitem>
+ 	 </varlistentry>
+ 	 
+ 	 <varlistentry>
+ 	  <term>ON</term>
+ 	  <listitem>
+ 	   <para>
+        Returns SELECT to the behaviour of automatically returning
+        results from sub-classes.
+ 	   </para>
+ 	  </listitem>
+ 	 </varlistentry>
+ 	</variablelist>
+        </para>
+       </listitem>
+      </varlistentry>
+ 
  	 <varlistentry>
  	  <term>OFF</term>
  	  <listitem>
Index: pgsql/src/backend/commands/creatinh.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/commands/creatinh.c,v
retrieving revision 1.56
diff -c -r1.56 creatinh.c
*** pgsql/src/backend/commands/creatinh.c	2000/01/29 16:58:34	1.56
--- pgsql/src/backend/commands/creatinh.c	2000/02/05 08:24:44
***************
*** 35,40 ****
--- 35,43 ----
                              const char *attributeType, List *schema);
  static List *MergeAttributes(List *schema, List *supers, List **supconstr);
  static void StoreCatalogInheritance(Oid relationId, List *supers);
+ static void
+ setRelhassubclassInRelation(Oid relationId, bool relhassubclass);
+ 

  /* ----------------------------------------------------------------
   *		DefineRelation
***************
*** 323,328 ****
--- 326,332 ----
  		TupleConstr *constr;

relation = heap_openr(name, AccessShareLock);
+ setRelhassubclassInRelation(relation->rd_id, true);
tupleDesc = RelationGetDescr(relation);
constr = tupleDesc->constr;

***************
*** 655,657 ****
--- 659,698 ----
  	}
  	return false;
  }
+ 
+ 
+ static void
+ setRelhassubclassInRelation(Oid relationId, bool relhassubclass)
+ {
+         Relation        relationRelation;
+         HeapTuple       tuple;
+         Relation        idescs[Num_pg_class_indices];
+ 
+         /*
+          * Lock a relation given its Oid. Go to the RelationRelation (i.e.
+          * pg_relation), find the appropriate tuple, and add the specified
+          * lock to it.
+          */
+         relationRelation = heap_openr(RelationRelationName, RowExclusiveLock);
+         tuple = SearchSysCacheTuple(RELOID,
+                                     ObjectIdGetDatum(relationId),
+                                     0, 0, 0)
+ ;
+         Assert(HeapTupleIsValid(tuple));
+ 
+         ((Form_pg_class) GETSTRUCT(tuple))->relhassubclass = relhassubclass;
+         heap_update(relationRelation, &tuple->t_self, tuple, NULL);
+ 
+         /* keep the catalog indices up to date */
+         CatalogOpenIndices(Num_pg_class_indices, Name_pg_class_indices, idescs);
+         CatalogIndexInsert(idescs, Num_pg_class_indices, relationRelation, tuple
+ );
+         CatalogCloseIndices(Num_pg_class_indices, idescs);
+ 
+         /*        heap_freetuple(tuple); */
+         heap_close(relationRelation, RowExclusiveLock);
+ }
+ 
+ 
+ 
+ 
Index: pgsql/src/backend/commands/variable.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/commands/variable.c,v
retrieving revision 1.28
diff -c -r1.28 variable.c
*** pgsql/src/backend/commands/variable.c	2000/01/22 23:50:10	1.28
--- pgsql/src/backend/commands/variable.c	2000/02/05 08:24:45
***************
*** 48,53 ****
--- 48,56 ----

extern bool _use_keyset_query_optimizer;

+ #define examine_subclass_default true
+ bool examine_subclass = examine_subclass_default;
+ 
  /*
   *
   * Get_Token
***************
*** 228,233 ****
--- 231,274 ----
  	geqo_rels = GEQO_RELS;
  	return TRUE;
  }
+ /*
+  *
+  * EXAMINE_SUBCLASS
+  *
+  */
+ #define EXAMINE_SUBCLASS "EXAMINE_SUBCLASS"
+ 
+ static bool
+ parse_examine_subclass(const char *value)
+ {
+     if (strcasecmp(value, "on") == 0)
+         examine_subclass = true;
+     else if (strcasecmp(value, "off") == 0)
+         examine_subclass = false;
+     else if (strcasecmp(value, "default") == 0) 
+         examine_subclass = examine_subclass_default;
+ 	else
+ 		elog(ERROR, "Bad value for %s (%s)", EXAMINE_SUBCLASS, value);
+ 	return TRUE;
+ }
+ 
+ static bool
+ show_examine_subclass()
+ {
+     
+ 	if (examine_subclass)
+ 		elog(NOTICE, "%s is ON", EXAMINE_SUBCLASS);
+ 	else
+ 		elog(NOTICE, "%s is OFF", EXAMINE_SUBCLASS);
+ 	return TRUE;
+ }
+ 
+ static bool
+ reset_examine_subclass(void)
+ {
+     examine_subclass = examine_subclass_default;
+ 	return TRUE;
+ }

  /*
   *
***************
*** 600,605 ****
--- 641,649 ----
  	{
  		"pg_options", parse_pg_options, show_pg_options, reset_pg_options
  	},
+     {
+ 		EXAMINE_SUBCLASS, parse_examine_subclass, show_examine_subclass, reset_examine_subclass
+     },
  	{
  		NULL, NULL, NULL, NULL
  	}
Index: pgsql/src/backend/optimizer/plan/planner.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v
retrieving revision 1.74
diff -c -r1.74 planner.c
*** pgsql/src/backend/optimizer/plan/planner.c	2000/01/27 18:11:31	1.74
--- pgsql/src/backend/optimizer/plan/planner.c	2000/02/05 08:24:48
***************
*** 35,40 ****
--- 35,41 ----
  #include "utils/builtins.h"
  #include "utils/lsyscache.h"
  #include "utils/syscache.h"
+ #include "parser/parsetree.h"

static List *make_subplanTargetList(Query *parse, List *tlist,
AttrNumber **groupColIdx);
***************
*** 140,146 ****
* to change interface to plan_union_queries to pass that info back!
*/
}
! else if ((rt_index = first_inherit_rt_entry(rangetable)) != -1)
{
List *sub_tlist;

--- 141,147 ----
  		 * to change interface to plan_union_queries to pass that info back!
  		 */
  	}
! 	else if ((rt_index = first_inherit_rt_entry(rangetable)) != -1 && has_inheritors(rt_fetch(rt_index, parse->rtable)->relid))
  	{
  		List	   *sub_tlist;

Index: pgsql/src/backend/optimizer/prep/prepunion.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/optimizer/prep/prepunion.c,v
retrieving revision 1.43
diff -c -r1.43 prepunion.c
*** pgsql/src/backend/optimizer/prep/prepunion.c	2000/02/03 06:12:19	1.43
--- pgsql/src/backend/optimizer/prep/prepunion.c	2000/02/05 08:24:49
***************
*** 25,30 ****
--- 25,33 ----
  #include "parser/parse_clause.h"
  #include "parser/parsetree.h"
  #include "utils/lsyscache.h"
+ #include "access/heapam.h"
+ #include "catalog/catname.h"
+ #include "utils/syscache.h"

  typedef struct {
  	Index		rt_index;
***************
*** 45,50 ****
--- 48,54 ----
  static Append *make_append(List *appendplans, List *unionrtables,
  						   Index rt_index,
  						   List *inheritrtable, List *tlist);
+ bool has_inheritors(Oid relationId);

  /*
***************
*** 352,357 ****
--- 356,386 ----

  	*union_rtentriesPtr = union_rtentries;
  	return union_plans;
+ }
+ 
+ bool has_inheritors(Oid relationId)
+ {
+         bool rtn;
+         Relation        relationRelation;
+         HeapTuple       tuple;
+ 
+         /*
+          * Lock a relation given its Oid. Go to the RelationRelation (i.e.
+          * pg_relation), find the appropriate tuple, and add the specified
+          * lock to it.
+          */
+         relationRelation = heap_openr(RelationRelationName, NoLock);
+         tuple = SearchSysCacheTuple(RELOID,
+                                  ObjectIdGetDatum(relationId),
+                                  0, 0, 0)
+ ;
+ /*        Assert(HeapTupleIsValid(tuple)); */
+ 
+         rtn = ((Form_pg_class) GETSTRUCT(tuple))->relhassubclass;
+ 
+         /*         heap_freetuple(tuple); */
+         heap_close(relationRelation, NoLock);
+         return rtn;
  }

  /*
Index: pgsql/src/backend/parser/gram.y
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.139
diff -c -r2.139 gram.y
*** pgsql/src/backend/parser/gram.y	2000/02/04 18:49:33	2.139
--- pgsql/src/backend/parser/gram.y	2000/02/05 08:25:00
***************
*** 811,868 ****

AlterTableStmt:
/* ALTER TABLE <name> ADD [COLUMN] <coldef> */
ALTER TABLE relation_name opt_inh_star ADD opt_column columnDef
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'A';
n->relname = $3;
! n->inh = $4;
n->def = $7;
$$ = (Node *)n;
}
/* ALTER TABLE <name> ALTER [COLUMN] <colname> {SET DEFAULT <expr>|DROP DEFAULT} */
| ALTER TABLE relation_name opt_inh_star ALTER opt_column ColId alter_column_action
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'T';
n->relname = $3;
! n->inh = $4;
n->name = $7;
n->def = $8;
$$ = (Node *)n;
}
/* ALTER TABLE <name> DROP [COLUMN] <name> {RESTRICT|CASCADE} */
| ALTER TABLE relation_name opt_inh_star DROP opt_column ColId drop_behavior
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'D';
n->relname = $3;
! n->inh = $4;
n->name = $7;
n->behavior = $8;
$$ = (Node *)n;
}
/* ALTER TABLE <name> ADD CONSTRAINT ... */
| ALTER TABLE relation_name opt_inh_star ADD TableConstraint
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'C';
n->relname = $3;
! n->inh = $4;
n->def = $6;
$$ = (Node *)n;
}
/* ALTER TABLE <name> DROP CONSTRAINT <name> {RESTRICT|CASCADE} */
| ALTER TABLE relation_name opt_inh_star DROP CONSTRAINT name drop_behavior
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'X';
n->relname = $3;
! n->inh = $4;
n->name = $7;
n->behavior = $8;
$$ = (Node *)n;
}
;

  alter_column_action:
--- 811,926 ----

  AlterTableStmt:
  /* ALTER TABLE <name> ADD [COLUMN] <coldef> */
+         /* "*" deprecated */
          ALTER TABLE relation_name opt_inh_star ADD opt_column columnDef
  	{
+         extern bool examine_subclass;
  		AlterTableStmt *n = makeNode(AlterTableStmt);
                  n->subtype = 'A';
  		n->relname = $3;
! 		n->inh = $4 || examine_subclass;
  		n->def = $7;
  		$$ = (Node *)n;
  	}
+     |    ALTER TABLE ONLY relation_name ADD opt_column columnDef
+ 	{
+ 		AlterTableStmt *n = makeNode(AlterTableStmt);
+                 n->subtype = 'A';
+ 		n->relname = $4;
+ 		n->inh = FALSE;
+ 		n->def = $7;
+ 		$$ = (Node *)n;
+ 	}
  /* ALTER TABLE <name> ALTER [COLUMN] <colname> {SET DEFAULT <expr>|DROP DEFAULT} */
+         /* "*" deprecated */
        | ALTER TABLE relation_name opt_inh_star ALTER opt_column ColId alter_column_action
          {
+         extern bool examine_subclass;
                  AlterTableStmt *n = makeNode(AlterTableStmt);
                  n->subtype = 'T';
                  n->relname = $3;
!                 n->inh = $4 || examine_subclass;
                  n->name = $7;
                  n->def = $8;
                  $$ = (Node *)n;
          }
+       | ALTER TABLE ONLY relation_name ALTER opt_column ColId alter_column_action
+         {
+                 AlterTableStmt *n = makeNode(AlterTableStmt);
+                 n->subtype = 'T';
+                 n->relname = $4;
+                 n->inh = FALSE;
+                 n->name = $7;
+                 n->def = $8;
+                 $$ = (Node *)n;
+         }
  /* ALTER TABLE <name> DROP [COLUMN] <name> {RESTRICT|CASCADE} */
+         /* "*" deprecated */
        | ALTER TABLE relation_name opt_inh_star DROP opt_column ColId drop_behavior
          {
+         extern bool examine_subclass;
                  AlterTableStmt *n = makeNode(AlterTableStmt);
                  n->subtype = 'D';
                  n->relname = $3;
!                 n->inh = $4 || examine_subclass;
                  n->name = $7;
                  n->behavior = $8;
                  $$ = (Node *)n;
          }
+       | ALTER TABLE ONLY relation_name DROP opt_column ColId drop_behavior
+         {
+                 AlterTableStmt *n = makeNode(AlterTableStmt);
+                 n->subtype = 'D';
+                 n->relname = $4;
+                 n->inh = FALSE;
+                 n->name = $7;
+                 n->behavior = $8;
+                 $$ = (Node *)n;
+         }
  /* ALTER TABLE <name> ADD CONSTRAINT ... */
+         /* "*" deprecated */
        | ALTER TABLE relation_name opt_inh_star ADD TableConstraint
          {
+         extern bool examine_subclass;
                  AlterTableStmt *n = makeNode(AlterTableStmt);
                  n->subtype = 'C';
                  n->relname = $3;
!                 n->inh = $4 || examine_subclass;
                  n->def = $6;
                  $$ = (Node *)n;
          }
+       | ALTER TABLE ONLY relation_name ADD TableConstraint
+         {
+                 AlterTableStmt *n = makeNode(AlterTableStmt);
+                 n->subtype = 'C';
+                 n->relname = $4;
+                 n->inh = FALSE;
+                 n->def = $6;
+                 $$ = (Node *)n;
+         }
  /* ALTER TABLE <name> DROP CONSTRAINT <name> {RESTRICT|CASCADE} */
+         /* "*" deprecated */
        | ALTER TABLE relation_name opt_inh_star DROP CONSTRAINT name drop_behavior
          {
+         extern bool examine_subclass;
                  AlterTableStmt *n = makeNode(AlterTableStmt);
                  n->subtype = 'X';
                  n->relname = $3;
!                 n->inh = $4 || examine_subclass;
                  n->name = $7;
                  n->behavior = $8;
                  $$ = (Node *)n;
          }
+       | ALTER TABLE ONLY relation_name DROP CONSTRAINT name drop_behavior
+         {
+                 AlterTableStmt *n = makeNode(AlterTableStmt);
+                 n->subtype = 'X';
+                 n->relname = $4;
+                 n->inh = FALSE;
+                 n->name = $7;
+                 n->behavior = $8;
+                 $$ = (Node *)n;
+         }
          ;

alter_column_action:
***************
*** 2380,2390 ****
*****************************************************************************/

  RenameStmt:  ALTER TABLE relation_name opt_inh_star
  				  RENAME opt_column opt_name TO name
  				{
  					RenameStmt *n = makeNode(RenameStmt);
  					n->relname = $3;
! 					n->inh = $4;
  					n->column = $7;
  					n->newname = $9;
  					$$ = (Node *)n;
--- 2438,2460 ----
   *****************************************************************************/

  RenameStmt:  ALTER TABLE relation_name opt_inh_star
+         /* "*" deprecated */
  				  RENAME opt_column opt_name TO name
  				{
+                     extern bool examine_subclass;
  					RenameStmt *n = makeNode(RenameStmt);
  					n->relname = $3;
! 					n->inh = $4 || examine_subclass;
! 					n->column = $7;
! 					n->newname = $9;
! 					$$ = (Node *)n;
! 				}
!       | ALTER TABLE ONLY relation_name
! 				  RENAME opt_column opt_name TO name
! 				{
! 					RenameStmt *n = makeNode(RenameStmt);
! 					n->relname = $4;
! 					n->inh = FALSE;
  					n->column = $7;
  					n->newname = $9;
  					$$ = (Node *)n;
***************
*** 3553,3562 ****

  relation_expr:	relation_name
  				{
! 					/* normal relations */
  					$$ = makeNode(RelExpr);
  					$$->relname = $1;
! 					$$->inh = FALSE;
  				}
  		| relation_name '*'				  %prec '='
  				{
--- 3623,3633 ----

  relation_expr:	relation_name
  				{
!     				/* default inheritance */
!                     extern bool examine_subclass;
  					$$ = makeNode(RelExpr);
  					$$->relname = $1;
! 					$$->inh = examine_subclass;
  				}
  		| relation_name '*'				  %prec '='
  				{
***************
*** 3565,3570 ****
--- 3636,3648 ----
  					$$->relname = $1;
  					$$->inh = TRUE;
  				}
+         | ONLY relation_name
+                 {
+ 					/* no inheritance */
+ 					$$ = makeNode(RelExpr);
+ 					$$->relname = $2;
+ 					$$->inh = FALSE;
+                 }

  opt_array_bounds:	'[' ']' opt_array_bounds
  				{  $$ = lcons(makeInteger(-1), $3); }
Index: pgsql/src/include/catalog/catversion.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/include/catalog/catversion.h,v
retrieving revision 1.13
diff -c -r1.13 catversion.h
*** pgsql/src/include/catalog/catversion.h	2000/01/27 18:11:40	1.13
--- pgsql/src/include/catalog/catversion.h	2000/02/05 08:25:05
***************
*** 53,58 ****
   */

/* yyyymmddN */
! #define CATALOG_VERSION_NO 200001271

  #endif
--- 53,58 ----
   */

/* yyyymmddN */
! #define CATALOG_VERSION_NO 200002050

  #endif
Index: pgsql/src/include/catalog/pg_attribute.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/include/catalog/pg_attribute.h,v
retrieving revision 1.53
diff -c -r1.53 pg_attribute.h
*** pgsql/src/include/catalog/pg_attribute.h	2000/01/26 05:57:57	1.53
--- pgsql/src/include/catalog/pg_attribute.h	2000/02/05 08:25:09
***************
*** 402,408 ****
  { 1259, {"relrefs"},	   21, 0,	2, 16, 0, -1, -1, '\001', 'p', '\0', 's', '\0', '\0' }, \
  { 1259, {"relhaspkey"},    16, 0,	1, 17, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
  { 1259, {"relhasrules"},   16, 0,	1, 18, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
! { 1259, {"relacl"},		 1034, 0,  -1, 19, 0, -1, -1,	'\0', 'p', '\0', 'i', '\0', '\0' }

  DATA(insert OID = 0 ( 1259 relname			19 0 NAMEDATALEN   1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 reltype			26 0  4   2 0 -1 -1 t p f i f f));
--- 402,409 ----
  { 1259, {"relrefs"},	   21, 0,	2, 16, 0, -1, -1, '\001', 'p', '\0', 's', '\0', '\0' }, \
  { 1259, {"relhaspkey"},    16, 0,	1, 17, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
  { 1259, {"relhasrules"},   16, 0,	1, 18, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
! { 1259, {"relhassubclass"},16, 0,	1, 19, 0, -1, -1, '\001', 'p', '\0', 'c', '\0', '\0' }, \
! { 1259, {"relacl"},		 1034, 0,  -1, 20, 0, -1, -1,	'\0', 'p', '\0', 'i', '\0', '\0' }

  DATA(insert OID = 0 ( 1259 relname			19 0 NAMEDATALEN   1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 reltype			26 0  4   2 0 -1 -1 t p f i f f));
***************
*** 422,428 ****
  DATA(insert OID = 0 ( 1259 relrefs			21 0  2  16 0 -1 -1 t p f s f f));
  DATA(insert OID = 0 ( 1259 relhaspkey		16 0  1  17 0 -1 -1 t p f c f f));
  DATA(insert OID = 0 ( 1259 relhasrules		16 0  1  18 0 -1 -1 t p f c f f));
! DATA(insert OID = 0 ( 1259 relacl		  1034 0 -1  19 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 ctid				27 0  6  -1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 oid				26 0  4  -2 0 -1 -1 t p f i f f));
  DATA(insert OID = 0 ( 1259 xmin				28 0  4  -3 0 -1 -1 t p f i f f));
--- 423,430 ----
  DATA(insert OID = 0 ( 1259 relrefs			21 0  2  16 0 -1 -1 t p f s f f));
  DATA(insert OID = 0 ( 1259 relhaspkey		16 0  1  17 0 -1 -1 t p f c f f));
  DATA(insert OID = 0 ( 1259 relhasrules		16 0  1  18 0 -1 -1 t p f c f f));
! DATA(insert OID = 0 ( 1259 relhassubclass	16 0  1   19 0 -1 -1 t p f c f f));
! DATA(insert OID = 0 ( 1259 relacl		  1034 0 -1  20 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 ctid				27 0  6  -1 0 -1 -1 f p f i f f));
  DATA(insert OID = 0 ( 1259 oid				26 0  4  -2 0 -1 -1 t p f i f f));
  DATA(insert OID = 0 ( 1259 xmin				28 0  4  -3 0 -1 -1 t p f i f f));
Index: pgsql/src/include/catalog/pg_class.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/include/catalog/pg_class.h,v
retrieving revision 1.33
diff -c -r1.33 pg_class.h
*** pgsql/src/include/catalog/pg_class.h	2000/01/26 05:57:57	1.33
--- pgsql/src/include/catalog/pg_class.h	2000/02/05 08:25:09
***************
*** 78,88 ****
  	int2		relrefs;		/* # of references to this relation */
  	bool		relhaspkey;		/* has PRIMARY KEY */
  	bool		relhasrules;
  	aclitem		relacl[1];		/* this is here for the catalog */
  } FormData_pg_class;

#define CLASS_TUPLE_SIZE \
! (offsetof(FormData_pg_class,relhasrules) + sizeof(bool))

  /* ----------------
   *		Form_pg_class corresponds to a pointer to a tuple with
--- 78,89 ----
  	int2		relrefs;		/* # of references to this relation */
  	bool		relhaspkey;		/* has PRIMARY KEY */
  	bool		relhasrules;
+ 	bool		relhassubclass;
  	aclitem		relacl[1];		/* this is here for the catalog */
  } FormData_pg_class;

#define CLASS_TUPLE_SIZE \
! (offsetof(FormData_pg_class,relhassubclass) + sizeof(bool))

  /* ----------------
   *		Form_pg_class corresponds to a pointer to a tuple with
***************
*** 102,109 ****
   *		relacl field.
   * ----------------
   */
! #define Natts_pg_class_fixed			18
! #define Natts_pg_class					19
  #define Anum_pg_class_relname			1
  #define Anum_pg_class_reltype			2
  #define Anum_pg_class_relowner			3
--- 103,110 ----
   *		relacl field.
   * ----------------
   */
! #define Natts_pg_class_fixed			19
! #define Natts_pg_class					20
  #define Anum_pg_class_relname			1
  #define Anum_pg_class_reltype			2
  #define Anum_pg_class_relowner			3
***************
*** 122,128 ****
  #define Anum_pg_class_relrefs			16
  #define Anum_pg_class_relhaspkey		17
  #define Anum_pg_class_relhasrules		18
! #define Anum_pg_class_relacl			19

  /* ----------------
   *		initial contents of pg_class
--- 123,130 ----
  #define Anum_pg_class_relrefs			16
  #define Anum_pg_class_relhaspkey		17
  #define Anum_pg_class_relhasrules		18
! #define Anum_pg_class_relhassubclass		19
! #define Anum_pg_class_relacl			20

  /* ----------------
   *		initial contents of pg_class
***************
*** 135,141 ****
  DESCR("");
  DATA(insert OID = 1255 (  pg_proc 81		  PGUID 0 0 0 0 f f r 16 0 0 0 0 0 f f _null_ ));
  DESCR("");
! DATA(insert OID = 1259 (  pg_class 83		  PGUID 0 0 0 0 f f r 19 0 0 0 0 0 f f _null_ ));
  DESCR("");
  DATA(insert OID = 1260 (  pg_shadow 86		  PGUID 0 0 0 0 f t r 8  0 0 0 0 0 f f _null_ ));
  DESCR("");
--- 137,143 ----
  DESCR("");
  DATA(insert OID = 1255 (  pg_proc 81		  PGUID 0 0 0 0 f f r 16 0 0 0 0 0 f f _null_ ));
  DESCR("");
! DATA(insert OID = 1259 (  pg_class 83		  PGUID 0 0 0 0 f f r 20 0 0 0 0 0 f f _null_ ));
  DESCR("");
  DATA(insert OID = 1260 (  pg_shadow 86		  PGUID 0 0 0 0 f t r 8  0 0 0 0 0 f f _null_ ));
  DESCR("");

--ELM949743062-22250-0_

--ELM949743062-22250-0_--

From bouncefilter Sat Feb 5 05:34:03 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA96124
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 05:33:37 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id TAA07978
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 19:33:36 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-17 [133.137.84.17])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id TAA27230
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 19:33:34 +0900
To: pgsql-hackers@postgresql.org
Subject: TODO item
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000205193719A.t-ishii@sra.co.jp>
Date: Sat, 05 Feb 2000 19:37:19 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 8

In the TODO file:

* -Allow transaction commits with rollback with no-fsync performance [fsync](Vadim)

Has this been done in current? I see almost no performance
improvement on copying data into a table.
--
Tatsuo Ishii

From bouncefilter Sat Feb 5 06:41:04 2000
Received: from hu.tm.ee (ppp919.tele2.ee [212.107.37.219])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA08903
for <hackers@postgresql.org>; Sat, 5 Feb 2000 06:40:49 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id CE16C39DA; Sat, 5 Feb 2000 13:47:50 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389C0DE6.666E1CF4@tm.ee>
Date: Sat, 05 Feb 2000 13:47:50 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris <chris@bitmead.com>
Cc: Don Baccus <dhogaza@pacifier.com>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Patch attached...
References: <3.0.1.32.20000204203823.01030d30@mail.pacifier.com>
<389BBC52.7FBAED10@bitmead.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris wrote:

Don Baccus wrote:

At 02:36 PM 2/5/00 +1100, Chris wrote:

*) The overhead for non-inheritance has
been cut down to 30 microseconds (on a pc).

What kind of PC?

Cerelon 400, 64MB, IDE disk.

Btw, how did you measure that 30us overhead ?

Does it involve disk accesses or is it just in-memory code that
speed-concious folks could move to assembly like current
spinlocking code for some architectures?

-------------
Hannu

From bouncefilter Sat Feb 5 06:56:04 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA10095
for <hackers@postgresql.org>; Sat, 5 Feb 2000 06:55:16 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id WAA24325
for <hackers@postgresql.org>; Sat, 5 Feb 2000 22:55:13 +1100
Sender: chris@tech.com.au
Message-ID: <389C0FA0.488FCC8C@bitmead.com>
Date: Sat, 05 Feb 2000 22:55:12 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Patch attached...
References: <3.0.1.32.20000204203823.01030d30@mail.pacifier.com>
<389BBC52.7FBAED10@bitmead.com> <389C0DE6.666E1CF4@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hannu Krosing wrote:

Btw, how did you measure that 30us overhead ?

I measured it with the test program below. With the latest patch it is
no longer 30us, but as far as I can measure 0us.

Does it involve disk accesses or is it just
in-memory code that
speed-concious folks could move to assembly like current
spinlocking code for some architectures?

For this patch it is an in-memory issue.

--
Chris Bitmead
mailto:chris@bitmead.com

#include <stdio.h>
#include <time.h>
#include "libpq-fe.h"

#define rep 1000000

main() {
int c;
PGconn *conn;
PGresult *res;
time_t t, t2;

conn = PQsetdb(NULL,NULL,NULL,NULL,"foo");
time(&t);
for (c = 0; c < rep; c++) {
res = PQexec(conn, "select * from a*");
PQclear(res);
}
time(&t2);
printf("inh %d\n", t2 - t);
time(&t);
for (c = 0; c < rep; c++) {
res = PQexec(conn, "select * from only a");
PQclear(res);
}
time(&t2);
printf("no inh %d\n", t2 - t);

PQfinish(conn);

}

From bouncefilter Sat Feb 5 06:54:05 2000
Received: from hu.tm.ee (ppp919.tele2.ee [212.107.37.219])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA09941;
Sat, 5 Feb 2000 06:53:44 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id BCADC39DA; Sat, 5 Feb 2000 14:00:52 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389C10F4.63DFB540@tm.ee>
Date: Sat, 05 Feb 2000 14:00:52 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris <chris@bitmead.com>
Cc: Marten Feldtmann <marten@feki.toppoint.de>,
Peter Eisentraut <peter_e@gmx.net>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
Subject: Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL
References: <200002041815.TAA07061@feki.toppoint.de>
<389B8250.EB7CF08A@bitmead.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris wrote:

One very good point is the query language of the
rdbms systems. On the odbms side no standard is
really available, which can be seen as the sql of
the odbms.

There is a standard called OQL which is very similar to SQL. It's just
rather poorly supported.

I think the operative word here is "available". I know that SQL specs
are'nt freely available either, but due to SQL being already widely
supported one can get the general idea from many freely available sources,
like the bunch of freely downloadable DB's currently available for linux.
Most of them have some docs included.

It is still quite a job to reconstruct SQL92 from them ;)

I know now description (except a BNF syntax available from some ODBMS website)
that I could use to get some idea about OQL.

----------------------
Hannu

From bouncefilter Sat Feb 5 07:13:04 2000
Received: from hu.tm.ee (ppp919.tele2.ee [212.107.37.219])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA15985;
Sat, 5 Feb 2000 07:12:21 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 2D8A639DF; Sat, 5 Feb 2000 14:19:31 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389C1553.52D2E7E2@tm.ee>
Date: Sat, 05 Feb 2000 14:19:31 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris <chris@bitmead.com>, Marten Feldtmann <marten@feki.toppoint.de>,
Peter Eisentraut <peter_e@gmx.net>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
Subject: Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL
References: <200002041815.TAA07061@feki.toppoint.de>
<389B8250.EB7CF08A@bitmead.com> <389C10F4.63DFB540@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hannu Krosing wrote:

It is still quite a job to reconstruct SQL92 from them ;)

I know now description (except a BNF syntax available from some ODBMS website)

SHould be "I know no description ..."

that I could use to get some idea about OQL.

----------------------
Hannu

************

From bouncefilter Sat Feb 5 07:27:04 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA18902
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 07:26:50 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id XAA24619
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 23:26:46 +1100
Sender: chris@tech.com.au
Message-ID: <389C1706.9B683710@bitmead.com>
Date: Sat, 05 Feb 2000 23:26:46 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
Subject: Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL
References: <200002041815.TAA07061@feki.toppoint.de>
<389B8250.EB7CF08A@bitmead.com> <389C10F4.63DFB540@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hannu Krosing wrote:

I think the operative word here is "available". I know that SQL specs
are'nt freely available either, but due to SQL being already widely
supported one can get the general idea from many freely available sources,
like the bunch of freely downloadable DB's currently available for linux.
Most of them have some docs included.

It is still quite a job to reconstruct SQL92 from them ;)

I know now description (except a BNF syntax available from some ODBMS website)
that I could use to get some idea about OQL.

Poet at http://www.poet.com have their doco online including OQL.

--
Chris Bitmead
mailto:chris@bitmead.com

From bouncefilter Sat Feb 5 07:30:04 2000
Received: from hu.tm.ee (ppp919.tele2.ee [212.107.37.219])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA20564
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 07:29:02 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 61C863A00; Sat, 5 Feb 2000 14:36:12 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389C193C.4BD71B7C@tm.ee>
Date: Sat, 05 Feb 2000 14:36:12 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris <chris@bitmead.com>
Cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Patch attached...
References: <3.0.1.32.20000204203823.01030d30@mail.pacifier.com>
<389BBC52.7FBAED10@bitmead.com> <389C0DE6.666E1CF4@tm.ee>
<389C0FA0.488FCC8C@bitmead.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

I looked at the patch and for me the name of the variable
to set to get the old behaviour (SET EXAMINE_SUBCLASS TO 'on';)
seems confusing.

At first I thought it was a typo to set it to 'ON' for old behaviour,
my internal logic would set it to 'OFF' to not select subclass by default.

I think something like DONT_SELECT_INHERITED or OLD_INHERITED_SELECT_SYNTAX
would be much clearer in meaning.

Actually the name is not very important, as most people won't use it anyway ;)

----------------
Hannu

From bouncefilter Sat Feb 5 08:13:05 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA38170
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 08:12:58 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id AAA24962
for <hackers@postgreSQL.org>; Sun, 6 Feb 2000 00:12:54 +1100
Sender: chris@tech.com.au
Message-ID: <389C21D5.A2078036@bitmead.com>
Date: Sun, 06 Feb 2000 00:12:53 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Patch attached...
References: <3.0.1.32.20000204203823.01030d30@mail.pacifier.com>
<389BBC52.7FBAED10@bitmead.com> <389C0DE6.666E1CF4@tm.ee>
<389C0FA0.488FCC8C@bitmead.com> <389C193C.4BD71B7C@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hannu Krosing wrote:

Hi

I looked at the patch and for me the name of the variable
to set to get the old behaviour (SET EXAMINE_SUBCLASS TO 'on';)
seems confusing.

At first I thought it was a typo to set it to 'ON' for old behaviour,
my internal logic would set it to 'OFF' to not select subclass by default.

Umm, but that IS how it works...

$ psql
Welcome to psql, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
pghack=# select * from a;
aa
-----
aaa
bbb
(2 rows)

pghack=# set examine_subclass to 'off';
SET VARIABLE
pghack=# select * from a;
aa
-----
aaa
(1 row)

I think something like DONT_SELECT_INHERITED or OLD_INHERITED_SELECT_SYNTAX
would be much clearer in meaning.

I'm happy to hear alternative names, but I don't really want "SELECT" in
the name, because this might apply to UPDATE eventually too.

Actually the name is not very important, as most people won't use it anyway ;)

----------------
Hannu

--
Chris Bitmead
mailto:chris@bitmead.com

From bouncefilter Sat Feb 5 08:27:05 2000
Received: from hu.tm.ee (ppp919.tele2.ee [212.107.37.219])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA43608
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 08:26:04 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 317303A0D; Sat, 5 Feb 2000 15:33:14 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389C2699.B81F5921@tm.ee>
Date: Sat, 05 Feb 2000 15:33:13 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris <chris@bitmead.com>
Cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL
References: <200002041815.TAA07061@feki.toppoint.de>
<389B8250.EB7CF08A@bitmead.com> <389C10F4.63DFB540@tm.ee>
<389C1706.9B683710@bitmead.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris wrote:

Hannu Krosing wrote:

I think the operative word here is "available". I know that SQL specs
are'nt freely available either, but due to SQL being already widely
supported one can get the general idea from many freely available sources,
like the bunch of freely downloadable DB's currently available for linux.
Most of them have some docs included.

It is still quite a job to reconstruct SQL92 from them ;)

I know now description (except a BNF syntax available from some ODBMS website)
that I could use to get some idea about OQL.

Poet at http://www.poet.com have their doco online including OQL.

Thanks, I'll check that.

Btw, has anyone compared PostgreSQL's object features with SQL3 (draft)
features.

For example they seem to use UNDER instead of INHERITS and no parentheses.

They also have a special privilege also called UNDER for being able to define
a subtype (as they call it). A lot of other features seem to be considered too
-
no wonder it is 2.3 MB text file.

available at:

ftp://ftp.digital.com/pub/standards/sql/

or

http://gatekeeper.dec.com/pub/standards/sql/

the main file is sql-foundation-aug94.txt

------------------------
Hannu

From bouncefilter Sat Feb 5 09:38:05 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA83839
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 09:37:44 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12H6J1-0002Wa-00; Sat, 5 Feb 2000 14:35:23 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12H6It-00017v-00; Sat, 5 Feb 2000 14:35:15 +0000
Date: Sat, 5 Feb 2000 14:35:15 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
Message-ID: <20000205143515.F3402@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<1426.949641960@sss.pgh.pa.us>
<20000204171153.D3402@quartz.newn.cam.ac.uk>
<4803.949697937@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <4803.949697937@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Fri, Feb 04, 2000 at 03:58:57PM -0500

On Fri, Feb 04, 2000 at 03:58:57PM -0500, Tom Lane wrote:

Any thoughts on where to look?

Is there anything in the postmaster log?

DEBUG: Data Base System is in production state at Fri Feb 4 17:11:05 2000
Server process (pid 3588) exited with status 11 at Fri Feb 4 17:14:57 2000
Terminating any active server processes...
Server processes were terminated at Fri Feb 4 17:14:57 2000
Reinitializing shared memory and semaphores

Is there a core file (look
in the database subdirectory, ie .../data/base/yourdatabase/core)?

But no core file ... so who knows what the sigsegv comes from. (don't worry
coredumpsize unlimited)

If so, compiling the backend with -g and extracting a backtrace from
the resulting corefile with gdb would be very useful info.

(already have the -g..)

Still looking...

Cheers,

Patrick

From bouncefilter Sat Feb 5 09:39:05 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA85417
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 09:38:36 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA15314;
Sat, 5 Feb 2000 14:46:36 GMT
Sender: lockhart@hub.org
Message-ID: <389C37CC.9C706269@alumni.caltech.edu>
Date: Sat, 05 Feb 2000 14:46:36 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris <chris@bitmead.com>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Patch attached...
References: <3.0.1.32.20000204203823.01030d30@mail.pacifier.com>
<389BBC52.7FBAED10@bitmead.com> <389C0DE6.666E1CF4@tm.ee>
<389C0FA0.488FCC8C@bitmead.com> <389C193C.4BD71B7C@tm.ee>
<389C21D5.A2078036@bitmead.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

pghack=# set examine_subclass to 'off';

I think something like DONT_SELECT_INHERITED or
OLD_INHERITED_SELECT_SYNTAX
would be much clearer in meaning.

I'm happy to hear alternative names, but I don't really want "SELECT" in
the name, because this might apply to UPDATE eventually too.

Hmm. This uncovers our clunky SET syntax. imho this should be a clean
and natural option, not something with a bunch of underscores in the
keyword and a quoted string for the option.

But this is awfully close to beta to be even considering making this
change in default behavior and syntax for 7.0. We've got a lot of
other features to babysit through beta, and this one wasn't even on
the radar until a few days ago...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sat Feb 5 12:04:07 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA98638
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 12:03:55 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA07851;
Sat, 5 Feb 2000 12:02:46 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002051702.MAA07851@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <20000205193719A.t-ishii@sra.co.jp> from Tatsuo Ishii at "Feb 5,
2000 07:37:19 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Sat, 5 Feb 2000 12:02:46 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In the TODO file:

* -Allow transaction commits with rollback with no-fsync performance [fsync](Vadim)

Has this been done in current? I see almost no performance
improvement on copying data into a table.

TODO updated. That was part of MVCC which originally was supposed to be
in 7.0.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Feb 5 12:11:07 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA99447
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 12:10:57 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA07938;
Sat, 5 Feb 2000 12:10:36 -0500 (EST)
To: Chris <chris@bitmead.com>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Status of inheritance-changing patch
In-reply-to: <389B9ACB.9F929BAE@bitmead.com>
References: <389B9ACB.9F929BAE@bitmead.com>
Comments: In-reply-to Chris <chris@bitmead.com>
message dated "Sat, 05 Feb 2000 14:36:43 +1100"
Date: Sat, 05 Feb 2000 12:10:35 -0500
Message-ID: <7935.949770635@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris,
This is to let you know that the core list has discussed this patch,
and we feel that it is not appropriate to apply it at this late stage
in the 7.0 development cycle. There are several reasons for this:

* It appears that making such a definitional change is still
controversial. (One thing that still needs to be looked at is whether
SQL 3 defines any comparable features, and if so whether we ought
to be following their syntax and behavior.)

* The implications of changing this behavior still need to be followed
through in the rest of the system. For example, it doesn't make much
sense to me to change SELECT to have recursive behavior by default when
UPDATE and DELETE can't yet do it at all. A user would naturally
expect "UPDATE table" to scan the same tuples that "SELECT FROM table"
does.

* It's awfully late in the 7.0 development cycle to be making such a
significant change. We have only ten days left to scheduled beta,
which is not enough time to find and work out any unexpected problems
that may be lurking.

We encourage you to continue to work on this line of development,
but with an eye to merging your code into CVS early in the 7.1 cycle,
rather than trying to squeeze it into 7.0 at the last minute.

regards, tom lane

From bouncefilter Sat Feb 5 12:19:07 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA00546
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 12:18:33 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA07991;
Sat, 5 Feb 2000 12:18:30 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <20000205143515.F3402@quartz.newn.cam.ac.uk>
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<1426.949641960@sss.pgh.pa.us>
<20000204171153.D3402@quartz.newn.cam.ac.uk>
<4803.949697937@sss.pgh.pa.us>
<20000205143515.F3402@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Sat, 05 Feb 2000 14:35:15 +0000"
Date: Sat, 05 Feb 2000 12:18:29 -0500
Message-ID: <7988.949771109@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

Is there anything in the postmaster log?

DEBUG: Data Base System is in production state at Fri Feb 4 17:11:05 2000
Server process (pid 3588) exited with status 11 at Fri Feb 4 17:14:57 2000

But no core file ... so who knows what the sigsegv comes from. (don't worry
coredumpsize unlimited)

There sure oughta be a corefile after a SIGSEGV. Hmm. How are you
starting the postmaster --- is it from a system startup script?
It might work better to start it from an ordinary user process.
I discovered the other day on a Linux box that the system just plain
would not dump a core file from a process started by root, even though
the process definitely had nonzero "ulimit -c" and had set its euid
to a nonprivileged userid. But start the same process by hand from an
unprivileged login, and it would dump a core file. Weird. Dunno if
your platform behaves the same way, but it's worth trying.

regards, tom lane

From bouncefilter Sat Feb 5 13:16:09 2000
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA18890
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 13:15:42 -0500 (EST)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id VAA26643
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 21:15:35 +0300 (GMT)
Date: Sat, 5 Feb 2000 21:15:35 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
Reply-To: Oleg Bartunov <oleg@sai.msu.su>
To: pgsql-hackers@postgreSQL.org
Subject: Linux MANDRAKE startup startup script is broken ?
Message-ID: <Pine.GSO.3.96.SK.1000205210347.22044F-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

I had a request from bulgarian user of postgres. He complained
about non-working locale. His system is MANDRAKE 7.0 which comes
with postgres 6.5.3 I believe. After several messages we found
that problem was in startup script /etc/init.d/rc3.d
su -l postgres -c 'postmaster .......'
The problem was '-l', after removing it all problems were solved !
I'm not an expert in su, at least I don't know what '-l' is supposed
for, but it's worth to describe the problem and let people from
MANDRAKE to know.

Regards,

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Sat Feb 5 14:23:13 2000
Received: from hu.tm.ee (ppp935.tele2.ee [212.107.37.235])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA34682
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 14:23:04 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 1302039CB; Sat, 5 Feb 2000 21:30:16 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389C7A47.296E1A87@tm.ee>
Date: Sat, 05 Feb 2000 21:30:15 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris <chris@bitmead.com>
Cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Patch attached...
References: <3.0.1.32.20000204203823.01030d30@mail.pacifier.com>
<389BBC52.7FBAED10@bitmead.com> <389C0DE6.666E1CF4@tm.ee>
<389C0FA0.488FCC8C@bitmead.com> <389C193C.4BD71B7C@tm.ee>
<389C21D5.A2078036@bitmead.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris wrote:

Hannu Krosing wrote:

Hi

I looked at the patch and for me the name of the variable
to set to get the old behaviour (SET EXAMINE_SUBCLASS TO 'on';)
seems confusing.

At first I thought it was a typo to set it to 'ON' for old behaviour,
my internal logic would set it to 'OFF' to not select subclass by default.

Umm, but that IS how it works...

I don't contest that ;)

I think something like DONT_SELECT_INHERITED or OLD_INHERITED_SELECT_SYNTAX
would be much clearer in meaning.

I'm happy to hear alternative names, but I don't really want "SELECT" in
the name, because this might apply to UPDATE eventually too.

Oops, I didnt think of that.

Of course it should actually apply to all four (SELECT, UPDATE, SELETE,
INSERT)
as wellas DDL statements (ALTER TABLE ADD/DROP xxx, CREATE
CONSTRAINT/INDEX/RULE/TRIGGER)

------------------
Hannu

From bouncefilter Sat Feb 5 14:48:11 2000
Received: from hu.tm.ee (ppp935.tele2.ee [212.107.37.235])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA40843
for <hackers@postgresql.org>; Sat, 5 Feb 2000 14:47:56 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 9116239CB; Sat, 5 Feb 2000 21:55:05 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389C8019.92DEDED9@tm.ee>
Date: Sat, 05 Feb 2000 21:55:05 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Chris <chris@bitmead.com>, Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Status of inheritance-changing patch
References: <389B9ACB.9F929BAE@bitmead.com> <7935.949770635@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Chris,
This is to let you know that the core list has discussed this patch,
and we feel that it is not appropriate to apply it at this late stage
in the 7.0 development cycle.

Here you see Chris what happens when you try to force the default
behaviour be the "wrong" way :-p

But seriously, we could still warn people about current (mis)use of
inheritance and that it may be soon be changed/deprecated or "made
compatible with Informix" whichever seems most PC.

There are several reasons for this:

* It appears that making such a definitional change is still
controversial. (One thing that still needs to be looked at is whether
SQL 3 defines any comparable features,

It does define "comparable" features, but moves away from out nice clean
SQL92 worldview quite radically.

and if so whether we ought
to be following their syntax and behavior.)

I agree that some discussion about OQL vs. SQL3 would be in place.

* The implications of changing this behavior still need to be followed
through in the rest of the system. For example, it doesn't make much
sense to me to change SELECT to have recursive behavior by default when
UPDATE and DELETE can't yet do it at all. A user would naturally
expect "UPDATE table" to scan the same tuples that "SELECT FROM table"
does.

That's true. I would like to see INSERT,UPDATE,DELETE and SELECT be
updated together.

Fixing ALTER TABLE behaviour is not so important as we are just getting
most of it done for plain SQL92 by 7.0.

* It's awfully late in the 7.0 development cycle to be making such a
significant change. We have only ten days left to scheduled beta,
which is not enough time to find and work out any unexpected problems
that may be lurking.

Also - fixing object DB behaviours would give us reason to move to 8.x
faster ;)

We encourage you to continue to work on this line of development,
but with an eye to merging your code into CVS early in the 7.1 cycle,
rather than trying to squeeze it into 7.0 at the last minute.

But could we then disable the current half-hearted OO for the time being
to avoid more compatibility problems from people who might err to use it.

If there is serious attempt to put the O back in ORDBMS we should not let
compatibility with non-SQL postgres extensions to be a decisive fact.

But then again that kind of change is best done at a major number change.

--------------------
Hannu

From bouncefilter Sat Feb 5 15:16:09 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id PAA84542
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 15:15:12 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12HBRI-0003kMC; Sat, 5 Feb 100 21:04 MET
Message-Id: <m12HBRI-0003kMC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: FOREIGN KEY !!!!!
To: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Date: Sat, 5 Feb 2000 21:04:16 +0100 (CET)
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

We got a little dispute in the FKEY project :-)

In section 11.9, the SQL3 draft explicitly discribes what to
do for referential actions ON DELETE and ON UPDATE. First
there seems to be an incompatibility between SQL3 and SQL-92.
While Date describes and Oracle implements NO ACTION to raise
an exception if a PK delete leaves an unsatisfied foreign
key, the SQL3 specs explicitly define that behaviour for the
RESTRICT action.

Second, there's absolutely nothing said about anything to do
for NO ACTION in SQL3. Thus, our current implementaion in
fact doesn't do anything meaningful. That makes it totally
legal, to delete a PK leaving an unsatisfied FK behind,
resulting in an in fact violation. And NO ACTION is the
default if no referential actions given explicitly in the
schema.

Don Baccus now suggested, to interpret NO ACTION as "if it
would result in a violation, then silently rollback this
update for the PK row in question". Not to speak about the
technical problems arising from an attempt to do so, but as
said, such a behaviour is nowhere mentioned in the SQL3
draft. OTOH it would close the possible violation hole in
our implementation of FOREIGN KEY.

What do others think about it? We need a decision urgent, or
going for the suppress/rollback will cause a release delay,
definitely.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Sat Feb 5 15:36:10 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA86890
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 15:30:20 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA26757;
Sat, 5 Feb 2000 12:29:52 -0800 (PST)
Message-Id: <3.0.1.32.20000205122738.007a43e0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 05 Feb 2000 12:27:38 -0800
To: Jan Wieck <wieck@debis.com>,
PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] FOREIGN KEY !!!!!
In-Reply-To: <m12HBRI-0003kMC@orion.SAPserv.Hamburg.dsh.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:04 PM 2/5/00 +0100, Jan Wieck wrote:

We got a little dispute in the FKEY project :-)

Etc...Jan and I have crossed a couple of e-mails.

After he and I tossed our thoughts back-and-forth it appeared
to both of us that SQL3 seemed to be defining "NO ACTION"
differently than in SQL92.

Then I remembered that Date's SQL92 primer has an appendix
on SQL3. I could've saved us all a bunch of trouble if I
remembered earlier...

By the time you and I read this, Jan and I might well be in
"what exactly should we implement now that we know how it is
SUPPOSED to work" mode, rather than "how is it supposed to
work?" mode.

For those into self-flagellation and other forms of self-inflicted
pain, spend an hour or so with the SQL3 standard trying to figure
out how "NO ACTION" is supposed to work and how it differs from
"RESTRICT" before cheating and reading this excerpt from Date.

Here's my note to Jan that he didn't quite have a chance to read
before posting to the hacker's list:

"OK, mystery solved, I remembered that Date has an appendix on SQL3.
Fortunately, he has a short section on "RESTRICT" vs. "NO ACTION".

We're all wrong :)

From his SQL3 appendix...

F.4 INTEGRITY

Referential Action RESTRICT

In addition to ... CASCADE, SET NULL [etc] ... SQL3 supports
a new [referential action] RESTRICT. RESTRICT is very similar - but
not quite identical - to NO ACTION. The subtle difference between
them is as follows. Note: to fix our ideas, we concentrate here
on the delete rule; the implications for the update rule are
essentially similar.

o Let T1 and T2 be the referenced table and the referencing
table, respectively; let R1 be a row of T1, let R2 be a row
of T2 that corresponds to row R1 under the referential
constraint in question. What happens if an attempt is made
to delete row R1?

o Under NO ACTION [equiv. to SQL92] the system - conceptually,
at least - actually performs the requested DELETE, discovers
row R2 now violates the constraint, and so undoes the DELETE.

o Under RESTRICT, by contrast, the system realizes "ahead of
time" that row R2 exists and will violate the constraint if
R1 is deleted, and so rejects the DELETE out of hand.
"

The standard also mentions (I've dug around a bit) that RESTRICT
raises a "restrict violation" exception. The "NO ACTION" case
conceptually might raise an "integrity constraint violation"
instead, and perhaps to be compliant MUST raise that constraint.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Feb 5 15:42:10 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id PAA90693
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 15:41:10 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12HBqG-0003kMC; Sat, 5 Feb 100 21:30 MET
Message-Id: <m12HBqG-0003kMC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] FOREIGN KEY !!!!!
In-Reply-To: <3.0.1.32.20000205122738.007a43e0@mail.pacifier.com> from Don
Baccus at "Feb 5, 2000 12:27:38 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Sat, 5 Feb 2000 21:30:04 +0100 (CET)
CC: Jan Wieck <wieck@debis.com>,
PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

o Under RESTRICT, by contrast, the system realizes "ahead of
time" that row R2 exists and will violate the constraint if
R1 is deleted, and so rejects the DELETE out of hand.

That'd mean in last consequence, that RESTRICT actions aren't
DEFERRABLE, while the rest of their constraint definition is!
Anyway, cannot work with the actual implementation of the
trigger queue, so we could either make RESTRICT and NO ACTION
identical (except for different ERROR messages), or leave the
SQL3 RESTRICT out of 7.0 while changing NO ACTION to fire the
message.

I'd prefer to have them identical in 7.0, because according
to Date they have no semantic difference, so it'll buy us
little if we complicate the trigger stuff more than required
right now.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Sat Feb 5 15:38:10 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA90258
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 15:37:21 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id PAA07897;
Sat, 5 Feb 2000 15:37:08 -0500
Message-ID: <389C89EC.1CEA2D16@wgcr.org>
Date: Sat, 05 Feb 2000 15:37:00 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Oleg Bartunov <oleg@sai.msu.su>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Linux MANDRAKE startup startup script is broken ?
References: <Pine.GSO.3.96.SK.1000205210347.22044F-100000@ra>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oleg Bartunov wrote:

Hi,

I had a request from bulgarian user of postgres. He complained
about non-working locale. His system is MANDRAKE 7.0 which comes
with postgres 6.5.3 I believe. After several messages we found
that problem was in startup script /etc/init.d/rc3.d
su -l postgres -c 'postmaster .......'
The problem was '-l', after removing it all problems were solved !

?!?!?!? Do something for me: add a couple of lines in
/etc/rc.d/init.d/postgresql after the postmaster start:
su -l postgres -c 'set >/var/lib/pgsql/envvars-l.lst'
su postgres -c 'set >/var/lib/pgsql/envvaqrs-no-l.lst'

And e-mail me the two '*.lst' files out of /var/lib/pgsql.

I'm not an expert in su, at least I don't know what '-l' is supposed

From man su:

SU(1) FSF SU(1)

NAME
su - run a shell with substitute user and group IDs

SYNOPSIS
su [OPTION]... [-] [USER [ARG]...]

DESCRIPTION
Change the effective user id and group id to that of USER.

-, -l, --login
make the shell a login shell
......

for, but it's worth to describe the problem and let people from
MANDRAKE to know.

The same problem should manifest itself in RedHat, which is what I build
the RPM's for. Mandrake has been taking the RedHat RPM's and using
them, with modifications, up till now, so, if I fix this in the RedHat
RPM's, the Mandrake RPM's will follow from Mandrake shortly.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Sat Feb 5 15:52:10 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA92245
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 15:50:36 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA02181;
Sat, 5 Feb 2000 12:49:54 -0800 (PST)
Message-Id: <3.0.1.32.20000205124742.00f991e0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 05 Feb 2000 12:47:42 -0800
To: Jan Wieck <wieck@debis.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] FOREIGN KEY !!!!!
Cc: Jan Wieck <wieck@debis.com>,
PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
In-Reply-To: <m12HBqG-0003kMC@orion.SAPserv.Hamburg.dsh.de>
References: <3.0.1.32.20000205122738.007a43e0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:30 PM 2/5/00 +0100, Jan Wieck wrote:

o Under RESTRICT, by contrast, the system realizes "ahead of
time" that row R2 exists and will violate the constraint if
R1 is deleted, and so rejects the DELETE out of hand.

That'd mean in last consequence, that RESTRICT actions aren't
DEFERRABLE, while the rest of their constraint definition is!

That's how I read it, too. Pardon me while I run off to vomit in
the toilet.

Anyway, cannot work with the actual implementation of the
trigger queue, so we could either make RESTRICT and NO ACTION
identical (except for different ERROR messages), or leave the
SQL3 RESTRICT out of 7.0 while changing NO ACTION to fire the
message.

I'd prefer to have them identical in 7.0, because according
to Date they have no semantic difference, so it'll buy us
little if we complicate the trigger stuff more than required
right now.

If others on the list agree, I think this is an excellent idea. I
see no semantic difference that the application will see, either,
other than a difference in execution time.

Raising the exception before the delete or update seems more an efficiency
hack than anything, i.e. it's much less expensive to short-circuit the
delete/update rather than finish it, check afterwards, and roll it
back.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Feb 5 15:56:10 2000
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA93060
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 15:55:40 -0500 (EST)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id XAA05938;
Sat, 5 Feb 2000 23:54:27 +0300 (GMT)
Date: Sat, 5 Feb 2000 23:54:27 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: lory@mobikom.bg, pgsql-hackers@postgresql.org
cc: lamar.owen@wgcr.org
Subject: Re: [HACKERS] Linux MANDRAKE startup startup script is broken ? (fwd)
Message-ID: <Pine.GSO.3.96.SK.1000205234036.3191A-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Lory,

here is what people, responsible (for RPMs) suggested to do.
As I'm not a MANDRAKE user could you please to do
what Lamar requested and send results to him.

Regards,

Oleg

PS.
Lamar, my Slackware 7.0 has:
NAME
su - Change user ID or become super-user

SYNOPSIS
su [-] [username [args]]

But you're right about su from GNU Shell Utilities - it has -l option

If MANDRAKE is just a modified Redhat distribution probable I know
possible reason why Lory's setup didn't works.
I remember I had problem with Redhat 6.1 startup files on some
system (I didn't install Redhat). It's /etc/sysconfig/i18n which was
didn't configured properly. I spent several hours trying to figured out
why compiled postgres wont' work properly with locale I directly
specified in postgres starting script. I found LC_ALL was specified
as 'C' (or something else by default, dont' remember) and LC_ALL has
higher precendence than LC_CTYPE, LC_COLLATE, LANG which were
specified in the script. So I just redefine LC_ALL as LC_CTYPE, LC_COLLATE,
LANG and everything become fine. I still don't understand LC_ALL
but I think it's worth to mention somewhere about this possible
source of confusion for Redhat people.

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

---------- Forwarded message ----------
Date: Sat, 05 Feb 2000 15:37:00 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
To: Oleg Bartunov <oleg@sai.msu.su>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Linux MANDRAKE startup startup script is broken ?

Oleg Bartunov wrote:

Hi,

I had a request from bulgarian user of postgres. He complained
about non-working locale. His system is MANDRAKE 7.0 which comes
with postgres 6.5.3 I believe. After several messages we found
that problem was in startup script /etc/init.d/rc3.d
su -l postgres -c 'postmaster .......'
The problem was '-l', after removing it all problems were solved !

?!?!?!? Do something for me: add a couple of lines in
/etc/rc.d/init.d/postgresql after the postmaster start:
su -l postgres -c 'set >/var/lib/pgsql/envvars-l.lst'
su postgres -c 'set >/var/lib/pgsql/envvaqrs-no-l.lst'

And e-mail me the two '*.lst' files out of /var/lib/pgsql.

I'm not an expert in su, at least I don't know what '-l' is supposed

From man su:

SU(1) FSF SU(1)

NAME
su - run a shell with substitute user and group IDs

SYNOPSIS
su [OPTION]... [-] [USER [ARG]...]

DESCRIPTION
Change the effective user id and group id to that of USER.

-, -l, --login
make the shell a login shell
......

for, but it's worth to describe the problem and let people from
MANDRAKE to know.

The same problem should manifest itself in RedHat, which is what I build
the RPM's for. Mandrake has been taking the RedHat RPM's and using
them, with modifications, up till now, so, if I fix this in the RedHat
RPM's, the Mandrake RPM's will follow from Mandrake shortly.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Sat Feb 5 16:02:12 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA97024
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 16:01:15 -0500 (EST)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id XAA09329;
Sat, 5 Feb 2000 23:56:11 +0300 (MSK)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: (from dms@localhost)
by woland.wplus.net (8.9.3/8.9.1/wplus.2) id AAA27939;
Sun, 6 Feb 2000 00:01:09 +0300 (MSK)
Message-ID: <XFMail.20000206000109.dms@wplus.net>
X-Mailer: XFMail 1.4.4 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.GSO.3.96.SK.1000205210347.22044F-100000@ra>
Date: Sun, 06 Feb 2000 00:01:09 +0300 (MSK)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Oleg Bartunov <oleg@sai.msu.su>
Subject: RE: [HACKERS] Linux MANDRAKE startup startup script is broken ?
Cc: pgsql-hackers@postgreSQL.org

On 05-Feb-2000 Oleg Bartunov wrote:

Hi,

I had a request from bulgarian user of postgres. He complained
about non-working locale. His system is MANDRAKE 7.0 which comes
with postgres 6.5.3 I believe. After several messages we found
that problem was in startup script /etc/init.d/rc3.d
su -l postgres -c 'postmaster .......'
The problem was '-l', after removing it all problems were solved !
I'm not an expert in su, at least I don't know what '-l' is supposed
for, but it's worth to describe the problem and let people from
MANDRAKE to know.

Switch -l cause su to emulate login procedure,
i.e rewrite all environment.
I use simple program to avoid such kind of collision,
and apropriate startup script

(see below sign)

--
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

==================== cat ===========================
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <unistd.h>
#include <pwd.h>

int main(int argc, char *argv[])
{
struct passwd *pw;
uid_t u;

if (!argv[1]"CREATE TABLE USArrests (State varchar(255) ,Murder varchar(255) ,Assault varchar(255) ,UrbanPop varchar(255) ,Rape varchar(255) )" /* This is a debugging output showing the exact request sent to PosstgreSQL, minus the ending semicolumn. Yes the types are ridiculous, and that's what I'm trying to fix ... */ Error in sqlColumns(channel, tablename) : USArrests :table not found on channel 0 /* This is an (unexpected) error message*/)
{ fprintf(stderr,"usage: su_postgres command\n");
exit(0);
}

pw = getpwnam("postgres");
if (!pw)
{ fprintf(stderr, "user postgres doesn't exist\n");
exit(0);
}
setuid(pw->pw_uid);
seteuid(pw->pw_uid);

u = geteuid();
if( u != pw->pw_uid)
{ fprintf(stderr,"Can\'t change uid to %d\n", pw->pw_uid);
exit(0);
}
system(argv[1]"CREATE TABLE USArrests (State varchar(255) ,Murder varchar(255) ,Assault varchar(255) ,UrbanPop varchar(255) ,Rape varchar(255) )" /* This is a debugging output showing the exact request sent to PosstgreSQL, minus the ending semicolumn. Yes the types are ridiculous, and that's what I'm trying to fix ... */ Error in sqlColumns(channel, tablename) : USArrests :table not found on channel 0 /* This is an (unexpected) error message*/);

}

=================================================================
# $Id: S81pgsql.in,v 1.2 1999/08/31 14:21:19 dms Exp $

PG_HOME="/usr/local/pgsql"
PG_DATA="$PG_HOME/data"
UDS="/tmp/.s.PGSQL.5432"

PS="@PS@"
GREP="@GREP@"

case "$1" in
'start')
# If no postgres run, remove UDS and start postgres.
pid=
set -- `$PS | $GREP postmaster | $GREP -v grep`
[ $? -eq 0 ] && pid=$1

if [ -z "$pid" ]; then
rm -f "$UDS"
$PG_HOME/bin/su_postgres "$PG_HOME/bin/postmaster -D $PG_DATA -b
$PG_HOME/bin/postgres -i -S -o -F &"
echo "Postgres started"
else
echo "Postmaster already run with pid $pid"
fi
;;
'stop')
pid=
set -- `$PS | $GREP postmaster | $GREP -v grep`
[ $? -eq 0 ] && pid=$1

if [ -z "$pid" ]; then
echo "Postgres not run"
else
echo "Stoping postmaster with pid $pid"
kill $pid
fi

;;
*)
echo "USAGE: $0 {start | stop}"
;;
esac

=================================================================

From bouncefilter Sat Feb 5 16:30:10 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA01126
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 16:29:56 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id QAA14604
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 16:29:27 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Proposal for new SET variables for optimizer costs
Date: Sat, 05 Feb 2000 16:29:26 -0500
Message-ID: <14601.949786166@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I am about to implement some changes to the planner/optimizer's cost
model, following up to the thread on pghackers beginning on 20 Jan.
The main conclusion of that thread was that we needed to charge more for
a page fetched nonsequentially than for a page fetched sequentially.
After further investigation I have concluded that it is also appropriate
to include explicit modeling of the cost of evaluation of WHERE clauses.
For example, using the regression database and a query like

select * from tenk1 where
(unique1 = 1 and unique2 = 101) or
(unique1 = 2 and unique2 = 102) or
(unique1 = 3 and unique2 = 103) or
... 100 OR clauses ...
(unique1 = 100 and unique2 = 200);

(which is not too implausible for certain automatic query generators),
I observe that a sequential scan takes about 6 seconds, vs. less than
a second for a similar query with only 10 clauses. That says that the
cost of evaluating a WHERE clause this large is far from negligible.
The optimizer needs to account for this because different query plans
can have a considerable impact on the number of tuples that the WHERE
clause is evaluated for --- in this example, if we use indexscans to
pull out just the tuples with the right values of 'unique1', then the
WHERE clause need only be checked at 100 tuples, not all 10000.

I believe it would be reasonable to charge a certain amount per operator
or function appearing in the WHERE clause in order to account for this
effect. (Currently I see no need to model the cost of evaluating the
targetlist expressions. The same expressions should get evaluated for
the same tuples no matter what query plan the optimizer picks, so we
might as well just leave that cost out of our comparisons.)

Also, as was previously mentioned on pghackers, I would like to add SET
variables to control enabling/disabling of particular query plan types,
so that different plans can be checked with less hassle than restarting
psql with a new PGOPTIONS setting.

This all leads to the following proposal for redoing the optimizer
plan cost SET variables. The variables proposed below would replace
COST_HEAP and COST_INDEX, which are poorly named IMHO and are definitely
very misleadingly documented at present.

(Note that all costs will still be referenced to the cost of a disk page
fetch. We will take 1.0 as the cost of a sequential page fetch.)

SET variable name Internal variable Proposed default

RANDOM_PAGE_COST random_page_cost 4.0

Cost of fetching a disk block nonsequentially (as a multiple of the cost
of a sequential block fetch).

CPU_TUPLE_COST cpu_tuple_cost 0.01

Cost of CPU time per tuple processed within a query (as a fraction of
the cost of a sequential disk block fetch). This renames the existing
SET variable COST_HEAP (cpu_page_weight); but the default value is
smaller than it used to be, since WHERE clause evaluation will now be
accounted for separately.

CPU_INDEX_TUPLE_COST cpu_index_tuple_cost 0.001

Cost of CPU time per index tuple processed within a query (as a fraction
of the cost of a sequential disk block fetch). This renames the
existing SET variable COST_INDEX (cpu_index_page_weight); but the
default value is much smaller than it used to be, since the operator
evaluation cost will account for the bulk of the cost of visiting an
index tuple.

CPU_OPERATOR_COST cpu_operator_cost 0.0025

Cost of CPU time per operator or function evaluated in a WHERE clause.
Note that this would apply to operators evaluated at index tuples as
well as those evaluated against heap tuples.
(The proposed default corresponds to a ratio of 5 microsec against 2
millisec for a sequential block fetch, which seems to be about right
on my workstation.)

ENABLE_SEQSCAN enable_seqscan ON

ENABLE_INDEXSCAN enable_indexscan ON

ENABLE_TIDSCAN enable_tidscan ON

ENABLE_SORT enable_sort ON

ENABLE_NESTLOOP enable_nestloop ON

ENABLE_MERGEJOIN enable_mergejoin ON

ENABLE_HASHJOIN enable_hashjoin ON

Provide access via SET to the already-existing internal optimizer
control flags.

Currently, it is possible to have COST_HEAP and COST_INDEX set
automatically during connection startup; libpq will do that if
the environment variables PGCOSTHEAP and/or PGCOSTINDEX are defined
on the client side. If we want to continue that behavior, the
environment variables for these variables would be named
PGRANDOMPAGECOST etc (remove underscores and prepend PG).
I'm not sure if we want to continue inventing client-side environment
variables, however.

Comments? Ideas for better names? Anyone object to renaming the
existing variables? (BTW, although it could be argued that this
might break existing scripts that set COST_HEAP or COST_INDEX,
I doubt that there are any ... and given the existing doco,
I doubt even more that anyone is setting appropriate values ...)

regards, tom lane

From bouncefilter Sat Feb 5 17:03:11 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA12686
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 17:02:21 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA07126;
Sat, 5 Feb 2000 17:01:59 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002052201.RAA07126@candle.pha.pa.us>
Subject: Re: [HACKERS] Proposal for new SET variables for optimizer costs
In-Reply-To: <14601.949786166@sss.pgh.pa.us> from Tom Lane at "Feb 5,
2000 04:29:26 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 5 Feb 2000 17:01:59 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Looks great. I wouldn't change a thing in your proposal.

I am about to implement some changes to the planner/optimizer's cost
model, following up to the thread on pghackers beginning on 20 Jan.
The main conclusion of that thread was that we needed to charge more for
a page fetched nonsequentially than for a page fetched sequentially.
After further investigation I have concluded that it is also appropriate
to include explicit modeling of the cost of evaluation of WHERE clauses.
For example, using the regression database and a query like

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Feb 5 17:13:11 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA14110
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 17:12:18 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id RAA08004
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 17:12:25 -0500
Message-ID: <389CA040.D5CBC94F@wgcr.org>
Date: Sat, 05 Feb 2000 17:12:16 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Spoke too soon (was RE: cvs committers digest)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lamar Owen wrote, in a misguided moment: (:-/)

I also track the current CVS -- but for a totally different reason, as I
want to be able to release RPMs of the beta release the same day as the
beta release -- thus, I am doing trial builds of RPM's against the CVS.
However, this current issue doesn't impact me in the slightest -- which
is why I have not and will not say anything about it.

I am now saying something about it. While I have been doing trial
builds of the current sources, I have not been building all the clients
up until today, for speed in building. And guess what -- the lack of
pqbool breaks the perl5 client. Badly. Won't-even-compile-badly.

Is this breakage going to be fixed by the 15th? If not, what can I do
to workaround it until it is fixed properly (either by putting pqbool
back in libpq-fe.h, or by fixing Pg.xs to not need pqbool).

I _would_ like to have RPM's ready of the beta on the release day....

TIA

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Sat Feb 5 17:27:11 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA16063
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 17:26:24 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA15001;
Sat, 5 Feb 2000 17:26:06 -0500 (EST)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Spoke too soon (was RE: cvs committers digest)
In-reply-to: <389CA040.D5CBC94F@wgcr.org>
References: <389CA040.D5CBC94F@wgcr.org>
Comments: In-reply-to Lamar Owen <lamar.owen@wgcr.org>
message dated "Sat, 05 Feb 2000 17:12:16 -0500"
Date: Sat, 05 Feb 2000 17:26:06 -0500
Message-ID: <14998.949789566@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Lamar Owen <lamar.owen@wgcr.org> writes:

And guess what -- the lack of
pqbool breaks the perl5 client. Badly. Won't-even-compile-badly.

Yeah, that was pointed out already. I am of the opinion that both
that change and removal of the "obsolete" print functions should be
reverted, but I haven't done so --- I was sort of expecting Peter
to take care of it.

Is this breakage going to be fixed by the 15th?

Someone will do something about it ;-)

regards, tom lane

From bouncefilter Sat Feb 5 17:43:11 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA22189
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 17:42:42 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id RAA08055;
Sat, 5 Feb 2000 17:39:41 -0500
Message-ID: <389CA6A4.982BFC17@wgcr.org>
Date: Sat, 05 Feb 2000 17:39:32 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Spoke too soon (was RE: cvs committers digest)
References: <389CA040.D5CBC94F@wgcr.org> <14998.949789566@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

And guess what -- the lack of
pqbool breaks the perl5 client. Badly. Won't-even-compile-badly.

Yeah, that was pointed out already.

IIRC, it was Hiroshi. I remembered the post, went to the archives, and
pulled it up to double-check. So, I thought I'd just put out a feeler
to see how I needed to allocate my time -- if it's fixed soon, I'll just
put the 7.0 RPM's on my back burner today, and wait on the fix --
otherwise, I'm going to go back to building without the perl client for
now for my testing, as I have several other issues to deal with.

I am of the opinion that both
that change and removal of the "obsolete" print functions should be
reverted, but I haven't done so --- I was sort of expecting Peter
to take care of it.

Well, after following the thread down a ways, I saw his reply to Hiroshi
stating to the effect that he was going to take off for a bit, but that
he'd be back. Probably needed a breather.

Is this breakage going to be fixed by the 15th?

Someone will do something about it ;-)

I have a poem about Someone, Everyone, and Anyone.... Thanks, Tom. If
I need to just apply a patch for build purposes, that's fine. I'm just
trying to get my build-act together, as 7.0 is quite different from a
packaging standpoint than 6.5.x, at least from 'my' packaging
standpoint.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Sat Feb 5 17:56:13 2000
Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net
[194.217.242.91]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA23730
for <hackers@postgresql.org>; Sat, 5 Feb 2000 17:55:37 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1)
id 12HE73-0003Pp-0X
for hackers@postgreSQL.org; Sat, 5 Feb 2000 22:55:33 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id WAA11394; Sat, 5 Feb 2000 22:55:21 GMT
Message-Id: <200002052255.WAA11394@mtcc.demon.co.uk>
Date: Sat, 5 Feb 2000 22:55:21 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Solaris regression tests.
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY=Swarm_of_Insects_211_000
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

--Swarm_of_Insects_211_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: UVi/drDgm5pr042Mk2CVrw==

Hi,

Solaris has always had problems with 1947 in the
regression tests so I prepared a set of expected
files to make things look OK.

There's also a file to account for minor variations
in the geopmetry output and a resultmap patch to
pull them all together.

With these changes PostgreSQL, from CVS, builds and
regression tests (runcheck) cleanly.

Keith.

--Swarm_of_Insects_211_000
Content-Type: TEXT/plain; name="resultmap.patch"; charset=us-ascii;
x-unix-mode=0644
Content-Description: resultmap.patch
Content-MD5: MKPxJQj4yhDHRAdtEJG/3Q==

*** src/test/regress/resultmap.orig	Tue Jan 25 20:29:28 2000
--- src/test/regress/resultmap	Sun Jan 30 11:56:04 2000
***************
*** 4,10 ****
--- 4,16 ----
  int4/.*-netbsd=int4-too-large
  int2/i.86-pc-linux-gnulibc=int2-not-representable
  int4/i.86-pc-linux-gnulibc=int4-not-representable
+ int2/sparc-sun-solaris=int2-too-large
+ int4/sparc-sun-solaris=int4-too-large
  geometry/hppa=geometry-positive-zeros
  geometry/.*-netbsd=geometry-positive-zeros
  geometry/i.86-.*-gnulibc=geometry-i86-gnulibc
+ geometry/sparc-sun-solaris=geometry-solaris-precision
  horology/hppa=horology-no-DST-before-1970
+ horology/sparc-sun-solaris=horology-solaris-1947
+ abstime/sparc-sun-solaris=abstime-solaris-1947
+ tinterval/sparc-sun-solaris=tinterval-solaris-1947

--Swarm_of_Insects_211_000
Content-Type: APPLICATION/octet-stream; name="solaris_regress.tar.gz";
x-unix-mode=0644
Content-Transfer-Encoding: BASE64
Content-Description: solaris_regress.tar.gz
Content-MD5: PA047I9ZFMwN2LbF5cM5qg==

H4sICEoPlDgAA3NvbGFyaXNfcmVncmVzcy50YXIA7X1rcxs3sqi/rn7FVFJ1
JCUkDWDeiu2NHWuzOeXYubZy9qa2tlK0RNncI5NaknKirdT97bcbGMwAGAyA
4dCys+Fs1iIH/QAa3Y0G0ADXq/P7m9l6c381e7Oardf3Z79ez843s4v7b5er
5dXyze14vbyarubrMS2TfLK82dzr+xBKSJYk9wghNCP8L3xi4i+LWZxm90hO
EhbHlOVQzlhM4nsR6c1pi+dmvZmuouje9XK9QQl0wQHY5eVdVOhun/H4YDyO
/vri5YtnL7796YB/xTcX081sM383G0X47/p6uohACTZv38Hbc4R5dfrs9Juz
Gi46pGWZjUk8JvQwGjdYhzRaz86Xi4vD6PGr6LO/zF5HrPzsq4NIecRL9Q1w
cD0H0dnbG4nG4pO0hP8irEH0w6uzgyMarZa/HB9YK1kGVrKwVbLoVclXNwuJ
play9FSSgVncoSRvZi1JYg1CJEkZr+SXWiXfLRebt1BxvbpPZ+dRTI3qipe9
qvuX1VyiOWT6zcvTx2en0dnjJ8/g39Pvf/j5KXw/++770+joktbNOP4Kdf3N
bBOtl9Co8+niYo5l0XxxfbOJ3k+vbmbrg++evzp9eRZ99/zsRZvWMTRICodG
f3n54vtIFv989uQZlP7tr6cvT7HwyenZ305Pn4OM4vE/bxbgUNMchPP8KbwZ
/3OKL8r8EAX04qUOL0tLDZyBYz38SnbNIZfzZrYYRdBC+CgbCQR5tbSqHyCT
p6cvoyc/1YDQN4Ae/aZ0R93fZg996esnfH6LZtfL87fyy99mF9IcaH4SsxNC
G5utYBS77oRBFfgenDYWdcF8v1wINSEOXqD5lSo5eVlgShXm1XQT/Tfovlqf
2oIkzM2iRceEwTpb6NBKtQnq9rqxRdHhb28WF6vZxSi6mOjdDp67eiONs4L5
si64vrpZW7UjAnr499UPj5+jFkcbVV8QbWQZIUB/qtr4dEgtrl1HR3nE+Wkv
GifhUUNPcZgWK5ocdTy/RV9HNEF/t46mb5aWctR92f8puq0kAz3KFD0KZRO9
my86y1U2GejPCWjYVmzS6O3yZrXuKFfYMOSxNRt0xbcRq5jF2LZ1VAlSOANp
EMUJiU9IAmxy0p8NQT5drZH2C1AotKo1W7CJceyzc6ncDbqtqm+2Z5M62aCn
+R6EKjyNyubpVmwos6hC5axueN+QdAibLLqdTUM0TRVaagrNNbYEmqeCTk+S
3BgKQtl4zVNBj9sjTiAbv3nKuJNZBzYB5xpsA4RmoHcKzc/GKTQDfXuh+Z2N
ZFOexKDT6XatcfeNOnFx9Y0ryAnoGwO9s2/8bJx9Y6B39k2ACrj6RmXj6htv
a9x9o6AP7Btna3C84ejM3Rq/QnuHNc6mM5QO7Rs3Gz7erPjo6WLjF5qTDY43
nE1nsB4otJBB+pajFxr6035Cc7PBWnI2pZuNV2huNjyyuZEBVDebgPHGF3L8
982VV2ihbJwhxxUKjWRD+sbdGoXNMBVwtwY1DdnADNXZmgCf5lRoqOXjmzde
FQhl09EaROdsmLs1rnl5wLBmoHcOa342zmHNQO8c1rxs3OONgu6O0xwLFSFx
mo7eHad52bjjNB19e6F54jSFjTNO87XGE6c16AP7xtkadIlyiqu0Ju8vNOfo
Wc+kdV/VYuNvjZMNegE5k3ax8bbGM6xVIUfsYeNtjZuNDDkM9P6tcXto4Xlv
OXqhsenpOt0eWoSDfF1A9dAtNgF24ws55PKDqzWhbLpac9MsP7ha41q/DZxG
WVxna6HLz8Y7jbK4zv5s/PMbi09rsXEtaAcIzUDnQtPXukPZOIVmoMftJfXg
vvHN1kwPvVVr3H2joNd9s6XQnK25qfYYmLs1fqF5Z2vmQLBda9zDGsbQyKZz
VyWwNe6BQMbG3Zs3ga3xz9YeX68c+0iBrXF7aDn3VD20YNPTdXrmNxhyGB7a
xibAbnzzG3OKO4SNY37D2TBPaxz7fCGuU0fvdp1eNm7XqaN3uk4vG49Pa9Cd
Ps218Rk4KbSMN7Q/G++k0DLetNgE9I3LQ6tsFA/dvzX+uadlvNlGaL7ZmmW8
2UJozoFATqOM8WaL1gRNo6gFvVdr/AOBZbzp3xr/NEqON4WG3tOn+T20ZbzZ
mo3PQ+vjTYtNgN34YgHLeLM1G8dszTLetNh4l1Td26v1Gmah1ZL13iPYDRvv
IqSbjQ3dxsY7k3azsaFbheab4nqEZkG3sfGnJSTdfOw77MAm7h11uluDCm1p
TWsj3xunedjcWM2utWzndTZ+NhZ061qn0wv4Nc2C3lqB8m96OVXAbp5xK07z
b3rthI1/08vJxu4F2mz8i5BONnYvYBGadxHSLTSrF7ALzT3FdbKxm2fc8gL+
Ka6bjdU8Aad3AOVlY2lNi40/gPKqgKU1wqcdUbKrjM1xXQDBdZ+UTZF6PF9f
zhfzzewIiR2rmZyc3B2mcnJ+mhA/yVTOcItsUtLi/ilp/nG5jZ71D812w2ag
UxaTABO9zWagU64Nn3iENswp17X0tGZg8qNd07L+oZl/wLS0pn9o5h9iTHRg
0z806z+S2dgM9P22kQzYtEKzgWm2Ynnziu/apVqm9XbZvB3lChuaD2Hjz656
NbuuzHMAG39KGqoA0+1m5+np0jyBenySZvDfdmyCk+3pwGT70KMD/ITC1myC
D0LwvqGJlc3AhY0O9P5Tmt2wGbiwYR8922wGLmzYR0+L0IYtbNhHT7vQBqw4
dKD3n9L4FzbaA0HZf0rTf/3ExmbgioN9WCv7B7f+YQ0HAkBX0zfSHSemKmzU
ZJQWm4GpnKhpnE3pbs3AxFSFjbM1A1M5UQVenG/M1Jqt2XS0RmHjbM0OErqf
L9+b6C2F3kFCN2dTutkMTOiWPm2wefoDKESnnSd1A4XmzxLhbDwnFAYeHahP
uHtOKAw9QCTZ5BhAseIk3fIMWfDhLjrscJc3MVWyGdSaXifi6PZ90+d8Hzuh
H/pwl7NvBh4gUtm4+ma3B+86+2a3xwg7+2Z3h7uG9k2PE3GdQtvt+b5OoQ1M
Gg49pDIwBVph4z5yMyxpmGeJVIspzgNEw1KgFTbO1gzMgkd0uZgySGi7YTPw
hIKMbHyD9MATCnIaxSzoOzykUq9AeTz07g4QuWOBYYdUVDaDWtPr1FWn69zt
GbLuWGBnB4iG9k2PU1fdg/ROz5A5B+kBScMi7anloVsLxANToBU2qk9rsRmY
NMwT7MTZS2drBqZAK2ycrRmYBS8XU4yBoH9r/FNcy7pA/9b4J4WWgWCLszDe
xFTOhrnZDDykgn1j8dAf8AARHXaAyHvdQ7MVMaA1vU5d0e37ps8ZMuk6+wst
+AARHXiAqMepK7o9mz5nyLjQtjyhEHKlQOw7pDIsBVph4zykMjBpGH2aOd4M
YdPRGoWN+8jN8Cx4c7zZqjX+LHhzvNnuZI/36IA53mx3FiZsGsXcbAYeUql3
o5Tx5sMeIHL6tIGHVFQ2g1rT69RVt+vc6RmyTte5uwNEdOABoh6nruj2bPqc
IZNCq+/etKdy8ttW22mc6i25BRkTOiZZJBI3vv3+jGO+uV4jxM//nq2WI2xH
legZgHoxv7ycrWaLc/vNrtGFmuHZAIfd7toUqzW0FCN6TVt9G3Q/7MBkz7Fx
w2yH9qhxRKqmAhXKGJSBsXOHCoohiXp2G7xE06IsBFHKbSiKmXA5/E5kycWz
bh7CpfRz8Sw0+7mUhPi5eNZkvFwyRpIAibkXMUK4pGESc8T7Xi55HCIxT4Ac
woUGcHGPJX4uWZaF9b7D+YZwyR1c/HcfU8MHU3jHjHdMwo2VMp8vBULGG3Zg
uTqbjjQ2qtO15NHXWFbH21CyF3e73mh3+fQBHlhxw0Gu2Js4SHoQ8+4Hl2nq
MPXG2Qdx8+5wAjeHmfTk5t0aBG4Oc+nJzbuaXhaZw9H0laRvGRq4sZ1K0rNG
WO5QlAFrhWXqCAz6svPOE2jM4p0qijvCBnaOQdxk5zFhr7twW3gPTl5fQnoQ
C0y76ScLr0dgRggbRNW//0yybej6N5yJGXIHS8GzDku2EkTAWiWJtyLstdA8
K7btOrct5llpJezRzxCr8waEQZzCsu16EPRaHulBLDBDq59wAwwu3abTAgzO
bsgBQvAZHN2GcIjB2S3ZRzjA4Oy+J6DrfAZnt2SPJoUYnGtuFM7Ja3BC4j0o
ho11PQh6rY70IBZgbck2PRZgbXYrDmi8z9rINoRDrM1uxj7CAdZmdzwBXeez
NrsZezrdb23OyU4PTv5jC5VP7kHTf0ah0rweNP0HEior6UHTa3mkT6PDctf6
6UHIxNCuuaELnY4p4FaaG7AplNmHzIDO8mycZPbg19MzIbbmmOr34BRga3lL
hz00A2ytbb8emgG21rZfD82wRNU+DffZG+nZYu8CzDbKFWJnHTGvh3CAnXXE
vP6O8tmZ3YA9Qgw4LO9c5OrBKuAUDrFHkQ6iAcdHqvCkB9GA4xVVMNWDaECK
e9l2Cr7m+xPay7ZXCGi+0+5agXTIhlenSdhGYB9Rb3KQI3T09JE7G6gjcvS0
MsjKvJu+QaxCrCxuaYSHaIiVtU3XQzTEytqm6yEaYmXt4dzX/AAra5tuQPP9
Sbs9CHotjfQh5rcw+9Ab0D8eC7NbrqdCfgtzb2f0YOW3MLma04Oo38LkpLUH
Ub+FySl2D6IBB2gyiy/wNN9/wCSz+AJ/891HFvq33n8+IWuPtz6aPlsjPbsn
IJvRMs1zYAVZlzcFJ4hViHWV1jUFB9EQ62qbrIdoiHW1TdZDNMS62sO3r/kB
1tU22YDme6yrd+sDrMu+7uWiGZSs3LOLnBZGOnI+p+vocn65ucVUIvxS53we
iLSdn6+nq83RId6wc4gwx5hkhN9GavG75WLztinnXw0K0J7DUVUOnzV0NM4G
G78ZyHjN5mamMODfNRpg0cvFRQMivsskKJnthBeJHrSvEQWU6eICRfDoYXRI
x/+cLsa0rFJUbelRXx0IsUV6/mg7/RT7DsUFf7hU4C+6ut+EQ/qtagmSERVu
Ep78CUtf6oBf2l6qZA7qGjl9J4fgN5jxxlGGf0FT8RvNZItJ03TSEHZ6yopw
KWlwwgDJCefVy5g1hGlD2Okt7YTLIMJOj2kSjgXJIMJOr2kQrmRMwkTh8px2
wmE1Vn+6TyGca4QlDdpDFPWP9TGR+S3SJZ2EK0K1ltnVTSUcn5BE/bFBN+FY
0ksawqneefwiHxKR0icKTpJWNSz9WvG7JVxphaPzVMJWrSAuwoE1DrG8PeE9
4T3hPeEtCE9UBxdIGJHg8RBO+hMW9Z0kbsLp1oTtY15NONuacOYizLaTcckf
PRLihEMCFkE4PBLihFkwYRZEWIaxNA4mHAcRxjCWE06CCSdBhHH6ywmnwYTT
MMLySsYsmHD2cQlLGRuTGwfhwMmN/Hm0oMC7zxxEXENm+/nqp23CWQ+3qRI2
fxTZTbjwE7bMmqyi6DVrUq/pDiQcJmPnmpMkbJ1LB2hF58ITh+DfBGqf6Zhz
9ckg3KvGzlUoSZhuU2PphDKVMHRXDcG/BZv0UVLKpbDxGP6Lpq/X4qTzanbF
V3Cmq/nm7bvZZn6OENohvUtcn4rEcTuJZ10tu/Ssll16Vssunatll/7Vskv/
atmlbbXs8ZNX3Ytll9ViGQjgwSMpgOjw/Ga1mi022mpZVYiLZWK1q3kknvIE
LpRV62QHQatk/ZbIDlR9w194BKfFYvzpAAwEykS4t9/ER9GaVPFtTC4qpHJK
TVlN0rNdEb7eRppaVlebw0hO4hOanOBVHGUe10FVLitElQG/XvqQ3yNGa5Jo
wdhwsC9CTmL8D91XWje8TNWGV+ZbVy5uPoCN6SYGvfZ+tlrPl4t1y6T4tQO2
SweOotoINvYTrbWCCn1srhuwKSSW9rg2AN/j3/43AByE9TrehkDH0FFEIni2
mggbs2KMLySCZxsJEUoNwbNFRGJRpQbBs/1D2TgmepXcWzuIQFtVcmzb1Ail
RPDsyQix4osawb3hIjioCJ4NlZoD7TzLbdXpyu3Val1979JsiyftdeWF1c/u
4j6LQP3mxYGq7SoOVHZXcaD6u4oDDcJVHGgiruJAo3EVB5qRqzjQsFzFgabm
Ku40vsv5+5kZo3UPKN545/HzpyHxTjW8IHN/sBOZ48sWA4w/VCHpmKJ3TvLQ
SMQck/yBBoIniBGHxhFQKzHIpEqYYOnAiw73eWH1nuomb9WLz1+cadu8Te80
fvM3pYMsPfGlTerzxfvp1fxC/VyXjecLzvBW/axgVoXK5yCytrKj1D70vF3N
hPpP17r6c+kpFqCKT7ECm/QuufQ4aU1kqihte9cW+bnF4BFhlyhi3yjc/AZp
NcmrfUH1vR6FlV8dtYy43h8FlXNI5Qkac73l0mN+7blirCpvwN0Xn9XlCn3n
nXx1eYPg/m3BplzBcF5iKMuVKjmvO9PKVTm5rslzljdE3D8wVZer4nY3LTWa
5r4Es1XeOeqt579Kq690sPkB3FrZ5Qup7S9Pn0mzB2UHEkKZFSXG76rS25XZ
/G5XVo9yepXRq3x+ZfMpl6lMR5kU9tOXL36Izh4/eXaqR+pfVVPcy+Xq3XRT
TW/PoqfgF19tbq9m0dmL6PDHV6MfluvNm9VsffjVwau/vvhbA/DVAbja7745
PYkUpPk6kgjRL/PN2+jHV9HR8+Xi9Ga1vJ5NF8diSr3Y8Cm1qQib2583vyzl
EHqz/vla0mqNlaLbBYLmyVSs5jlwdHqXz5KS1we16mXLw0tY21tlSiFfuTYH
A9hbX3r2BX3ArA+wtjHoB077AGddwK6cnG5IM8lm2474uJCubZGPUc8eHfqf
A9nKUvrwkK5dqyG61LUHrUO6NpXbFte1S6xDurZ9dUjXPq4B6dg/7Wh7BQme
BMCefNPBWaGHgB1tVqHSFpTBkdetRcvGkWYhHGkexLFocQyWWddWll1XuhfD
zFZ0r3mpuuJe2pKQ/hUsVTruhSq1RV3JpXadtm2zt2XZtW/eUU+vPbv2idv1
dK+wqfV0L6SpeuReL1P7qHtZLKPWCcJs/ubtRs6HWzGhsgAAISGHVcJBazAY
mKx+oDWwaynpQGtc1/JRA6WFgr9F1Ypce43Bsq6gVMixftZacTg4Khq5WgL8
7169wNjeF4rP18vwKLyCb8vcJ/c7iLzRMMaEjZVhckyKbWNuCzUIo1sE22As
DAzj7CCwNAws6wIDITRRtROmiqdD2H0CMJkOk99VfYK64/cEI+PUDwwj+qvY
RX/RABgWABMHwCQBMGkATNYNg/GnCtMKWk2Akya3twJIPQDURwEjUjdA7gMo
fAABomDeekI8N+aJB06ZC5jSB4PpBR4YnlEQAOPVSerjlQe0Kw+ocx5Q5zyg
zqUPBmNBX7s4jJ8OtdAJjRvrAMYbMqqhizdYbOItDAn5FmETJiptEIlIY76L
WAeIin/bUWiIYeCYb6DWoaHGJDAofPV/ngUv+ALsLtZ61/+66rfMiwjNE7zC
ewchJmH3KbnPZ2DqQuyApd1Qim04FgjHF3SD4NJAuMwGR+8jKMLJWNNePwWu
ijeD2/FJwWV2OHPt7sPXr0POn7r8+sPJ+PJu4JT+LXbUvzQQjgXCxYFwSSBc
GgiXBcPxJdiOmNYAEISsMKkfhgbQwRDXC5MHwBQBMIECYr56s+I+X8L00WJl
CFx8n9AAONDAmATChdBDpx+o/KK9Prg4jF7djgC4UHocrgxpL18qDaDnh6vp
0RZcaJBcB2HuINkRfwXFXryu3OHkcR0sG23C6WrVf2kdMBvOdUdBMzDi3jnJ
66C5xSgkcJaR79CkCUlHC6C/e/7q9OVZ9N1z4KRlDf7P42c/nr46OgRHj8NR
meaHx/WC7vnyZrE5+uIY82uWi1ln0iGE4Q+jQ77RGEecBnQ7IhzUHYdp49h2
SwYPBugif0+E87OqAUEJHDI7TzxtVEPBAtSsFed3xNWdsX5XtG+N9/ElLv7D
lItvkrl2YBwV6XhtodyVp2EH70zr6KLekdjRBd6R2tEF3pHcgeC4LUiY2CFy
pXeYsK4Ej76d8ynA4sYfwHJj1GGffsT69urm/0RYZ6LGh4RV9cGVArKVntEw
WNxipiyQLtgmjCJBsLghTZMwWNz2pGkgLAor6yEHBdaWElLzN2iaSSF1+024
1AJn8D2xJIZ08TVTQ7r4mskhnXwLC98eMrTV0UwRkXrEihbNVvKFbA8rw2BR
j6AYMyu8sGgjMeE5C/46gKxiGgaLbYNinioQovcWOXTK1tK2Tl22tK3Tpi1t
66yvBbaVOKLUV5ODLSFE6phJtwsW+81Clzp8EPpMJZZIhc88yph/NtQRwzom
Rl2h61YJJ+AUq+DGlXDC1eL2ThJOYFRBVgMTTuopUpV2EjQ7AljHxCh4MuJJ
YdHmIRqS0Y/+3rzTuYd/T7z/rMNCs52vYge0JLZ0UWyltnQBtpJbugBb6S0N
oCvBxYSyp7iEC/tjQbmSXT58vQI76fcJ1ZG28mGgXEkwW9S+c1Ndg+pMhdGg
OpNhNKjOdBgNqjMhRoPqzAPhS3fupBgbyImeLCIWAL0gntQYDuJOjuEg7vQY
DuJOkAkXjSdJpiLkSZPRoDoTZRooV9pJDeVMPNGgAjTXlViiCsvbRk/STA0V
UntP4kwF5UmdEZ3oS56poUJo2RJoWvVKhQeKldEy7xkzhyTbtEOsP2KyTR0Q
b5VyMywg9qTcdCzMK/s+Pdbk7zYkJnX6iGPHbIuwOJhuG9KWiNNFs52K0wXZ
Tsbpgmyn4/CRj9V7pI6EHBOyOyVnqJTuGtK2B99eVb2benZJ/uNL6QNCOtJr
PiSk7PfupJ2eLaLBkCwYMg6GTIIh02DIrB9kZxKPDeSklcaiQDkSeZSKBdFy
JfMoUI50HgXKkdCzjcBcST08XCsqes60GQ5ZhkJiikgcBIkZMWE0MdclnLs/
gUZruxeybpEXsm6RH5L2hnSm+jRt9yXxNDRDIB0JPwZkkxuiD/O9F8PDEoRc
sWJgghC6NOpLEIL2p3eRIITjQNo7QejlqRbuf4ALVPZXuIRMN/ZXuHRQ3l/h
sr/C5ZOT0v4Kl/0VLoFt31/hsr/CxQO5v8LlDq9waWlIlU++ZQbO/rKXRtv2
l73osPvLXvaXvbRh9pe97Ahmf9nL/rKX/WUv+8teTJiPfdmLUZ/tM1X2F8LU
RPYXwqhKtb8QRl0eDoLbXwizvxDmE4bbXwhjwO0vhGkqtL8QZn8hTHc7/nMv
hNHhMuEUts0O2V8cs784xnFxDNtfHGOdF+DL/cUxoeD7i2O8sPuLYz5J2P3F
MfuLY/YXx7j6Zn9xzP7imOh3cHFMH9ijzP7rvvtLZjomU/tLZtR+9Pfmnc5T
/Hvx/WcoFpr7S2bChf2xoPaXzHwwqP0lM/tLZvaXzHih9pfMhCTsVFC/p0tm
wqD6Rdb7q2h6h837q2h2GDjvr6LZX0Wzv4rm9wC5v4pmfxWNAbW/ioZD7a+i
CYHcX0Uz8CqacMh+U4D9pTWf0qU19/aP8axX5/c3s/Xm/mqGMlzfn/16PTvf
zC7ub+aLzWwFfTReL6+mq/l6jP05Wd5s+vIglJAsSe6BLdOM8L/wiYm/hOZp
Ft8jOUlYHNOEpPcIY0mS3YvIh2iw+dysN9NVFN2Te1pdcAB2eXkXFbrbR1zj
dPbd87PTl//z+Ble5PTNy1OYCEdnj588O21KeN7dEXi3qFaM46+0BL8W6DEa
u8j0i44O//5Z7Sg+iz6rP/7jsC8ZcSJ9FGnuBUiKo/OjSPOBW9B/NbuOOJki
Vsm/ON+0X/enzv0rkJPH+CPjGP8WJOUlJ2UJJNgJTU9IDBwq1y0IQie/nl5c
3VY3doGBN/24jvrxA0KA/G4WrcFVzC/n51PuXYGl4HX68uWLl+ClnwDc9PWa
g85+BV6L6VW0ml2DlUG9OFJ02EHssF+VWhrVqw6HKB70go1MIhg9VtPNcmUs
JF3O389Gen0mX8CAju8jNdnY9qD1uJ+DgDE/6DmQw2yX2SkArmseAMd1LYVO
BwDReEii0gFzEXQwzQONyFqs0jFNxHbThYZQ32uT1vovrAFrqBjCwVEqYw3o
8KvZ4g0EDA8f6j28XEAHbyZfIH0euenKx0MhkX+8mUCHfv4wOvwajPjdcrF5
u5YZyLvShF0pwvDuqfOoG8k9eKRLrlpe7SG7B49M4RnLrQPFt0NL2pml9Ffx
njoet3X8gd5R/56tlv36Sekm7CUkALWCItVhHRwRC+uB5vXgocH7D2Neg62r
Mq7b2XS1N60PZVqPHg7uJq7hMe+nvQ/cfUct389WV9Prtb2faHdHUaWnKHbV
f/1XvU7UBIoQfT6+ecPrBI2FJpfcrlEU4A0wOUF7/Y9Pv4edAePOIr0+OnAU
q1vHb2b/WvJd4+XlpXmlmIjPeXfBHwZ/Ont3ZL5h7f4WJKLpQtkEFWUPG+ov
Xj49fRk9+Ulju7s5wSc0q7iDeYmvLY1UQmY2Q/R0p3OaUNfV3dhg59eghFmX
S8K9p2KDRocdjC/NDE93C8ub1WY2W1SuAV9JBy4NVn3HduQ0osVy4/AXShVq
zug3qsq6Lb9GdltJAAXmAlKSWz4h/yHVbbgP2clQtrPa9DTy3THuF4ztjO1O
gsloV87eHfjsjM1Wsh4+gAS1bjibrVo3fKQKat1wNrt0F8Nrs6W72IEYdmm3
g0OGMLsdzCZ0sgIkmtnn+XKxmc7NfFRlmhIw+2yiiAcPouApKLFOQUsCU9D2
rOXT3sK46yh8Z5sj2kLEu+n/zsRel+y5riWJIK1orUkcyY2uQ9uCxGH04PNH
jU3UsLZVisNjq4bsly2iLZctRGoLLlx89WkloXTnf1QKMjj7w5v/EcdJ3uR/
MJ7/QTKyz/+4i0fkf1TJaXIbfL54E72+mV9twKSEw9rcXs+ky0Com/VsHa1m
V7wQJ7r1YCR+GIxTgrJ/LxcA+A5M5P10dRu9nq5nYlK8XFzdwj/R1VJs+AM/
GOPezqp9d6gBkljfrjezd5OIl7yDYRSGU3DR5xuguo7m6/UNzwDbvJ0K5Bev
OC9k8Ga2QT8TXUxvr3iy3Xr6HqiuRXtW/NXlcsW/rqPr1Rw/L6MfF/NfRQ5c
dPRP9OvozcnxpJUYo+Tz8bSYSjhG7oYBddzkLFizVapMjV+m6yiISu3EF8tf
Do9PwljXSF0pKGYCip8SF1h/tGq87Y8o3Xt/zPH2qNa8I9ljqIFvp9fXswXo
5WX0i8xnuY3WXP1A29/N103yTUX1z1GgumDUEqecOYzVVUpq70QXO5UeVWAF
z4CCARJip+KEbleFNhVbflJFan3CzX8NEn27vLm6AIrrm6sNxFAyhbSGDBUm
5hxdTDezitlWOUsqfqjJ8x/igqYXSVzpDU86kvw6Uo6qxGKFLs84at9vaIm9
/si/QaMf/zME2ITR6mucYTWRMfZXDP2FqeWH4kBgmLyDpB0i6xBJa3I2pNyS
qEeeR9lQ8T2KLK72dyq7Dy06z8gSPXhkSPc/RI6NTnYIjecI+YQmg4foYVtK
MkdIiMYUiFlN+xWh1WzcVw0R+kSPLLWwTpcHe2jDq/Z1mUf20yu45xTsIh8q
PtIaxlabWIFtD2t60Niki6ctHZ9wkh7Cscvmz48O/qSvzF2v+CwiJfVRos+i
z+RP8+GZKaiHeP2Pjym4gDFdSldb1RKxGa/1v25mqzmEYXWgtrlZLfjEbD3l
88T1L7NVhaOs0fAJpLp8s7m5vgIyEOGpwdT5dIETu9dA6OIC48PFRUVrNYNA
DGy14otQ8PGX6OYaaSAzETOuJ0EmLjo2OjK69st6wlunax0eR1CDL6vcrYM/
PTANA5fV5OVsed6Z+nNHYZvhOrbxE26vGCKzaPpmeXj8J5DbOFBu9I8nt7FV
16oHRXf0ZXy8l1649ITW1dIb19KTjf8DmC6mvxiSgtdVs0fRy9NnRlElxUbS
bfPWkY79yqhtLNS8K04oZCPvRVJTHl4sezgKDHjN4pCgHoq/xhasZ+drVKBw
nOjdfBEMnUYwbklVDKFOcFUzHD7G5PkaXCxudjwdDfbjqA32QhsN9lPXG+yF
rxp8ROvzCB97mf2Tfbr3f97Mlu9mm9VtvQF0vZqdz9fz5aLvLpB7/ydN4H/1
/k+WZvcIi7Oc7vd/7uIRWzXfnr74/vTs5U/N5s0PS5jDrPGLZSZ0PsP5DV/c
hHfiW71h/eTF/60uOahmMqLcMmmpZxVHdCROdIpvbMTUb5N0FCvfY/zmnKgd
ff119OnVja8EXaNYOwT3zXcvv3mmXD6G45ysn2WMk97wiIzI8UFTW6Z+ibtK
CBkxQvQX8NW1itUt1k+45vx3Hbtr/sOLZz99++I5Vl2Jcj7n0I8iTMY1f+wR
n7pt2tPnSFlT+0msPSPzRdNQ5gc9YsrE/LP5GsbZ1fzfmIF09Vl0ebM4x/0L
i4CutZSTH1589/yMT7mvlXST+bohdnQtTjpwdY4OeUfijkYtLffCm97xYyo6
0FV3uTWyZd05TPTnsV7hHdf3/Wy1mZ93S5qvaoZJWpIy5ZxOwDCSSSqE3ZyE
rCYhFg2sa12jakcN9XrbpRxc70rKv1mqu5PaYoWfzYHMevbm3awanuAdX22D
kLUtcv5LUlB5LsSryZr/E33OX9T5/hJTNu7Zq9NveduuRmpDmz3CHxfT11cz
zBaYX+DNMpe3Ecx0pPCiw88PRWbB7fVsHR1eQW0P+RLXIZfL4cGfflreRL/M
r66it9P3nM5qxhMsNm+hO3AR7Ta6WWMSBpCFeOxqfj7fROfT9YYnFF4t17hr
yImZ0+T5anOrtZe39PPPebtRIALZ39aKlt5jph9cG99bmWGyrlZPaXa+z3OG
ZovVU/rKcOWXv/OBZASDdHLcTm7VxhnV0LdFRshtOdfqH4KMBRrndDSm7Hg7
ztBkGtxmk7Mubfw2OspGmR153DjVyCJuD3YLWRO3DxnCNoLORXmni9xDAAu6
Rd6z6rrIe3I2FJxAPRAfxDE2Og2rySYkKfJC/lMA0CSJS8LkPy7999Dmbx0W
0BfdsIHe3HUr8KDjxbCKZEoUTNYtGcNK3MQhblPoEDYaZxO1F/LC0aNAmD88
5gVTFF/GCTn+h9BkQliR4Iw5Lcq0yNmIppO4SDKaFBlhWeLoUQ/tcTkpy5ym
ZcJYWjBSkc6ANqEJSXKXw/PRZki7KAvKWJantBS0U5oVRcLymMQOXfDQTiek
zJKcFDFjNCkzQTrO8iQp86xkqUNPfNVOoNpJmSSMFEmaxUlV7TTOU1bQjGYO
NfHQptiXpCzjPKEgGkGZQYVB0jEpmcvswU9zRw1dYLpqpMyLHZbdG1237L7o
hmV70JNJPGIgC5d1962BYb9B6NBhTcAvQ9F1s2LyZPnrzFgwma7FzPn18lc5
54eP3XNm/4PoIc+urjdphVXcn1FGY0biJE5TsLSR+QI9YQuo9aaZUOV0klOS
5QWlRZYm+Shn+gskmJUG0DgrDKiaIOgW8IjB2aZlzPJklBkvRA0NoDHR38QK
xdhsTmJpM221mRhvtHWMfEKU+oNX0F8AxRK8JCugLrQoaJykI6q/SRVyOVGl
kY7071yGrJyo1GCwagEpyyi4tb6aLtZXU9uiAcx7bsVq22uxESSnVCpOpC+7
Ra9bk4yaTq3+Cr6my95JQG3fUk157KoFW7IzRzGUKOt6DQ6u501Q9PiJqSGi
hhuP4lbJuOAMq9UBszDneOPSwnSc11z5RxtbiZ/bGFOICUfCKZtlZMSNh40s
JDEKzgVb/JhZ2Ap0/NcsydGHZxy7masbMAUWCA4ZfkwtMPkkG8UFQPAPbT4K
jfpjqyWxjL/EqNAqh5CrxGKwSGqRP/b1uBCS4J9LGxNJhP81SykER9j7YmBp
lcYjylUOdK7NnyJPKhRAfLZpQE2D/z04YvZV5pZljndmmRbTDLXNj2+dVDC0
GietWNp40oYp7eIq8W18QZvEFHrcNs4M1BHKQCsteKiHpLIvVGsL3wqf/2nb
BFjLOGZCq1P+xWajOCxDERVwCf8S2+EyhBM2gh9tdqbSar60bH5EcbxERW/b
O8S9vE20LRN0jjTl1PlHq88R+PyPxUOPi8pFjy1mCt51nAsvbTFx7pvHWeOn
x1ZfJGnwv6qZ4nGm8+mVWNa7gLebkIH1i9p8a4RoG9uNanylvsHW27ZfsUxh
s6bdloxF0ZhBlzFLsTL3hk+xBYKhCQqNhE+xbfgQmA4apBraE8fQzmzuY0zl
iM4hpFG3K0lrIm29h/EXIjdux8WksFUBIjuYilIoRaiimLBRXE4yS11jNBwC
di7soBiVFk3nBHRy4lvL82GMy3sOvEvbX4MDoGgMYAupxZ2XKI5ECIfLaZzY
TArJpFjf6kNbPEm3XmWiyKI6VRlqUOrAzIhvsK0s9X5fS202To445oPxI2ND
DbPKaW3QYTNEm507HvtS/I4efcWCawqoP0MbMBYUCA4WRGglgQk//mNCMG48
rApYxbc4NaEq3C46ZAI6L3UWTNFYTYX5GmeCig+gfApXGIvcE5bhax4Zi2oX
zEqlSAQIs1IhWUppDlO1HBcaoTl1pUhSxElSsowlOFvLTcQyzwCniLMkS4si
5ygsoTlLspjCPxmpqh+zFABYDv+nZcarQXKW0jyGaWAel4WxFgZ1ReIspykj
RUlLjpFmLM7LPE1iVhSJaBOBGWSZkwz+nyYl4QIhGUliSlOcTWYpoyHVNmsz
CgXUe32ENarWQbMiwxl8pSUEHBfMvmmZsiyLzU0DbDBM9imucuZZHNMRdlfC
MgLzdcLKtMgqTSI0z1Oa5Dj7LhPkl9BEoW7R1hoaq4aEa6JpXhZFRZixpABp
57wiDAlDCzNcqqw4tBS8VZXAGptghlK3h2D+PhbvQdEtJRMiuoxrrx0vFnvl
xtrZD9PN22qxzH2fY3X4kfvFtVxEW4iv8sdWroFYtS/9+Oyvxi+sVLCa8+QI
ytPO2Q2ZykiKLDK2ymwARwrAsQmQRM3Oj5BbMuKDIu4C9aYWBOCtMF8WFXPa
GOP1rnpoQMddBzBFRIty531o5t60jr1oPeQ87XJQ69yRUGE2SipFPlbKoHrV
zBDFqpeZsITD4r9qMpdrPUxqKa3WwqpRXKwGcIiL+Xrz8/Tioo4JpKoCUsdh
Xomivex1d0rTZY7ebPehisVbIIr430TMrxAlC6TiZtBVrb9juMeX5Vk8YkaN
9SJV64JmWVp3fVF3F8OJdNNb726ugntLIvTvKLXFiVBPCEj15irvNeHJveJx
tfyQiZkvDcHupmqvxd+PcLcLSxKCOqCx0IuOW7/pJC6+kZmlV7dvMD1bfK3u
x8J8nu6p8HWVBXV1q36I/l8dcte3bEXtxD4O7p0jt1Jc1IMdv9UMHHNme0cr
b22zXkWnTe8FbzcmirpxZ0e5tKyO1pt1gSjqBl0oF2VDLhBF3YQLRNEl1vLp
1oppEgtD0SQWhKJLLIyLJrEgFF1iQSi6xIRgdRCPjtlQPBILQtElFsZFk1gQ
ii6xIBRTYnUs4KiYIbEQFENiASimxEK4GBILQDElZkMJ2XwwXTY66q9rz924
7NnFh/bZs4shTnvvtV36sffae6/t47L32p+21678tXOFRcTsNk/dTN3NlZYK
qfrWmsR7pvPiie1exgrVPcUXD220yShhptTc58uqhsmfIbSfLGs9ujiUZ4sL
c43FC77DwSUk/tWXMyhvF623xkdcUioEq/eo9C12fbNdX05Rqcl/t5BbPbGW
R1/4kYELhDFkqcnPITOt5eYaWO+35vKWq33CVpbXs8XPuH7VNDi65q3CRh1b
zakSQrMjNF8jGYsU4KkZ1G8UbWtpWYB2BSx2ug4DdEmvc0VT0Vuz7HgQP2Mx
Scfo7EmxCIGnoKLz+eocb57ZLKUg19VJHLxE5mJ2OcWbBxc3717PVtHysnKa
1nOebVXfLuPzE306vdnv5vkAKbL7p+cjbBfNcxxXeR6TtCxInjFK4xT+jugk
JfWTJCIPY5KU9UNpNtKwCg4EeDElLE5L3Agj5WxMxRCoEqR5VmjIuIEphrz6
VZaRfKRyzPOS+55xPCEZI0lOCxKnCS2QhYEM70XyVs0yJmXCa9EQzBKRH92g
5fC/Y56PlZYxyQk0AFrDct4Ivtqr0QSx6PgsL0xhFvDfSJNcCm+k++RdUJYi
zaVIJxlhaULivABxFqOUTRqRJVXVikkjEZImo6JosDIq2lhjpZTgGjFB+qn6
vihjDRPg+Cp23rwqspKNAKlmx7KYkyfg0uu3RZmXMdNR8yIpMKukqBkCeb5Q
nZIGsWCYxlIkNVpJWYJACkySAf1sNC65XJNyooqDadg5dFlsiLGE/0R6S00R
32jSF8vuoFRxTKCrCS1KmpcwNKoGgEnphgEUKctHuYIFCqMLHyqRshHWPFZo
sTLJNDzoJIRJlVdJDDCpqqoxT+hBi2ssMAHZ6IhFyRLcy04UmIRXPVbfUbCs
MVX4pRnf1iEKcYapECKJUtP5HAxTQy7yMstNCWK34VG/Gg0UjOlaz0aStu54
YovjIYbjoaPE5nkaPApmO6qCaN3rJG2vE5teJ255nUTReOiNMi4MPO5w1Gpm
JTgpXgHT4RDd4bDSkDxoblaKFNMx0bwNLXMdnUHtSlOK3ONoiAUekFJkX8qz
UCX2Y5knaQmYWQLRHUk1KSKM+oaVeGAC/IbicrhLIApQCnTErqVGLS0NVIGp
vilyAElULUSnRHGWXZbN64K7Aw01L/CURqLCcGtUqYHHARilyYRng2iUExA9
LblsVEy0dQ2VJdSQH3Q3+EVVWhQUQJG6iLwpmIkicfCwpOXk1VfcXRRZy8er
EgeBU96fVMUEH68hVi6equ/Ax4+SsuXiGR6QA3uCRhUsLuMExiwYyUlp4KOj
H40VptLPU4UoOnrw1FnLzyuC53Ifi0aoqCnLCg1XenlFjBgMoJMvW05eO1Qj
5xo4oxDzDZxuTBdRMRYb0XJ22D2rKHCu+WlNLD7afOCPF8bbgmblmFmCSRHK
iywlmSseVmFzjPbUFwk3Q1es28DGLC30Y35FllNPGKuClzmeSVPfMJqn1hBV
PQ2Y5EmsHRmEoNUYh9XwUzltWNIy0zBxEO+OLBVMsH/MAlWOIJZpmukjqBE0
KlWG2CEvNOw8hle2cFA9pchgkNaOMiYQSXSFeuoZSBiTNTySZp1RnIIHw2AW
68ci0dNmjghNrW6Jjl/FBiePeYfW4MtQ4MSmwJawKjaVN2kpb0fIZOot0fWW
5I5oiLaUlhhKy+xhjnp6ExVIP/NZtAZUNYRRIGE+pGNyW+wMTxRI0Fv9ECnh
Cb1doYcKSHjUorxhGW2HFeoZ05SluXYOVRqmPWZQIIVhkpZhOuMBBT7PjdOt
0jo7hnql1thOpuFK21RHcRzIvxGLha078vhQLUb2I9z6xrBEWfCWW9raWF0F
As4RTYr6gRB1Sh41b8RelvEOl0f1V/VmlAEpNpz0l1XqH77ruFutugxQtjRg
M0RtZtNU/6FeXh/cxoCJL03A0nhOekwfKeXclbjK+V19OCFR3/LNC2xiV0bD
0tpC571xD6O44+K45jElsduoRulF76VxI7wUhmY4/ydZDP9TdMB/5RxKHIwt
iQkPqAsQbnMxWmdyyLn8EW4hBpmKybdG5nhjl7j4jB+J4bDHMitzujifWQJf
gBp13ErWJvUoIlhc30Is6Y6a6vBAXKz8P3hgSz1R+g9fCIRIbsVIiqqSd6i6
LxvF2Ol9UN13iE7zUWuDGQasPIOxEeZPuGCQt5HRSOJH8oW2oY09iaYDQx2O
d0ULmfPtQDYe5q22igzBZZ5nMMAmuLiQBiArO+TpJCtiDF4YK1LKLMho4qlS
bWXfP5skEA5DyJESCMridptNZHWj3YvcEpjC2XgCukpBLiYYh8cwpc0TGOZT
L7Ja7ahEg4foMc2LHKI3f7UVaesPJf6u6myzBdnkrFWbQtil+HZ/PyvVRlyI
LPHmHgrTd7/ANGQ2YTFNE1zVylnuVxLVJFk2AZPMYeqU5zGzSNvkrCJHEJjk
ENhCX8UQd7V12xSYihzTCaoHLSESzpPU0mZ5FxGFvjKQQb8mEOyTuEjBvIrE
i6x2Fbyf4JmxDAcWVmReZNUZgJBhEIe5Q8HSpEj81VZTf0A9JhmEbeD9wInl
pZ+zop4Q/k2AJ0MlISyzmKSJrCgJg45OwYsVrIDwNM/VdJuPfcnz/tk/+2f/
7J/9s3/2z/7ZP/tn/+yf/bN//tDP/wexVlb6AOABAA==

--Swarm_of_Insects_211_000--

From bouncefilter Sat Feb 5 17:56:11 2000
Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net
[194.217.242.91]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA23739
for <hackers@postgresql.org>; Sat, 5 Feb 2000 17:55:46 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1)
id 12HE7C-0003QY-0X
for hackers@postgreSQL.org; Sat, 5 Feb 2000 22:55:43 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id WAA11408; Sat, 5 Feb 2000 22:55:30 GMT
Message-Id: <200002052255.WAA11408@mtcc.demon.co.uk>
Date: Sat, 5 Feb 2000 22:55:29 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Small problem with pg_ctl.
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: C6//LVFJzx1Abu6bj9BFMA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

I've a problem with pg_ctl.

When attempting to start the postmaster I get :-

bash-2.03$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start
postmaster successfully started up.
bash-2.03$ /usr/local/pgsql/bin/postmaster does not know where to find the
database system data. You must specify the directory that contains the database
system either by specifying the -D invocation option or by setting the PGDATA
environment variable.

No data directory -- can't proceed.

I think this small patch should fix it.

Keith.

*** src/bin/pg_ctl/pg_ctl.sh.orig       Sat Feb  5 22:29:52 2000
--- src/bin/pg_ctl/pg_ctl.sh    Sat Feb  5 22:30:55 2000
***************
*** 76,81 ****
--- 76,82 ----
        -D)
            shift
            PGDATA="$1"
+           export PGDATA
            ;;
        -p)
            shift

From bouncefilter Sat Feb 5 18:28:12 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA30930
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 18:27:19 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id KAA05086;
Sun, 6 Feb 2000 10:26:59 +1100
Message-Id: <3.0.5.32.20000206102728.0346bc00@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sun, 06 Feb 2000 10:27:28 +1100
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Proposal for new SET variables for optimizer
costs
In-Reply-To: <14601.949786166@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 16:29 5/02/00 -0500, Tom Lane wrote:

SET variable name Internal variable Proposed default

RANDOM_PAGE_COST random_page_cost 4.0

Cost of fetching a disk block nonsequentially (as a multiple of the cost
of a sequential block fetch).

CPU_TUPLE_COST cpu_tuple_cost 0.01

CPU_INDEX_TUPLE_COST cpu_index_tuple_cost 0.001

CPU_OPERATOR_COST cpu_operator_cost 0.0025

ENABLE_SEQSCAN enable_seqscan ON

ENABLE_INDEXSCAN enable_indexscan ON

ENABLE_TIDSCAN enable_tidscan ON

ENABLE_SORT enable_sort ON

ENABLE_NESTLOOP enable_nestloop ON

ENABLE_MERGEJOIN enable_mergejoin ON

ENABLE_HASHJOIN enable_hashjoin ON

Any chance of prefixing the 'set' variable names with 'PG_' or 'PG_OPT_' or
something similar? Or doing something else to differentiate them from
user-declared SQL variables? I have no idea if user-declared SQL variables
are an SQL92 thing, but these variables are 'system' things, and some kind
of differentiation seems like a good idea.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

From bouncefilter Sat Feb 5 18:32:12 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA35017
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 18:31:39 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA16044;
Sat, 5 Feb 2000 18:31:23 -0500 (EST)
To: Philip Warner <pjw@rhyme.com.au>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Proposal for new SET variables for optimizer costs
In-reply-to: <3.0.5.32.20000206102728.0346bc00@mail.rhyme.com.au>
References: <3.0.5.32.20000206102728.0346bc00@mail.rhyme.com.au>
Comments: In-reply-to Philip Warner <pjw@rhyme.com.au>
message dated "Sun, 06 Feb 2000 10:27:28 +1100"
Date: Sat, 05 Feb 2000 18:31:23 -0500
Message-ID: <16041.949793483@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Philip Warner <pjw@rhyme.com.au> writes:

Any chance of prefixing the 'set' variable names with 'PG_' or 'PG_OPT_' or
something similar? Or doing something else to differentiate them from
user-declared SQL variables?

I see no need to do that, since the *only* place these names exist is
in the SET command (and its friends SHOW and RESET), and SET exists only
to set system control variables. There are no user-declared SQL
variables.

The names are quite long and underscore-filled enough without adding
unnecessary prefixes, IMHO ;-)

regards, tom lane

From bouncefilter Sat Feb 5 19:22:12 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA44327
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 19:21:56 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id LAA29746
for <hackers@postgreSQL.org>; Sun, 6 Feb 2000 11:21:52 +1100
Sender: chris@tech.com.au
Message-ID: <389CBEA0.984044ED@bitmead.com>
Date: Sun, 06 Feb 2000 11:21:52 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: Status of inheritance-changing patch
References: <389B9ACB.9F929BAE@bitmead.com> <7935.949770635@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

(One thing that still needs to be looked at is
whether SQL 3 defines any comparable features, and
if so whether we ought to be following their syntax
and behavior.)

I just downloaded the SQL3 document from dec. I can't seem to make head
or tail of it. Can anybody understand what it's saying?

--
Chris Bitmead
mailto:chris@bitmead.com

From bouncefilter Sat Feb 5 19:47:13 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA50889
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 19:46:32 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id LAA05735;
Sun, 6 Feb 2000 11:33:22 +1100
Message-Id: <3.0.5.32.20000206113351.009c8670@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sun, 06 Feb 2000 11:33:51 +1100
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Proposal for new SET variables for optimizer
costs
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <16041.949793483@sss.pgh.pa.us>
References: <3.0.5.32.20000206102728.0346bc00@mail.rhyme.com.au>
<3.0.5.32.20000206102728.0346bc00@mail.rhyme.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 18:31 5/02/00 -0500, Tom Lane wrote:

Philip Warner <pjw@rhyme.com.au> writes:

Any chance of prefixing the 'set' variable names with 'PG_' or 'PG_OPT_' or
something similar? Or doing something else to differentiate them from
user-declared SQL variables?

I see no need to do that, since the *only* place these names exist is
in the SET command (and its friends SHOW and RESET), and SET exists only
to set system control variables. There are no user-declared SQL
variables.

The names are quite long and underscore-filled enough without adding
unnecessary prefixes, IMHO ;-)

I agree, given their complexity, they are unlikely to conflict with future
SQL names, but the SET statment *is* part of the SQL standard, and I
thought it would be good to be cautious in the names you choose. This would
avoid any possible future conflict, as well as make it clear from the
outset that they are *not* standard SQL names.

Another option would be to add another command, eg. 'PG', which is used for
all non-SQLxx commands:

PG SET somename = somevalue
PG VACUUM

...etc. But this has the disctinct disadvantage of being more work, and
being cumbersome in comparison to changing names. The transition could be
managed by supporting old commands until version 8.0, with an appropriate
notice.

Just my 0.02c worth.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

From bouncefilter Sat Feb 5 19:49:14 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA51049
for <hackers@postgreSQL.org>; Sat, 5 Feb 2000 19:48:18 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id QAA28137;
Sat, 5 Feb 2000 16:47:45 -0800 (PST)
Message-Id: <3.0.1.32.20000205163900.0105d860@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 05 Feb 2000 16:39:00 -0800
To: Chris <chris@bitmead.com>, Postgres Hackers List <hackers@postgreSQL.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Status of inheritance-changing patch
In-Reply-To: <389CBEA0.984044ED@bitmead.com>
References: <389B9ACB.9F929BAE@bitmead.com>
<7935.949770635@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:21 AM 2/6/00 +1100, Chris wrote:

Tom Lane wrote:

(One thing that still needs to be looked at is
whether SQL 3 defines any comparable features, and
if so whether we ought to be following their syntax
and behavior.)

I just downloaded the SQL3 document from dec. I can't seem to make head
or tail of it. Can anybody understand what it's saying?

No ... a full summary of the private discussion earlier today between
Jan and I regarding referential integrity would indicate that NOBODY can
understand what it's saying! Be glad it was in private, it was bad
enough that the two of us had to see each other so confused.

Date cheated, his co-author's a ringer who was part of the standards
committee and knows what they meant, rather than what they wrote :)

The appendix on SQL3 in Date's book talks very briefly about it.
There's a CREATE TABLE foo LIKE bar that causes foo to inherit
from bar. He doesn't go into details, though. Talks briefly about
sub and super tables and how the consequences aren't fully
understood. Then he punts.

It would still be a good place to start if you have it.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sat Feb 5 20:19:13 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA57995
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 20:19:12 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id UAA51189
for pgsql-hackers@postgresql.org; Sat, 5 Feb 2000 20:04:36 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: clyde jones <pylqrp@trbpvgvrf.pbz.tht.net>
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Re: Test
Organization: Luna Consulting
References: <87f68p$g3l16@eccws12.dearborn.ford.com>
User-Agent: MT-NewsWatcher/3.0 (PPC)
Message-ID: <pylqrp-1C0D38.20043505022000@news>
Lines: 14
Date: Sun, 06 Feb 2000 01:04:29 GMT
X-Trace: typhoon1.gnilink.net 949799069 151.196.11.187 (Sat,
05 Feb 2000 20:04:29 EST)
To: pgsql-hackers@postgresql.org

In article <87f68p$g3l16@eccws12.dearborn.ford.com>, "Douglas Ribas de
Mattos" <dmattos@visteon.com> wrote:

| It is a test...

And that is what alt.test is for !!!!!!!!!

--
Pray to God, But Hammer Away
- Spanish Proverb

Clyde Jones
jjj.trbpvgvrf.pbz/pylqr-wbarf
pylqrp@trbpvgvrf.pbz

From bouncefilter Sat Feb 5 21:22:15 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA71552
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 21:22:13 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA18499
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 21:22:05 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Optimizer cleanup to avoid redundant work on joins
Date: Sat, 05 Feb 2000 21:22:05 -0500
Message-ID: <18496.949803725@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

(This is mostly directed at Bruce, but anyone else who's looked at the
planner/optimizer is welcome to chime in.)

On the way to implementing estimates of WHERE-clause costs, I was
forced to notice that the estimated sizes of join relations are set
*after* all the planning work is done for a rel, instead of before,
which makes it hard to use the info for cost estimation :-(.
In looking at whether the sizes couldn't be set earlier, I saw that
trying to set them early enough to be used in planning would result in
duplicate effort; in fact there is a lot of duplicated effort already.
This is a proposal to rearrange the optimizer to clean that up.

Right now, the sequence of events in constructing a join tree is that
at each join level, make_one_rel_by_joins invokes make_rels_by_joins
to prepare a list of the joins to be considered at this level (where
a "join" means a particular outer rel and inner rel, and each "rel"
might consist of several already-joined base relations). Each join
is represented by a RelOptInfo node constructed by make_join_rel (see
joinrels.c for these routines). Then update_rels_pathlist_for_joins is
called to determine, for each of these joins, the best implementation or
"path". Finally, since different "joins" in this sense may represent
the same set of joined base relations, merge_rels_with_same_relids is
called to match equivalent joinrels together and keep just the best path
for each equivalence class of joinrels.

My beef with this is that we should never be generating distinct
RelOptInfos in the first place for different ways of producing the
same join relation. make_join_rel spends a fair amount of time and
memory space to produce the RelOptInfo and its substructure, and
for an N-component joinrel this price will be paid (at least) N times
over, after which we throw away all but one of the copies. Even more
critically, once one joinrel has been completed for a particular set
of base rels, the implementation paths for other equivalent joinrels
will be considered in a vacuum --- we may have already discovered a
path that will dominate many of the paths for other ways of building
the same join relation, but because that path isn't available to
add_pathlist when we are looking at another joinrel, we will have to
keep paths that could have been discarded instantly.

It seems to me that join RelOptInfos should be managed in the same way
as base-relation RelOptInfos: there ought never be more than one of them
for a given set of Relids. When we are considering a new pair of outer
and inner rels that can produce an already-considered join relation,
we should find the existing RelOptInfo for that join relation. Then
add_pathlist will keep proposed paths only if they survive comparison
against paths already found from the earlier ways of generating the same
join relation.

This looks like it should be a fairly straightforward change: we should
meld make_join_rel and get_join_rel so that a requested join rel is
first searched for in root->join_rel_list, and only built if not present
(like get_base_rel). The join rel would have a flat relids list from the
beginning, since it would be agnostic about which inner and outer subset
rels should be used to produce it. Then update_rels_pathlist_for_joins
would be called *immediately* to process just that one join rel, passing
the outer and inner subset relid lists as separate parameters. It would
generate paths using this pair of outer and inner rels, and would add
them to the join rel's path list only if they survive comparison against
all the already-found paths for that join rel. On return from
make_rels_by_joins, all the work is done, so make_one_rel_by_joins
doesn't need to invoke either update_rels_pathlist_for_joins or
merge_rels_with_same_relids (the latter routine disappears entirely).
We have but to invoke rels_set_cheapest and then advance to the next
level of joining.

With this change, I could add more processing to make_join_rel to set
the estimated output rel size, without fear that it would be repeated
uselessly.

Anyone see a problem with this, or have a better idea about how to do
it?

regards, tom lane

From bouncefilter Sat Feb 5 22:46:16 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA91693
for <pgsql-hackers@postgresql.org>; Sat, 5 Feb 2000 22:46:14 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id MAA29236
for <pgsql-hackers@postgresql.org>; Sun, 6 Feb 2000 12:46:13 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-20 [133.137.84.20])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id MAA31514
for <pgsql-hackers@postgresql.org>; Sun, 6 Feb 2000 12:46:11 +0900
To: pgsql-hackers@postgresql.org
Subject: pg_ctl man page
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000206124958U.t-ishii@sra.co.jp>
Date: Sun, 06 Feb 2000 12:49:58 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 126

I have written a man page for pg_ctl. I will appreciate if someone
would give me comments on it including grammatical corrections.
--
Tatsuo Ishii

NAME

pg_ctl - starts/stops/restarts postmaster

SYNOPSIS

pg_ctl [-w][-D database_dir][-p path_to_postmaster][-o "postmaster_opts"] start
pg_ctl [-w][-D database_dir][-m s[mart]|f[ast]|i[mmediate]] stop
pg_ctl [-w][-D database_dir][-m s[mart]|f[ast]|i[mmediate]][-o "postmaster_opts"] restart
pg_ctl [-D database_dir] status

DESCRIPTION

pg_ctl is a utility for starting, stopping or restarting postmaster.

Starting postmaster

To start postmaster:

pg_ctl start

If -w is supplied, pg_ctl waits for the database server comes up,
checking the pid file (PGDATA/postmaster.pid) gets created, for up to
60 seconds.

Parameters to invoke postmaster are taken from following sources:

Path to postmaster: found in the command search path
Database directory: PGDATA environment variable
Other parameters: PGDATA/postmaster.opts.default

postmaster.opts.default contains parameters for postmaster. With a
default installation, it has a line "-S." So "pg_ctl start" implies:

postmaster -S

Note that postmaster.opts.default is installed by initdb from
lib/postmaster.opts.default.sample under the PostgreSQL installation
directory (lib/postmaster.opts.default.sample is copied from
src/bin/pg_ctl/postmaster.opts.default.sample while installing
PostgreSQL).

To override default parameters you can use -D, -p and -o option.

-D database_dir
specifies the database directory

-p path_to_postmaster
specifies the path to postmaster

-o "postmaster_opts"
specifies any parameter for postmaster

Examples:

# blocks until postmaster comes up
pg_ctl -w start

# specifies postmaster path
pg_ctl -p /usr/local/pgsq/bin/postmaster start

# uses port 5433 and disables fsync
pg_ctl -o "-o -F -p 5433" start

Stopping postmaster

pg_ctl stop

stops postmaster.

There are several options for the stopping mode.

-w
waits for postmaster shutting down

-m
specifies the shutdown mode. s[mart] mode waits for all
the clients get logged out. This is the default.
f[ast] mode sends SIGTERM to the backends, that means
active transactions get rollback. i[mmediate] mode sends SIGUSR1
to the backends and let them abort. In this case, database recovery
will be neccessary on the next startup.

Restarting postmaster

This is almost equivalent to stopping postmaster then starting it
again except that the parameters for postmaster used before stopping
it would be used too. This is done by saving them in
PGDATA/postmaster.opts file. -w, -D, -m, and -o can also be used in
the restarting mode and they have same meanings as described above.

Examples:

# restarting postmaster in the simplest form
pg_ctl restart

# waiting for postmaster shutdown and waiting for postmaster coming up
pg_ctl -w restart

# uses port 5433 and disables fsync next time
pg_ctl -o "-o -F -p 5433" restart

Getting status from postmaster

To get status information from postmaster:

pg_ctl status

Followings are sample outputs from pg_ctl.

pg_ctl: postmaster is running (pid: 13718)
options are:
/usr/local/src/pgsql/current/bin/postmaster
-p 5433
-D /usr/local/src/pgsql/current/data
-B 64
-b /usr/local/src/pgsql/current/bin/postgres
-N 32
-o '-F'

From bouncefilter Sat Feb 5 23:25:20 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA99888
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 23:24:54 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id EAA16550;
Sun, 6 Feb 2000 04:33:01 GMT
Sender: lockhart@hub.org
Message-ID: <389CF97D.5B7FF997@alumni.caltech.edu>
Date: Sun, 06 Feb 2000 04:33:01 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_ctl man page
References: <20000206124958U.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have written a man page for pg_ctl. I will appreciate if someone
would give me comments on it including grammatical corrections.

I assume that this is intended for the main documentation set? Then
I'll be happy to convert this to sgml markup if you haven't done so or
do not know how. Also, I can make small changes to grammar etc at that
time.

You probably weren't asking about this, but...

The switch options "smart", "fast", and "immediate" are imho a bit too
general. I would suggest that "wait", "stop", and "abort" (or
something similar) might be better and more direct terms which would
come to mind for an admin. Though I see that you also have the concept
of "wait" wrt pg_ctl and the postmaster, to allow pg_ctl to return
immediately before the effects of the commands are seen. So maybe
"asychronous" or something similar could be applied to the
pg_ctl/postmaster relationship, leaving the other terms for the
pg_ctl/client relationship.

I would also suggest dropping "-m <opt>" style switches in favor of
specific flags, with the last flag specified taking precedence. I'm
not aware of other utilities having quite that same style.

- Thomas

NAME
pg_ctl - starts/stops/restarts postmaster

SYNOPSIS

pg_ctl [-w][-D database_dir][-p path_to_postmaster][-o "postmaster_opts"] start
pg_ctl [-w][-D database_dir][-m s[mart]|f[ast]|i[mmediate]] stop
pg_ctl [-w][-D database_dir][-m s[mart]|f[ast]|i[mmediate]][-o "postmaster_opts"] restart
pg_ctl [-D database_dir] status

DESCRIPTION

pg_ctl is a utility for starting, stopping or restarting postmaster.

Starting postmaster

To start postmaster:

pg_ctl start

If -w is supplied, pg_ctl waits for the database server comes up,
checking the pid file (PGDATA/postmaster.pid) gets created, for up to
60 seconds.

Parameters to invoke postmaster are taken from following sources:

Path to postmaster: found in the command search path
Database directory: PGDATA environment variable
Other parameters: PGDATA/postmaster.opts.default

postmaster.opts.default contains parameters for postmaster. With a
default installation, it has a line "-S." So "pg_ctl start" implies:

postmaster -S

Note that postmaster.opts.default is installed by initdb from
lib/postmaster.opts.default.sample under the PostgreSQL installation
directory (lib/postmaster.opts.default.sample is copied from
src/bin/pg_ctl/postmaster.opts.default.sample while installing
PostgreSQL).

To override default parameters you can use -D, -p and -o option.

-D database_dir
specifies the database directory

-p path_to_postmaster
specifies the path to postmaster

-o "postmaster_opts"
specifies any parameter for postmaster

Examples:

# blocks until postmaster comes up
pg_ctl -w start

# specifies postmaster path
pg_ctl -p /usr/local/pgsq/bin/postmaster start

# uses port 5433 and disables fsync
pg_ctl -o "-o -F -p 5433" start

Stopping postmaster

pg_ctl stop

stops postmaster.

There are several options for the stopping mode.

-w
waits for postmaster shutting down

-m
specifies the shutdown mode. s[mart] mode waits for all
the clients get logged out. This is the default.
f[ast] mode sends SIGTERM to the backends, that means
active transactions get rollback. i[mmediate] mode sends SIGUSR1
to the backends and let them abort. In this case, database recovery
will be neccessary on the next startup.

Restarting postmaster

This is almost equivalent to stopping postmaster then starting it
again except that the parameters for postmaster used before stopping
it would be used too. This is done by saving them in
PGDATA/postmaster.opts file. -w, -D, -m, and -o can also be used in
the restarting mode and they have same meanings as described above.

Examples:

# restarting postmaster in the simplest form
pg_ctl restart

# waiting for postmaster shutdown and waiting for postmaster coming up
pg_ctl -w restart

# uses port 5433 and disables fsync next time
pg_ctl -o "-o -F -p 5433" restart

Getting status from postmaster

To get status information from postmaster:

pg_ctl status

Followings are sample outputs from pg_ctl.

pg_ctl: postmaster is running (pid: 13718)
options are:
/usr/local/src/pgsql/current/bin/postmaster
-p 5433
-D /usr/local/src/pgsql/current/data
-B 64
-b /usr/local/src/pgsql/current/bin/postgres
-N 32
-o '-F'

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sat Feb 5 23:43:15 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA05671
for <pgsql-hackers@postgreSQL.org>; Sat, 5 Feb 2000 23:43:10 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA22920;
Sat, 5 Feb 2000 23:41:34 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002060441.XAA22920@candle.pha.pa.us>
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-Reply-To: <18496.949803725@sss.pgh.pa.us> from Tom Lane at "Feb 5,
2000 09:22:05 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 5 Feb 2000 23:41:34 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

This looks like it should be a fairly straightforward change: we should
meld make_join_rel and get_join_rel so that a requested join rel is
first searched for in root->join_rel_list, and only built if not present
(like get_base_rel). The join rel would have a flat relids list from the
beginning, since it would be agnostic about which inner and outer subset
rels should be used to produce it. Then update_rels_pathlist_for_joins
would be called *immediately* to process just that one join rel, passing
the outer and inner subset relid lists as separate parameters. It would
generate paths using this pair of outer and inner rels, and would add
them to the join rel's path list only if they survive comparison against
all the already-found paths for that join rel. On return from
make_rels_by_joins, all the work is done, so make_one_rel_by_joins
doesn't need to invoke either update_rels_pathlist_for_joins or
merge_rels_with_same_relids (the latter routine disappears entirely).
We have but to invoke rels_set_cheapest and then advance to the next
level of joining.

With this change, I could add more processing to make_join_rel to set
the estimated output rel size, without fear that it would be repeated
uselessly.

Anyone see a problem with this, or have a better idea about how to do
it?

Sounds good. The only question is how easy it will be to see if there
already is a RelOptInfo for that combination. My guess is that the
current code is brain-dead like the many fixes we made long ago. It was
carrying around too many versions, instead of keeping the cheapest.
Seems you have found another place that should be doing this.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Feb 6 00:05:16 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA12297
for <hackers@postgreSQL.org>; Sun, 6 Feb 2000 00:04:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA23417;
Sun, 6 Feb 2000 00:03:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002060503.AAA23417@candle.pha.pa.us>
Subject: Re: [HACKERS] Solaris regression tests.
In-Reply-To: <200002052255.WAA11394@mtcc.demon.co.uk> from Keith Parks at "Feb
5, 2000 10:55:21 pm"
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Date: Sun, 6 Feb 2000 00:03:37 -0500 (EST)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied.

Hi,

Solaris has always had problems with 1947 in the
regression tests so I prepared a set of expected
files to make things look OK.

There's also a file to account for minor variations
in the geopmetry output and a resultmap patch to
pull them all together.

With these changes PostgreSQL, from CVS, builds and
regression tests (runcheck) cleanly.

Keith.

Content-Description: resultmap.patch

*** src/test/regress/resultmap.orig	Tue Jan 25 20:29:28 2000
--- src/test/regress/resultmap	Sun Jan 30 11:56:04 2000
***************
*** 4,10 ****
--- 4,16 ----
int4/.*-netbsd=int4-too-large
int2/i.86-pc-linux-gnulibc=int2-not-representable
int4/i.86-pc-linux-gnulibc=int4-not-representable
+ int2/sparc-sun-solaris=int2-too-large
+ int4/sparc-sun-solaris=int4-too-large
geometry/hppa=geometry-positive-zeros
geometry/.*-netbsd=geometry-positive-zeros
geometry/i.86-.*-gnulibc=geometry-i86-gnulibc
+ geometry/sparc-sun-solaris=geometry-solaris-precision
horology/hppa=horology-no-DST-before-1970
+ horology/sparc-sun-solaris=horology-solaris-1947
+ abstime/sparc-sun-solaris=abstime-solaris-1947
+ tinterval/sparc-sun-solaris=tinterval-solaris-1947

Content-Description: solaris_regress.tar.gz

[application/octet-stream is not supported, skipping...]

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Feb 6 01:37:17 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA36220
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 01:36:20 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id PAA02123;
Sun, 6 Feb 2000 15:36:19 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-10 [133.137.84.10])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id PAA32436;
Sun, 6 Feb 2000 15:36:16 +0900
To: lockhart@alumni.caltech.edu
Cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_ctl man page
In-Reply-To: <389CF97D.5B7FF997@alumni.caltech.edu>
References: <20000206124958U.t-ishii@sra.co.jp>
<389CF97D.5B7FF997@alumni.caltech.edu>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000206154003R.t-ishii@sra.co.jp>
Date: Sun, 06 Feb 2000 15:40:03 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 33

I have written a man page for pg_ctl. I will appreciate if someone
would give me comments on it including grammatical corrections.

I assume that this is intended for the main documentation set? Then
I'll be happy to convert this to sgml markup if you haven't done so or
do not know how. Also, I can make small changes to grammar etc at that
time.

Oh, thank you very much!

You probably weren't asking about this, but...

The switch options "smart", "fast", and "immediate" are imho a bit too
general. I would suggest that "wait", "stop", and "abort" (or
something similar) might be better and more direct terms which would
come to mind for an admin. Though I see that you also have the concept
of "wait" wrt pg_ctl and the postmaster, to allow pg_ctl to return
immediately before the effects of the commands are seen. So maybe
"asychronous" or something similar could be applied to the
pg_ctl/postmaster relationship, leaving the other terms for the
pg_ctl/client relationship.

Talking about "smart/fast/immediate," I have refered to them from
comments in postmaster.c probably written by Vadim. So before changing
them I would like to hear from Vadim. Ok?

I would also suggest dropping "-m <opt>" style switches in favor of
specific flags, with the last flag specified taking precedence. I'm
not aware of other utilities having quite that same style.

Sounds resonable.
--
Tatsuo Ishii

From bouncefilter Sun Feb 6 01:38:17 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA36388
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 01:37:21 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id PAA02140;
Sun, 6 Feb 2000 15:37:15 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-10 [133.137.84.10])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id PAA32446;
Sun, 6 Feb 2000 15:37:12 +0900
To: pgman@candle.pha.pa.us
Cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-Reply-To: <200002051702.MAA07851@candle.pha.pa.us>
References: <20000205193719A.t-ishii@sra.co.jp>
<200002051702.MAA07851@candle.pha.pa.us>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000206154059U.t-ishii@sra.co.jp>
Date: Sun, 06 Feb 2000 15:40:59 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 122

In the TODO file:

* -Allow transaction commits with rollback with no-fsync performance [fsync](Vadim)

Has this been done in current? I see almost no performance
improvement on copying data into a table.

TODO updated. That was part of MVCC which originally was supposed to be
in 7.0.

Thanks.

BTW, I have worked a little bit on this item. The idea is pretty
simple. Instead of doing a real fsync() in pg_fsync(), just marking it
so that we remember to do fsync() at the commit time. Following
patches illustrate the idea. An experience shows that it dramatically
boosts the performance of copy. Unfortunately I see virtually no
difference for TPC-B like small many concurrent transactions. Maybe we
would need WAL for this. Comments?

Index: access/transam/xact.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/access/transam/xact.c,v
retrieving revision 1.60
diff -c -r1.60 xact.c
*** access/transam/xact.c	2000/01/29 16:58:29	1.60
--- access/transam/xact.c	2000/02/06 06:12:58
***************
*** 639,644 ****
--- 639,646 ----
  	if (SharedBufferChanged)
  	{
  		FlushBufferPool();
+ 		pg_fsync_pending();
+ 
  		if (leak)
  			ResetBufferPool();

***************
*** 653,658 ****
--- 655,661 ----
  		 */
  		leak = BufferPoolCheckLeak();
  		FlushBufferPool();
+ 		pg_fsync_pending();
  	}

  	if (leak)
Index: storage/file/fd.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/storage/file/fd.c,v
retrieving revision 1.52
diff -c -r1.52 fd.c
*** storage/file/fd.c	2000/01/26 05:56:55	1.52
--- storage/file/fd.c	2000/02/06 06:13:01
***************
*** 189,202 ****
  static File fileNameOpenFile(FileName fileName, int fileFlags, int fileMode);
  static char *filepath(char *filename);
  static long pg_nofile(void);

/*
* pg_fsync --- same as fsync except does nothing if -F switch was given
*/
int
pg_fsync(int fd)
{
! return disableFsync ? 0 : fsync(fd);
}

  /*
--- 189,238 ----
  static File fileNameOpenFile(FileName fileName, int fileFlags, int fileMode);
  static char *filepath(char *filename);
  static long pg_nofile(void);
+ static void alloc_fsync_info(void);

+ static char *fsync_request;
+ static int nfds;
+ 
  /*
   * pg_fsync --- same as fsync except does nothing if -F switch was given
   */
  int
  pg_fsync(int fd)
+ {
+ 	if (fsync_request == NULL)
+ 	  alloc_fsync_info();
+ 	fsync_request[fd] = 1;
+ 	return 0;
+ }
+ 
+ static void alloc_fsync_info(void)
+ {
+   nfds = pg_nofile();
+   fsync_request = malloc(nfds);
+   if (fsync_request == NULL) {
+     elog(ERROR, "alloc_fsync_info: cannot allocate memory");
+     return;
+   }
+ }
+ 
+ void
+ pg_fsync_pending(void)
  {
!   int i;
! 
!   if (disableFsync)
!     return;
! 
!   if (fsync_request == NULL)
!     alloc_fsync_info();
! 
!   for (i=0;i<nfds;i++) {
!     if (fsync_request[i]) {
!       fsync(i);
!       fsync_request[i] = 0;
!     }
!   }
  }

/*

From bouncefilter Sun Feb 6 02:01:18 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA42170
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 02:01:02 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA09293;
Sun, 6 Feb 2000 01:55:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002060655.BAA09293@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <20000206154059U.t-ishii@sra.co.jp> from Tatsuo Ishii at "Feb 6,
2000 03:40:59 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Sun, 6 Feb 2000 01:55:26 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

BTW, I have worked a little bit on this item. The idea is pretty
simple. Instead of doing a real fsync() in pg_fsync(), just marking it
so that we remember to do fsync() at the commit time. Following
patches illustrate the idea. An experience shows that it dramatically
boosts the performance of copy. Unfortunately I see virtually no
difference for TPC-B like small many concurrent transactions. Maybe we
would need WAL for this. Comments?

Can you be more specific. How does fsync work now vs. your proposed
change. I did not see that here. Sorry.

Index: access/transam/xact.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/access/transam/xact.c,v
retrieving revision 1.60
diff -c -r1.60 xact.c
*** access/transam/xact.c	2000/01/29 16:58:29	1.60
--- access/transam/xact.c	2000/02/06 06:12:58
***************
*** 639,644 ****
--- 639,646 ----
if (SharedBufferChanged)
{
FlushBufferPool();
+ 		pg_fsync_pending();
+ 
if (leak)
ResetBufferPool();

***************
*** 653,658 ****
--- 655,661 ----
*/
leak = BufferPoolCheckLeak();
FlushBufferPool();
+ 		pg_fsync_pending();
}

if (leak)
Index: storage/file/fd.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/storage/file/fd.c,v
retrieving revision 1.52
diff -c -r1.52 fd.c
*** storage/file/fd.c	2000/01/26 05:56:55	1.52
--- storage/file/fd.c	2000/02/06 06:13:01
***************
*** 189,202 ****
static File fileNameOpenFile(FileName fileName, int fileFlags, int fileMode);
static char *filepath(char *filename);
static long pg_nofile(void);

/*
* pg_fsync --- same as fsync except does nothing if -F switch was given
*/
int
pg_fsync(int fd)
{
! return disableFsync ? 0 : fsync(fd);
}

/*
--- 189,238 ----
static File fileNameOpenFile(FileName fileName, int fileFlags, int fileMode);
static char *filepath(char *filename);
static long pg_nofile(void);
+ static void alloc_fsync_info(void);

+ static char *fsync_request;
+ static int nfds;
+ 
/*
* pg_fsync --- same as fsync except does nothing if -F switch was given
*/
int
pg_fsync(int fd)
+ {
+ 	if (fsync_request == NULL)
+ 	  alloc_fsync_info();
+ 	fsync_request[fd] = 1;
+ 	return 0;
+ }
+ 
+ static void alloc_fsync_info(void)
+ {
+   nfds = pg_nofile();
+   fsync_request = malloc(nfds);
+   if (fsync_request == NULL) {
+     elog(ERROR, "alloc_fsync_info: cannot allocate memory");
+     return;
+   }
+ }
+ 
+ void
+ pg_fsync_pending(void)
{
!   int i;
! 
!   if (disableFsync)
!     return;
! 
!   if (fsync_request == NULL)
!     alloc_fsync_info();
! 
!   for (i=0;i<nfds;i++) {
!     if (fsync_request[i]) {
!       fsync(i);
!       fsync_request[i] = 0;
!     }
!   }
}

/*

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Feb 6 03:37:18 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA70390
for <pgsql-hackers@postgresql.org>; Sun, 6 Feb 2000 03:36:58 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm128.noc.fukui.nsk.ne.jp [210.161.188.47])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id RAA12582; Sun, 06 Feb 2000 17:35:50 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tatsuo Ishii" <t-ishii@sra.co.jp>, <pgman@candle.pha.pa.us>
Cc: <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] TODO item
Date: Sun, 6 Feb 2000 17:36:55 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFMEKPCCAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <20000206154059U.t-ishii@sra.co.jp>

-----Original Message-----
From: owner-pgsql-hackers@postgresql.org
[mailto:owner-pgsql-hackers@postgresql.org]On Behalf Of Tatsuo Ishii

In the TODO file:

* -Allow transaction commits with rollback with no-fsync

performance [fsync](Vadim)

Has this been done in current? I see almost no performance
improvement on copying data into a table.

TODO updated. That was part of MVCC which originally was supposed to be
in 7.0.

Thanks.

BTW, I have worked a little bit on this item. The idea is pretty
simple. Instead of doing a real fsync() in pg_fsync(), just marking it
so that we remember to do fsync() at the commit time. Following

This seems not good,unfortunately.
Note that the backend which calls pg_fsync() for a relation file may
be different from the backend which updated shared buffers of the file.
The former backend wouldn't necessarily be committed when the
latter backend is committed.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Feb 6 05:38:19 2000
Received: from feivel.fam-meskes.de (h-62.96.159.242.host.de.colt.net
[62.96.159.242]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA02440
for <pgsql-hackers@postgresql.org>; Sun, 6 Feb 2000 05:37:55 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 2F3452BBA5; Sun, 6 Feb 2000 11:23:26 +0100 (CET)
Date: Sun, 6 Feb 2000 11:23:26 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Two backends at the same time
Message-ID: <20000206112326.C5377@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
References: <20000204095525.A799@fam-meskes.de> <3606.949677473@sss.pgh.pa.us>
<20000204204548.B1929@fam-meskes.de>
<389B8236.55AE3A38@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <389B8236.55AE3A38@alumni.caltech.edu>;
from lockhart@alumni.caltech.edu on Sat, Feb 05, 2000 at
01:51:50AM +0000
Sender: michael@fam-meskes.de

On Sat, Feb 05, 2000 at 01:51:50AM +0000, Thomas Lockhart wrote:

$ENV{"PGDATESTYLE"} = "German";

might do it, but I'm not recalling with certainty that Perl does the
Right Thing in to make the variable visible to children (pretty sure
it does).

Yes, that's exactly what I tried and it works.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Sun Feb 6 07:57:22 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA34894
for <hackers@postgreSQL.org>; Sun, 6 Feb 2000 07:56:39 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id XAA02616
for <hackers@postgreSQL.org>; Sun, 6 Feb 2000 23:56:35 +1100
Sender: chris@tech.com.au
Message-ID: <389D6F83.84CD0159@bitmead.com>
Date: Sun, 06 Feb 2000 23:56:35 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Advice needed,
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

I've been trying to implement UPDATE and DELETE to work on subclasses.

I made some changes and it kinda seems to work. It works when I have no
WHERE condition. When I put a WHERE condition in, it seems to update the
wrong tuple, and then things go wierd...

pghack=# update a set aa='zzz' where oid=19286;
UPDATE 1
pghack=# select oid,* from a;
oid | aa
-------+------
19286 | aaaa
19285 | zzz
(2 rows)

pghack=# update a set aa='zzz' where oid=19285;
ERROR: heap_update: (am)invalid tid
ERROR: heap_update: (am)invalid tid
pghack=# update a set aa='zzz';
ERROR: heap_update: (am)invalid tid
ERROR: heap_update: (am)invalid tid

This message seems to be something to do with a tuple being in an
"Invisible" state whatever that means.

The change I made was basicly to add an "inh" parameter to
setTargetTable which I pass on down to addRangeTableEntry. From there I
expect it to be passed on to the executor and as I said it seems to work
ok without a where clause.

The patch is here. Any suggestions on where to start looking?

ftp://ftp.tech.com.au/pub/patch.only2

--
Chris Bitmead
mailto:chris@bitmead.com

From bouncefilter Sun Feb 6 08:06:22 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA40056
for <pgsql-hackers@postgresql.org>; Sun, 6 Feb 2000 08:06:12 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64206 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S299058AbQBFNFU>;
Sun, 6 Feb 2000 14:05:20 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12HRPS-00008y-00
for pgsql-hackers@postgresql.org; Sun, 06 Feb 2000 14:07:26 +0100
Date: Sun, 6 Feb 2000 14:07:26 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: psql -e and -n flags
Message-ID: <Pine.LNX.4.21.0002052024330.429-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

As you surely noticed, the psql -e flag ("echo" modus, if you will) has
changed its format (regression tests ring a bell?) in that it echoes the
input file verbatim. For the particular case of the regression tests this
seems like a good thing to me since you see the comments as well. However,
I also offer the "old" mode that merely echoes the actual queries as they
are sent to the backend (which, as we know since the array syntax thing,
can be quite different), but there's no option for this.

The suggestion I have is to offer the traditional behaviour with a single
-e flag, so there's little change for anyone switching from <7.0, and the
"full" echo mode with two -e flags. I'd then change the flags in the
regression drivers to -e -e. Comments? Better ideas?

Furthermore, does anyone have anything to say in defence of the -n ("no
readline") option? If not, I'd be tempted to "hide" it now, since it may
be a popular option letter to have available in the future.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sun Feb 6 08:07:21 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA40124
for <pgsql-hackers@postgresql.org>; Sun, 6 Feb 2000 08:06:38 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64476 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S299058AbQBFNFq>;
Sun, 6 Feb 2000 14:05:46 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12HRPu-0000Ah-00
for pgsql-hackers@postgresql.org; Sun, 06 Feb 2000 14:07:54 +0100
Date: Sun, 6 Feb 2000 14:07:54 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: libpq API tweaks
Message-ID: <Pine.LNX.4.21.0002052049180.429-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

I'm going to have to revert a few of the "const-mania" changes to the
libpq API done last fall. They are bound to be a real annoyance to users,
especially those that don't use const's religiously, but sometimes even to
those that do. This does not represent a break the with the 6.* API.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sun Feb 6 09:01:22 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA60202
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 09:00:27 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id XAA10442;
Sun, 6 Feb 2000 23:00:25 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-10 [133.137.84.10])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id XAA01884;
Sun, 6 Feb 2000 23:00:23 +0900
To: pgman@candle.pha.pa.us
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-Reply-To: <200002060655.BAA09293@candle.pha.pa.us>
References: <20000206154059U.t-ishii@sra.co.jp>
<200002060655.BAA09293@candle.pha.pa.us>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000206230412X.t-ishii@sra.co.jp>
Date: Sun, 06 Feb 2000 23:04:12 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 31

BTW, I have worked a little bit on this item. The idea is pretty
simple. Instead of doing a real fsync() in pg_fsync(), just marking it
so that we remember to do fsync() at the commit time. Following
patches illustrate the idea. An experience shows that it dramatically
boosts the performance of copy. Unfortunately I see virtually no
difference for TPC-B like small many concurrent transactions. Maybe we
would need WAL for this. Comments?

Can you be more specific. How does fsync work now vs. your proposed
change. I did not see that here. Sorry.

As already pointed out by many people, current buffer manager is not
very smart on flushing out dirty pages. From TODO.detail/fsync:

This is the problem of buffer manager, known for very long time:
when copy eats all buffers, manager begins write/fsync each
durty buffer to free buffer for new data. All updated relations
should be fsynced _once_ @ transaction commit. You would get
the same results without -F...

With my changes, pg_fsync would just mark the relation (actually its
file descriptor) as it is needed fsync, instead of calling real fsync.
Upon transaction commit, the mark would be checked and relations are
fsynced if necessary.

BTW, Hiroshi has raised a question with my changes, and I have written
to him (in Japanese, of course:-) to make sure that what I'm missing
here. I will let you know the result later.
--
Tatsuo Ishii

From bouncefilter Sun Feb 6 09:36:22 2000
Received: from anubis.inm.de (anubis.inm.de [195.20.81.9])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA71832
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 09:35:54 -0500 (EST)
(envelope-from sevo@ip23.net)
Received: from ip23.net (umbriel [195.20.81.11]) by anubis.inm.de
(980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA10748 for
<pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 15:35:17 +0100 (CET)
Message-ID: <389D86A4.962AF9A@ip23.net>
Date: Sun, 06 Feb 2000 15:35:16 +0100
From: Sevo Stille <sevo@ip23.net>
Reply-To: sevo@ip23.net
Organization: IP23
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: de,en,en-GB,en-US
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Proposal for new SET variables for optimizercosts
References: <3.0.5.32.20000206102728.0346bc00@mail.rhyme.com.au>
<3.0.5.32.20000206102728.0346bc00@mail.rhyme.com.au>
<3.0.5.32.20000206113351.009c8670@mail.rhyme.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Philip Warner wrote:

Another option would be to add another command, eg. 'PG', which is used for
all non-SQLxx commands:

PG SET somename = somevalue
PG VACUUM

...etc. But this has the disctinct disadvantage of being more work, and
being cumbersome in comparison to changing names.

This does not work out in terms of general SQL compatibility. Even if we
treat commands after PG specially, no other SQL database would, and it
would raise at least as many errors as the extension syntax. Nor is
there any significant advantage of it within Postgres if we ever get a
keyword clash with a future SQL revision - I'd rather not have a syntax
that alows for two interpretations for the same keyword depending on
whether it follows PG or not.

Sevo

--
Sevo Stille
sevo@ip23.net

From bouncefilter Sun Feb 6 10:48:23 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA89581
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 10:48:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA24484;
Sun, 6 Feb 2000 10:47:43 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-reply-to: <20000206230412X.t-ishii@sra.co.jp>
References: <20000206154059U.t-ishii@sra.co.jp>
<200002060655.BAA09293@candle.pha.pa.us>
<20000206230412X.t-ishii@sra.co.jp>
Comments: In-reply-to Tatsuo Ishii <t-ishii@sra.co.jp>
message dated "Sun, 06 Feb 2000 23:04:12 +0900"
Date: Sun, 06 Feb 2000 10:47:43 -0500
Message-ID: <24481.949852063@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

BTW, I have worked a little bit on this item. The idea is pretty
simple. Instead of doing a real fsync() in pg_fsync(), just marking it
so that we remember to do fsync() at the commit time. Following
patches illustrate the idea.

In the form you have shown it, it would be completely useless, for
two reasons:

1. It doesn't guarantee that the right files are fsync'd. It would
in fact fsync whichever files happen to be using the same kernel
file descriptor numbers at the close of the transaction as the ones
you really wanted to fsync were using at the time fsync was requested.

2. It doesn't guarantee that the files are fsync'd in the right order.
Per my discussion a few days ago, the only reason for doing fsync at all
is to guarantee that the data pages touched by a transaction get flushed
to disk before the pg_log update claiming that the transaction is done
gets flushed to disk. A change like this completely destroys that
ordering, since pg_fsync_pending has no idea which fd is pg_log.

You could possibly fix #1 by logging fsync requests at the vfd level;
then, whenever a vfd is closed to free up a kernel fd, check the fsync
flag and execute the pending fsync before closing the file. You could
possibly fix #2 by having transaction commit invoke the pg_fsync_pending
scan before it updates pg_log (and then fsyncing pg_log itself again
after).

(Actually, you could probably eliminate the notion of "fsync request"
entirely, and simply have each vfd get marked "dirty" automatically when
written to. Both closing a vfd and the scan at xact commit would look
at the dirty bit to decide to do fsync.)

What would still need to be thought about is whether this scheme
preserves the ordering guarantee when a group of concurrent backends
is considered, rather than one backend in isolation. (I believe that
fsync() will apply to all dirty kernel buffers for a file, not just
those dirtied by the requesting process, so each backend's fsyncs can
affect the order in which other backends' writes hit the disk.)
Offhand I do not see any problems there, but it's the kind of thing
that requires more than offhand thought...

regards, tom lane

From bouncefilter Sun Feb 6 10:55:23 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90611
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 10:54:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA24527;
Sun, 6 Feb 2000 10:54:42 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql -e and -n flags
In-reply-to: <Pine.LNX.4.21.0002052024330.429-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002052024330.429-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sun, 06 Feb 2000 14:07:26 +0100"
Date: Sun, 06 Feb 2000 10:54:42 -0500
Message-ID: <24524.949852482@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

The suggestion I have is to offer the traditional behaviour with a single
-e flag, so there's little change for anyone switching from <7.0, and the
"full" echo mode with two -e flags. I'd then change the flags in the
regression drivers to -e -e. Comments? Better ideas?

Seems reasonable.

Furthermore, does anyone have anything to say in defence of the -n ("no
readline") option? If not, I'd be tempted to "hide" it now, since it may
be a popular option letter to have available in the future.

readline automatically turns off if the input is not coming from a
terminal, right? That seems like the only really compelling reason
to have -n (since you wouldn't want script commands filling your
history or being subject to tab-completion). I suppose someone who
really hated tab-completion might want a way to turn off just that
feature, though --- is there a way?

BTW, if you need one more item for your psql todo list ;-) ... when
looking at EXPLAIN outputs it's possible to get NOTICE messages that
fill many screensful. It might be nice if NOTICEs went through the
pager like query results do.

regards, tom lane

From bouncefilter Sun Feb 6 11:14:23 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA97127
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 11:14:03 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA21322;
Sun, 6 Feb 2000 08:06:57 -0800 (PST)
Message-Id: <3.0.1.32.20000206080311.0105fe70@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 06 Feb 2000 08:03:11 -0800
To: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] psql -e and -n flags
In-Reply-To: <Pine.LNX.4.21.0002052024330.429-100000@localhost.localdoma
in>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:07 PM 2/6/00 +0100, Peter Eisentraut wrote:

The suggestion I have is to offer the traditional behaviour with a single
-e flag, so there's little change for anyone switching from <7.0, and the
"full" echo mode with two -e flags. I'd then change the flags in the
regression drivers to -e -e. Comments? Better ideas?

"-E"? Or another flag? I think "-e -e" is a real kludge. If I
thought the full-echo mode were only useful for regression tests I wouldn't
care, but I like the idea of a full echo and I'm sure others do, too, so
I'd rather see it be receive full flag citizenship rather than the double
"-e" bit.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sun Feb 6 11:27:23 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA99002
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 11:26:40 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA17253;
Sun, 6 Feb 2000 16:34:41 GMT
Sender: lockhart@hub.org
Message-ID: <389DA2A0.EC14B8D3@alumni.caltech.edu>
Date: Sun, 06 Feb 2000 16:34:40 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql -e and -n flags
References: <Pine.LNX.4.21.0002052024330.429-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The suggestion I have is to offer the traditional behaviour with a single
-e flag, so there's little change for anyone switching from <7.0, and the
"full" echo mode with two -e flags. I'd then change the flags in the
regression drivers to -e -e. Comments? Better ideas?

Hmm. imho having a *count* of switch options being significant is the
wrong way to go. It gets in the way of things like

# alias ps psql -e
# ps -e postgres

where someone has defined a "convenience" alias for everyone and
someone else uses it later. Also, it is a style of switch invocation
not appearing elsewhere afaik.

I'd suggest a switch style like "-ee" or "-eb" (backend) or "-ev"
(verbatim) or ??? Comments?

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sun Feb 6 11:50:24 2000
Received: from alert.infoplease.com (range.infoplease.com [208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA06299
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 11:50:10 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05704;
Sun, 6 Feb 2000 11:49:32 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id LAA07735;
Sun, 6 Feb 2000 11:49:32 -0500
Date: Sun, 6 Feb 2000 11:49:32 -0500
Message-Id: <200002061649.LAA07735@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: lockhart@alumni.caltech.edu
CC: peter_e@gmx.net, pgsql-hackers@postgreSQL.org
In-reply-to: <389DA2A0.EC14B8D3@alumni.caltech.edu> (message from Thomas
Lockhart on Sun, 06 Feb 2000 16:34:40 +0000)
Subject: Re: [HACKERS] psql -e and -n flags
Reply-to: kdebisschop@range.infoplease.com
References: <Pine.LNX.4.21.0002052024330.429-100000@localhost.localdomain>
<389DA2A0.EC14B8D3@alumni.caltech.edu>

I'd suggest a switch style like "-ee" or "-eb" (backend) or "-ev"
(verbatim) or ??? Comments?

Don's suggestion seems the right track for me.

It stays away from counting flags, which seems right. It sticks with
one-char flags for single dashes whihc is not the law but is common
enough to be intuitive for many users. PLus there's an aesthetic
appeal to -e for 'echo' and -E for 'echo everything'. It also does
not change current behavior in cases where people are expecting psql
-e to behave a certain way.

Just my $0.02 worth as a user.

From bouncefilter Sun Feb 6 11:43:24 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA04781
for <hackers@postgreSQL.org>; Sun, 6 Feb 2000 11:42:27 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA17269;
Sun, 6 Feb 2000 16:50:26 GMT
Sender: lockhart@hub.org
Message-ID: <389DA652.89F12DB0@alumni.caltech.edu>
Date: Sun, 06 Feb 2000 16:50:26 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris <chris@bitmead.com>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Advice needed,
References: <389D6F83.84CD0159@bitmead.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've been trying to implement UPDATE and DELETE to work on subclasses.
The change I made was basicly to add an "inh" parameter to
setTargetTable which I pass on down to addRangeTableEntry. From there I
expect it to be passed on to the executor and as I said it seems to work
ok without a where clause.

Hi Chris. I don't have time to look at you patches right now, since
I'm trying to get some syntax stuff finished up and committed. But fyi
my patches touch addRangeTableEntry and other files in the parser, so
you'll likely have a bit of a merge effort to get these sync'd back
up. Sorry :(

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sun Feb 6 11:47:25 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA05841
for <hackers@postgresql.org>; Sun, 6 Feb 2000 11:47:23 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA17278
for <hackers@postgresql.org>; Sun, 6 Feb 2000 16:55:36 GMT
Sender: lockhart@hub.org
Message-ID: <389DA788.CA1CF761@alumni.caltech.edu>
Date: Sun, 06 Feb 2000 16:55:36 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Implicit RTEs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I know this topic came up recently:

select t1.* from t1 ty;

gives a join between two instances of t1, rather than the expected
query rejection (the table in the from clause should be referred to as
"ty").

There was talk of disallowing:

select t1.*;

which seems to be a bit harsh, since it is a *nice* shorthand. How
about disallowing it if there is a FROM clause specified? That is,

select t1.*;

is allowed, but

select t1.* from t2;

is not? Pretty sure I can do this. Comments?

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sun Feb 6 12:22:24 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA15750
for <hackers@postgresql.org>; Sun, 6 Feb 2000 12:21:24 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA17339
for <hackers@postgresql.org>; Sun, 6 Feb 2000 17:29:38 GMT
Sender: lockhart@hub.org
Message-ID: <389DAF82.A8F8B561@alumni.caltech.edu>
Date: Sun, 06 Feb 2000 17:29:38 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Duplicate table names
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The following query is rejected (and always has been afaik):

select * from t1, t1;

Does this rejection have any basis in SQL92? (I haven't looked; hoping
someone else has.)

istm that

select x from t1, t1;

would have trouble, but the wildcard could do the Right Thing even
without resorting to (for example)

select * from t1 a, t1;

as is currently required. I'm not sure what it would take to do this,
but it probably touches on an area of "outer join syntax" I'm looking
at:

select a, b from t1 join t2 using (a);

is legal, but the "join table" (t1 join t2 using...) must lose its
underlying table names (yuck, only for the join columns), resulting in
disallowing, for example,

select t1.a from t1 join t2 using (a);

That is, the "relation.column" syntax is not allowed to refer to the
join column(s), unless one specifies an alias for the "join table", as
in

select tx.a from (t1 join t2 using (a)) as tx;

I'm thinking of implementing this by allowing multiple RTEs to have
the *same* table alias, (as long as there aren't column name conflicts
in the "visible" columns), so that, at least internally,

select * from t1 tx, t3 tx;

becomes legal as long as t1 and t3 do not share common column names.

Comments on either or both issues?

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sun Feb 6 12:49:24 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA24963
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 12:48:27 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA00280;
Sun, 6 Feb 2000 12:47:32 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002061747.MAA00280@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <24481.949852063@sss.pgh.pa.us> from Tom Lane at "Feb 6,
2000 10:47:43 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 6 Feb 2000 12:47:32 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

You could possibly fix #1 by logging fsync requests at the vfd level;
then, whenever a vfd is closed to free up a kernel fd, check the fsync
flag and execute the pending fsync before closing the file. You could
possibly fix #2 by having transaction commit invoke the pg_fsync_pending
scan before it updates pg_log (and then fsyncing pg_log itself again
after).

(Actually, you could probably eliminate the notion of "fsync request"
entirely, and simply have each vfd get marked "dirty" automatically when
written to. Both closing a vfd and the scan at xact commit would look
at the dirty bit to decide to do fsync.)

What would still need to be thought about is whether this scheme
preserves the ordering guarantee when a group of concurrent backends
is considered, rather than one backend in isolation. (I believe that
fsync() will apply to all dirty kernel buffers for a file, not just
those dirtied by the requesting process, so each backend's fsyncs can
affect the order in which other backends' writes hit the disk.)
Offhand I do not see any problems there, but it's the kind of thing
that requires more than offhand thought...

Glad someone is looking into this. Seems the above concern about order
is fine because it is only marking the pg_log transactions as committed
that is important. You can fsync anything you want, you just need to
make sure you current transactions buffers are fsync'ed before you mark
the transaction as complete.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Feb 6 12:58:24 2000
Received: from beth.bacbuc.fdn.fr (root@d168.paris-228.cybercable.fr
[212.198.228.168]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA26211
for <pgsql-hackers@postgresql.org>; Sun, 6 Feb 2000 12:57:33 -0500 (EST)
(envelope-from charpent@bacbuc.dyndns.org)
Received: from localhost.localdomain (really [193.57.55.1]) by bacbuc.fdn.fr
via in.smtpd with smtp (ident charpent using rfc1413)
id <m12HVwB-000QgVC@beth.bacbuc.fdn.fr> (Debian Smail3.2.0.101)
for <pgsql-hackers@postgresql.org>;
Sun, 6 Feb 2000 18:57:31 +0100 (CET)
From: Emmanuel Charpentier <charpent@bacbuc.dyndns.org>
Date: Sun, 06 Feb 2000 17:57:42 GMT
Message-ID: <20000206.17574200@localhost.localdomain>
Subject: An introduction and a plea ...
To: pgsql-hackers@postgresql.org
Reply-To: charpent@bacbuc.dyndns.org
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Linux)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id MAA26279

Dear pgsql-hackers list,

First a few words of introduction : I'm 43 and, while I have been
introduced to computing for a long time (my first exposure was a small
Fortran exercise I wrote in '74 (!) for a timesharing system on an
hardcopy terminal ...), my coding abilities are somewhat rusty. I am
mainly a user by now, no longer a coder, and my interests in computers
is now in making my life simpler (I'm a biostatistician, among other
things).I probably won't be contributing any code to PostgreSQL. Some
bug reports, maybe ...

However, I've lurked on some of the PostgreSQL lists for 2 to 3 months
(through the Web interface), and I feel that I might offer some
advice, based on my past experience of seeing a lot of projects
growing (or dying, due to feeping creaturism(TM) ...).

So I will shamelessly pull my first plea, related to the proposed
change to the default behaviour of PostgreSQL in querying classes with
subclasses.

I *strongly* suggest not to change anything in the default behaviour,
which is what is expected from an SQL-compliant system, even if the
database in question uses inheritance internally.

The reason for that plea is that a modification would crash any
program not explicitly written for inheritance features : such
features might be used by, say, the administrator and coere
programmers of a database, who are not necessarily publish this
internal use of inheritance to end-users. Furthermore, such a change
would forbid evolution of a database from a pure-relational to an
object-orien,ted one : the two representations would be incompatible.

It should also pointed out that most interface programs (such as ODBC
or JDBC drivers) are not and will not in a foreseeable future be
designed for use of these features. Modifying the default behaviour
would break them.

Apart from that, I am, after 17 years of exposure to the concepts of
object-oriented programming, still to be convinced of the value of
this paradigm. This is *not* to suggest that these developments should
be left over ! However, I *feel* that the real issues behind this
concept are not yet fully understood, and that some deep theoretical
work remains to be done (in logic, for example : while the
well-understood relational theory directly relates to set theory, I
think that a mathematically correct objects-and-types theory shoud
emanate from category theory but remains to be created ...).

Your thoughs ?

Emmanuel Charpentier

From bouncefilter Sun Feb 6 14:53:26 2000
Received: from tycho.rlent.pnet (IDENT:root@roberts.dialup.access.net
[166.84.193.218]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA66781
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 14:52:43 -0500 (EST)
(envelope-from roberts@panix.com)
Received: (from roland@localhost)
by tycho.rlent.pnet (8.9.3/8.9.3) id OAA08121;
Sun, 6 Feb 2000 14:52:41 -0500
Sender: roland@rlent.pnet
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql -e and -n flags
References: <Pine.LNX.4.21.0002052024330.429-100000@localhost.localdomain>
<389DA2A0.EC14B8D3@alumni.caltech.edu>
Reply-To: roberts@panix.com
From: Roland Roberts <roberts@panix.com>
In-Reply-To: Thomas Lockhart's message of "Sun, 06 Feb 2000 16:34:40 +0000"
Date: 06 Feb 2000 14:52:41 -0500
Message-ID: <m2aelecdme.fsf@tycho.rlent.pnet>
Lines: 15

"tl" == Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

tl> I'd suggest a switch style like "-ee" or "-eb" (backend) or
tl> "-ev" (verbatim) or ??? Comments?

With the typical switch bundling, how is -ee different from -e -e? It
is not unusual for programs to use -v for `verbose' with multiple -v's
possible.

roland
--
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD Custom Software Solutions
roberts@panix.com 76-15 113th Street, Apt 3B
rbroberts@acm.org Forest Hills, NY 11375

From bouncefilter Sun Feb 6 15:28:26 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA74410
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 15:27:57 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id PAA00790;
Sun, 6 Feb 2000 15:26:57 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-reply-to: <200002060441.XAA22920@candle.pha.pa.us>
References: <200002060441.XAA22920@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sat, 05 Feb 2000 23:41:34 -0500"
Date: Sun, 06 Feb 2000 15:26:57 -0500
Message-ID: <787.949868817@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

This looks like it should be a fairly straightforward change: we should
meld make_join_rel and get_join_rel so that a requested join rel is
first searched for in root->join_rel_list, and only built if not present
(like get_base_rel). The join rel would have a flat relids list from the
beginning, since it would be agnostic about which inner and outer subset
rels should be used to produce it.

Well, drat. This idea looked good, and I still think it's good, but
implementation turns out to be trickier than I thought. I was thinking
that RelOptInfos for join rels were essentially independent of which
pair of sub-relations were used to produce them --- eg, {1 2 3} doesn't
care if you made it from {1 2} joined to 3 or {1 3} joined to 2, etc.
That's almost true ... but it falls down on the restrictinfo list,
because which qual clauses are restrictions at a particular join level
*does* depend on the path you took to build it. For example, if you
have a qual clause "t1.v1 = t2.v2", this clause will be a restrict
clause for {1 2 3} if you make it from {1 3} joined to 2, but if you
make it from {1 2} joined to 3 then the clause was already handled when
{1 2} was produced.

We could still unify the RelOptInfos for different ways of making the
same joinrel if we stored restrictinfo lists for joins in individual
join paths, rather than in the RelOptInfo. I think that might be worth
doing, but the change is looking larger and subtler than I thought.
Probably best not to try to squeeze it in right before beta.

I will set aside the code I already rewrote for this purpose, and come
back to it after we start 7.1.

regards, tom lane

From bouncefilter Sun Feb 6 15:58:27 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA11618
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 15:57:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id PAA00936;
Sun, 6 Feb 2000 15:57:18 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-reply-to: <787.949868817@sss.pgh.pa.us>
References: <200002060441.XAA22920@candle.pha.pa.us>
<787.949868817@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Sun, 06 Feb 2000 15:26:57 -0500"
Date: Sun, 06 Feb 2000 15:57:18 -0500
Message-ID: <933.949870638@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I will set aside the code I already rewrote for this purpose, and come
back to it after we start 7.1.

Wait a minute ... stop the presses ...

I just realized that the bug I was complaining of is *already there
in current sources*, and has been for a while (certainly since 6.5).
Look at prune.c's code that merges together RelOptInfos after-the-
fact:

if (same(rel->relids, unmerged_rel->relids))
{
/*
* These rels are for the same set of base relations,
* so get the best of their pathlists. We assume it's
* ok to reassign a path to the other RelOptInfo without
* doing more than changing its parent pointer (cf. pathnode.c).
*/
rel->pathlist = add_pathlist(rel,
rel->pathlist,
unmerged_rel->pathlist);
}

This is wrong, wrong, wrong, because the paths coming from different
RelOptInfos (different pairs of sub-relations) may need different sets
of qual clauses applied as restriction clauses. There's no way to
represent that in the single RelOptInfo that will be left over. The
worst case is that the generated plan is missing a needed restriction
clause (the other possibility is that the clause is evaluated
redundantly, which is much less painful).

I am not sure why we haven't heard bug reports about this. It seems
like it wouldn't be hard at all to provoke the failure (I'm going to
try to make a test case right now). Assuming I can do that, I think
we have no choice but to move join restrictlists into JoinPath nodes.

regards, tom lane

From bouncefilter Sun Feb 6 17:02:27 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA31681
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 17:02:02 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA06005;
Sun, 6 Feb 2000 16:59:45 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002062159.QAA06005@candle.pha.pa.us>
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-Reply-To: <787.949868817@sss.pgh.pa.us> from Tom Lane at "Feb 6,
2000 03:26:57 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 6 Feb 2000 16:59:45 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

We could still unify the RelOptInfos for different ways of making the
same joinrel if we stored restrictinfo lists for joins in individual
join paths, rather than in the RelOptInfo. I think that might be worth
doing, but the change is looking larger and subtler than I thought.
Probably best not to try to squeeze it in right before beta.

I will set aside the code I already rewrote for this purpose, and come
back to it after we start 7.1.

What happened to the time-honored tradition of jamming partially-tested
features in before the beta feature freeze. Are we getting too
conservative in our old age? :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Feb 6 17:14:27 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA33394
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 17:13:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA06571;
Sun, 6 Feb 2000 17:13:15 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002062213.RAA06571@candle.pha.pa.us>
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-Reply-To: <787.949868817@sss.pgh.pa.us> from Tom Lane at "Feb 6,
2000 03:26:57 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 6 Feb 2000 17:13:15 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Well, drat. This idea looked good, and I still think it's good, but
implementation turns out to be trickier than I thought. I was thinking
that RelOptInfos for join rels were essentially independent of which
pair of sub-relations were used to produce them --- eg, {1 2 3} doesn't
care if you made it from {1 2} joined to 3 or {1 3} joined to 2, etc.
That's almost true ... but it falls down on the restrictinfo list,
because which qual clauses are restrictions at a particular join level
*does* depend on the path you took to build it. For example, if you
have a qual clause "t1.v1 = t2.v2", this clause will be a restrict
clause for {1 2 3} if you make it from {1 3} joined to 2, but if you
make it from {1 2} joined to 3 then the clause was already handled when
{1 2} was produced.

I thought "t1.v1 = t2.v2" would be in t1 RelOptInfo and t2 RelOptInfo.
Of course, this is a join info restriction, not a restrict info
restriction.

We could still unify the RelOptInfos for different ways of making the
same joinrel if we stored restrictinfo lists for joins in individual
join paths, rather than in the RelOptInfo. I think that might be worth
doing, but the change is looking larger and subtler than I thought.
Probably best not to try to squeeze it in right before beta.

Aren't the restrict-info/join-info of the Final RelOptInfo set only when
the cheapest is found, and before that, the individual Reloptinfo's
restrict-info/join-info that are part of the Path are used? Maybe these
are stupid questions.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Feb 6 17:17:27 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA33860
for <hackers@postgresql.org>; Sun, 6 Feb 2000 17:16:41 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id WAA22773
for <hackers@postgresql.org>; Sun, 6 Feb 2000 22:24:55 GMT
Sender: lockhart@hub.org
Message-ID: <389DF4B7.53AEA648@alumni.caltech.edu>
Date: Sun, 06 Feb 2000 22:24:55 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Need confirmation of "Posix time standard" on FreeBSD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Someone mentioned recently that a timezone style of "GMT+0800" was on
their FreeBSD machine as an allowed time zone, that its behavior was
the same as the usual ISO8601 timezone of "-0800", and that this
conformed to some sort of Posix standard.

I had posted patches for this, and have just modified the patch to be
cleaner and more robust.

Before committing this (or at least before completing our upcoming
beta period), I'd like confirmation that this actually matches
expected behavior for a machine implementing a "GMT+0800" (or similar)
time zone, and that it is indeed a Posix standard? Anyone??

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Sun Feb 6 17:40:28 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA40979
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 17:39:32 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA07100;
Sun, 6 Feb 2000 17:39:11 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-reply-to: <200002062213.RAA06571@candle.pha.pa.us>
References: <200002062213.RAA06571@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 06 Feb 2000 17:13:15 -0500"
Date: Sun, 06 Feb 2000 17:39:11 -0500
Message-ID: <7097.949876751@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I thought "t1.v1 = t2.v2" would be in t1 RelOptInfo and t2 RelOptInfo.
Of course, this is a join info restriction, not a restrict info
restriction.

Right, it would appear in t1's joininfo list (showing t2 as unjoined_relids)
and in t2's joininfo list (showing t1 as unjoined_relids). Then when
we make a join rel from t1 + t2, the clause would be put into that rel's
restrictinfo list, since it's no longer a joining clause for the
joinrel; but it does need to be implemented at the time of the join.
(The bug is probably only visible for auxiliary quals that are not
being used as the driving clause of the join method; they need to show
up in the qpquals of the final plan, or they won't get enforced.)

The trouble comes when there are more rels in the picture. If we make
a joinrel from t1 + t3, this clause will still appear in that joinrel's
joininfo list, since it's still a joinclause for that rel. Then when
we make t1+t2+t3 from {t1 t3} and {t2}, the clause propagates up to
become a restrict clause of that rel, and that's where the buck stops
(and where the clause gets enforced at runtime).

*BUT*, if we make {t1 t2 t3} from {t1 t2} and {t3}, it will *not* show
this clause as a restrictclause, because in that path it gets handled at
the {t1 t2} join. So a joinpath for {t1 t3} against {t2}, which needs
this clause to appear as a restrictclause, loses if it is copied into a
{t1 t2 t3} RelOptInfo that was made from the other pair of
sub-relations.

I find that I can exhibit the bug very easily in current sources:

create table t1 (k1 int, d1 int);
create table t2 (k2 int, d2 int);
create table t3 (k3 int, d3 int);
create table t4 (k4 int, d4 int);

insert into t1 values (1, 1);
insert into t1 values (2, 2);
insert into t1 values (3, 3);

insert into t2 values (1, 11);
insert into t2 values (2, 22);
insert into t2 values (3, 33);

insert into t3 values (1, 111);
insert into t3 values (2, 222);
insert into t3 values (3, 333);

insert into t4 values (1, 1111);
insert into t4 values (2, 2222);
insert into t4 values (3, 3333);

select * from t1,t2,t3,t4 where k1 = k2 and k1 = k3 and k2=k4
and d1<d2 and d1<d3 and d1<d4 and d2<d3 and d2<d4 and d3>d4;

k1 | d1 | k2 | d2 | k3 | d3 | k4 | d4
----+----+----+----+----+-----+----+------
1 | 1 | 1 | 11 | 1 | 111 | 1 | 1111
2 | 2 | 2 | 22 | 2 | 222 | 2 | 2222
3 | 3 | 3 | 33 | 3 | 333 | 3 | 3333
(3 rows)

which is obviously not meeting the restriction d3>d4. So we have
a problem.

I haven't been able to make 6.5.3 fail similarly, but I do not
understand why not --- it certainly looks like it *ought* to fail given
the right combination of circumstances. I think it may be escaping a
failure by sheer luck having to do with the order that RelOptInfos get
inserted into the query's join_rel_list. Our changes since 6.5 may have
exposed a problem that was only latent before. (Or maybe I just haven't
hit the right combination to trip up 6.5.3 ... but it does seem that
current sources fail more easily.)

Anyway, in the current sources things are certainly broken, and I don't
see any real alternative except to press forward with moving join
restrictinfos into JoinPaths. Even if we figure out exactly why 6.5.*
is somehow failing to fail, I am pretty certain that it must be a
non-robust coincidence rather than a solution that we want to keep using.

regards, tom lane

From bouncefilter Sun Feb 6 17:47:28 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA42059
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 17:46:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA07995;
Sun, 6 Feb 2000 17:43:52 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002062243.RAA07995@candle.pha.pa.us>
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-Reply-To: <7097.949876751@sss.pgh.pa.us> from Tom Lane at "Feb 6,
2000 05:39:11 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 6 Feb 2000 17:43:52 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I thought "t1.v1 = t2.v2" would be in t1 RelOptInfo and t2 RelOptInfo.
Of course, this is a join info restriction, not a restrict info
restriction.

Right, it would appear in t1's joininfo list (showing t2 as unjoined_relids)
and in t2's joininfo list (showing t1 as unjoined_relids). Then when
we make a join rel from t1 + t2, the clause would be put into that rel's
restrictinfo list, since it's no longer a joining clause for the
joinrel; but it does need to be implemented at the time of the join.
(The bug is probably only visible for auxiliary quals that are not
being used as the driving clause of the join method; they need to show
up in the qpquals of the final plan, or they won't get enforced.)

I understand. Is it only non-equi-joins that show this, where the join
is actually also a restriction in a sense.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Feb 6 17:51:28 2000
Received: from beth.bacbuc.fdn.fr (root@d168.paris-228.cybercable.fr
[212.198.228.168]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA42826
for <pgsql-hackers@postgresql.org>; Sun, 6 Feb 2000 17:51:25 -0500 (EST)
(envelope-from charpent@bacbuc.dyndns.org)
Received: from localhost.localdomain (really [193.57.55.1]) by bacbuc.fdn.fr
via in.smtpd with smtp (ident charpent using rfc1413)
id <m12HaWZ-000QgVC@beth.bacbuc.fdn.fr> (Debian Smail3.2.0.101)
for <pgsql-hackers@postgresql.org>;
Sun, 6 Feb 2000 23:51:23 +0100 (CET)
From: Emmanuel Charpentier <charpent@bacbuc.dyndns.org>
Date: Sun, 06 Feb 2000 22:51:34 GMT
Message-ID: <20000206.22513400@localhost.localdomain>
Subject: Case sensitivity issues
To: pgsql-hackers@postgresql.org
Reply-To: charpent@bacbuc.dyndns.org
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Linux)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id RAA42831

It seems that PostgreSQKL might have a case-sensitivity problem.

Sorry to post that here. I tried to post on pgsql-interfaces, and my
post has bounced (for no reason I have been able to fathom : the
subject line of the bounce messageb is : BOUNCE
pgsql-interfaces@postgreSQL.org: Admin request of type /^\s*config\b/i
at line 7. Beats me ...). I searched on the web site a reference to a
list manager, didn't find it ...

Feel free to flame if this is not the correct procedure ... :-)).

Emmanuel Charpentier

Bounced post follows :

From bouncefilter Sun Feb 6 13:38:25 2000

Received: from beth.bacbuc.fdn.fr (root@d168.paris-228.cybercable.fr
[212.198.228.168])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA39566
for <pgsql-interfaces@postgresql.org>; Sun, 6 Feb 2000 13:37:49 -0500
(EST)
(envelope-from charpent@bacbuc.dyndns.org)
Received: from localhost.localdomain (really [193.57.55.1]) by
bacbuc.fdn.fr
via in.smtpd with smtp (ident charpent using rfc1413)
id <m12HWZA-000QgVC@beth.bacbuc.fdn.fr> (Debian Smail3.2.0.101)
for <pgsql-interfaces@postgresql.org>; Sun, 6 Feb 2000 19:37:48 +0100
(CET)
From: Emmanuel Charpentier <charpent@bacbuc.dyndns.org>
Date: Sun, 06 Feb 2000 18:37:59 GMT
Message-ID: <20000206.18375900@localhost.localdomain>
Subject: Case sensitivity in ODBC ??
To: pgsql-interfaces@postgresql.org
Reply-To: charpent@bacbuc.dyndns.org
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Linux)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id
NAA39635

Dear pgsql-interface list,

I have lived that SQL database were not to be case-sensitive. However,
it seems that, at least through the ODBC interface, PostgreSQL 6.5.3
is :

Config : Linux RedHat 6.1, PostgreSQL 6.5.3 from the PostgreSQL ftp
site's RPM, unixODBC1.7 (including their PostgreSQL driver). Works
great from various interfaces (including StarOffice ...).

I'm working from the R statistical language/package through a beta
ODBC interface. Note that the interpreted R language is case-sensitive
...

Logical Setup

R user interface ---> RODBC library ---> unixODBC ---> PostgreSQL
^
|
I'm trying to enhance that---+

This interface mostly works, but has some odd behaviour :

sqlQuery(chan1,"create table Test1 (id int4 not null primary key, val

varchar(255))") /* This creates the table test1, correctly */

sqlColumns(chan1,"test1") /* Sanity check */

TABLE_QUALIFIER TABLE_OWNER TABLE_NAME COLUMN_NAME DATA_TYPE
TYPE_NAME
1 NA NA test1 id 4
int4
2 NA NA test1 val 12
varchar
PRECISION LENGTH SCALE RADIX NULLABLE REMARKS DISPLAY_SIZE
FIELD_TYPE
1 10 4 0 10 0 NA 11
23
2 254 254 NA NA 1 NA 254
1043
/* This is the expected answer */

sqlTables(chan1)

TABLE_QUALIFIER TABLE_OWNER TABLE_NAME TABLE_TYPE REMARKS
1 NA NA pga_forms TABLE NA
2 NA NA pga_layout TABLE NA
3 NA NA pga_queries TABLE NA
4 NA NA pga_reports TABLE NA
5 NA NA pga_schema TABLE NA
6 NA NA pga_scripts TABLE NA
7 NA NA test1 TABLE NA
/* This also is the expected answer. Note however that the name of the
table is lowercased */

sqlColumns(chan1,"Test1") /* Same sanity check, with the original name

*/
Error in sqlColumns(chan1, "Test1") : Test1 :table not found on
channel 0
/* This is unexpected if SQL, PostgreSQL and ODBC are case-insensitive
*/

Furthermore : debugging shows that the initial request for table
creation seds the name with its capital, as shown in the next example
:

sqlSave(chan1,USArrests,rownames="State") /* The sqlSave function

creates the necessary table if it does not exists */
[1]: "CREATE TABLE USArrests (State varchar(255) ,Murder varchar(255) ,Assault varchar(255) ,UrbanPop varchar(255) ,Rape varchar(255) )" /* This is a debugging output showing the exact request sent to PosstgreSQL, minus the ending semicolumn. Yes the types are ridiculous, and that's what I'm trying to fix ... */ Error in sqlColumns(channel, tablename) : USArrests :table not found on channel 0 /* This is an (unexpected) error message*/
,Assault varchar(255) ,UrbanPop varchar(255) ,Rape varchar(255) )"
/* This is a debugging output showing the exact request sent to
PosstgreSQL, minus the ending semicolumn. Yes the types are
ridiculous, and that's what I'm trying to fix ... */
Error in sqlColumns(channel, tablename) : USArrests :table not found
on channel 0
/* This is an (unexpected) error message*/

sqlTables(chan1)

TABLE_QUALIFIER TABLE_OWNER TABLE_NAME TABLE_TYPE REMARKS
1 NA NA pga_forms TABLE NA
2 NA NA pga_layout TABLE NA
3 NA NA pga_queries TABLE NA
4 NA NA pga_reports TABLE NA
5 NA NA pga_schema TABLE NA
6 NA NA pga_scripts TABLE NA
7 NA NA usarrests TABLE NA
/* A table ��� usarrests ��� has been created, but querying ��� USArrests ���
does not work. However :*/

sqlColumns(chan1,"usarrests")

TABLE_QUALIFIER TABLE_OWNER TABLE_NAME COLUMN_NAME DATA_TYPE
TYPE_NAME
1 NA NA usarrests state 12
varchar
2 NA NA usarrests murder 12
varchar
3 NA NA usarrests assault 12
varchar
4 NA NA usarrests urbanpop 12
varchar
5 NA NA usarrests rape 12
varchar
PRECISION LENGTH SCALE RADIX NULLABLE REMARKS DISPLAY_SIZE
FIELD_TYPE
1 254 254 NA NA 1 NA 254
1043
2 254 254 NA NA 1 NA 254
1043
3 254 254 NA NA 1 NA 254
1043
4 254 254 NA NA 1 NA 254
1043
5 254 254 NA NA 1 NA 254
1043

/* Querying ��� usarrests ��� does ! Note that column names have been
lowercased as well ... */

This seems to me proof enough that the behaviour of PostgreSQL (or
ODBC driver) related to case sensitivity is not coherent.

Could some kind soul shed some light on this ?

Thanks in advance,

Emmanuel Charpentier

From bouncefilter Sun Feb 6 18:02:29 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA48202
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 18:02:07 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA04570; Mon, 7 Feb 2000 10:01:34 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdEaw_k_;
Mon Feb 7 10:00:58 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA21821; Mon, 7 Feb 2000 10:00:55 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdrBOTJ_; Mon Feb 7 10:00:10 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA02022;
Mon, 7 Feb 2000 10:00:09 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
JAA21569; Mon, 7 Feb 2000 09:59:26 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389DFCA0.8686F29A@nimrod.itg.telecom.com.au>
Date: Mon, 07 Feb 2000 09:58:40 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: charpent@bacbuc.dyndns.org
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] An introduction and a plea ...
References: <20000206.17574200@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Emmanuel Charpentier wrote:

I *strongly* suggest not to change anything in the default behaviour,
which is what is expected from an SQL-compliant system, even if the
database in question uses inheritance internally.

Can I assure you that these changes have NO EFFECT on anybody who
does not use inheritance. i.e. Postgres will remain as SQL compliant
as it was before.

The reason for that plea is that a modification would crash any
program not explicitly written for inheritance features.

No it won't. If you don't use inheritance, you will not be effected in
any way.

: such
features might be used by, say, the administrator and coere
programmers of a database, who are not necessarily publish this
internal use of inheritance to end-users. Furthermore, such a change
would forbid evolution of a database from a pure-relational to an
object-orien,ted one : the two representations would be incompatible.

It should also pointed out that most interface programs (such as ODBC
or JDBC drivers) are not and will not in a foreseeable future be
designed for use of these features. Modifying the default behaviour
would break them.

In my opinion, this change will give users of ODBC and such tools MORE
useful defaults. Of course if you are using a non-OO interface to an OO
database there will always be things you can't do. But IMHO, this gives
a more useful set of defaults as a trasition phase.

For example, currently if I have student and employee inheriting from
person, ODBC query of SELECT * from person will return... NOTHING! After
these changes the query will return all the persons (which happen to
be students and employees).

Apart from that, I am, after 17 years of exposure to the concepts of
object-oriented programming, still to be convinced of the value of
this paradigm. This is *not* to suggest that these developments should
be left over ! However, I *feel* that the real issues behind this
concept are not yet fully understood, and that some deep theoretical
work remains to be done (in logic, for example : while the
well-understood relational theory directly relates to set theory, I
think that a mathematically correct objects-and-types theory shoud
emanate from category theory but remains to be created ...).

Well, the fact is people are using OO now, and it's hard for me to
explain the development advantages of an OO database to someone who
is not coding. But if you really want to find out why an OO database
is good, head on over to versant.com or odi.com, download the database
and write a small application. Apart from anything else, some people
need the improved performance NOW, and can't wait for the academics
to give their stamp of approval. And OO database coding simplicity
is saving millions of $$$ NOW.

From bouncefilter Sun Feb 6 18:15:28 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA50315
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 18:14:33 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA07153;
Sun, 6 Feb 2000 18:14:24 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-reply-to: <7097.949876751@sss.pgh.pa.us>
References: <200002062213.RAA06571@candle.pha.pa.us>
<7097.949876751@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Sun, 06 Feb 2000 17:39:11 -0500"
Date: Sun, 06 Feb 2000 18:14:24 -0500
Message-ID: <7150.949878864@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Anyway, in the current sources things are certainly broken, and I don't
see any real alternative except to press forward with moving join
restrictinfos into JoinPaths. Even if we figure out exactly why 6.5.*
is somehow failing to fail,

Er ... um ... ahem ... DUH! The reason 6.5.3 works is that it does in
fact keep join restrictinfo pointers in JoinPaths. I had eliminated
those pointers (the thoroughly undocumented "pathinfo" field) because
I thought that the lists were always the same as the parent relations'
restrictinfo lists. Which they were --- at the time of creation of a
JoinPath. What I missed was that prune.c moved a joinpath to belong
to a different RelOptInfo with (potentially) a different restrictinfo
list, but the joinpath needs to keep its original restrictinfo list.

In other words, I broke it.

Since surgery needs to be done anyway, I'm inclined to press ahead
with the changes I was going to put off. On the other hand, if the
patient had a vote, it might ask for a second opinion ;-)

regards, tom lane

From bouncefilter Sun Feb 6 18:18:28 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA50880
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 18:18:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA13200;
Sun, 6 Feb 2000 18:17:33 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002062317.SAA13200@candle.pha.pa.us>
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-Reply-To: <7150.949878864@sss.pgh.pa.us> from Tom Lane at "Feb 6,
2000 06:14:24 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 6 Feb 2000 18:17:33 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Er ... um ... ahem ... DUH! The reason 6.5.3 works is that it does in
fact keep join restrictinfo pointers in JoinPaths. I had eliminated
those pointers (the thoroughly undocumented "pathinfo" field) because
I thought that the lists were always the same as the parent relations'
restrictinfo lists. Which they were --- at the time of creation of a
JoinPath. What I missed was that prune.c moved a joinpath to belong
to a different RelOptInfo with (potentially) a different restrictinfo
list, but the joinpath needs to keep its original restrictinfo list.

In other words, I broke it.

Since surgery needs to be done anyway, I'm inclined to press ahead
with the changes I was going to put off. On the other hand, if the
patient had a vote, it might ask for a second opinion ;-)

Go for it. Beta is for testing. No better time to break things than
the present.

This is the first time I remember hearing about pre-beta release jitters
from many people.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Feb 6 18:22:28 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA51673
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 18:22:02 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA07405;
Sun, 6 Feb 2000 18:21:58 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-reply-to: <200002062317.SAA13200@candle.pha.pa.us>
References: <200002062317.SAA13200@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 06 Feb 2000 18:17:33 -0500"
Date: Sun, 06 Feb 2000 18:21:57 -0500
Message-ID: <7402.949879317@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

This is the first time I remember hearing about pre-beta release jitters
from many people.

Maybe our standards have gotten higher than they used to be. I know
I really want 7.0 to be rock-solid, because I expect a lot of people
will be taking a new look at us when it comes out.

regards, tom lane

From bouncefilter Sun Feb 6 18:28:28 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA52788
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 18:27:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA17341;
Sun, 6 Feb 2000 18:26:52 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002062326.SAA17341@candle.pha.pa.us>
Subject: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
In-Reply-To: <7402.949879317@sss.pgh.pa.us> from Tom Lane at "Feb 6,
2000 06:21:57 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 6 Feb 2000 18:26:52 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <pgman@candle.pha.pa.us> writes:

This is the first time I remember hearing about pre-beta release jitters
from many people.

Maybe our standards have gotten higher than they used to be. I know
I really want 7.0 to be rock-solid, because I expect a lot of people
will be taking a new look at us when it comes out.

I had a terrible habit of trowing things in. I guess we are getting
more professional.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Feb 6 19:00:30 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA61893
for <hackers@postgreSQL.org>; Sun, 6 Feb 2000 19:00:25 -0500 (EST)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (max02-021.enterprise.net [194.72.195.141])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id AAA11421;
Mon, 7 Feb 2000 00:00:20 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id AAA04871;
Mon, 7 Feb 2000 00:00:19 GMT
Message-Id: <200002070000.AAA04871@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>, olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Need confirmation of "Posix time standard" on FreeBSD
In-Reply-To: Message from Thomas Lockhart <lockhart@alumni.caltech.edu>
of "Sun,
06 Feb 2000 22:24:55 GMT." <389DF4B7.53AEA648@alumni.caltech.edu>
References: <389DF4B7.53AEA648@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 07 Feb 2000 00:00:19 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>

Thomas Lockhart wrote:

Someone mentioned recently that a timezone style of "GMT+0800" was on
their FreeBSD machine as an allowed time zone, that its behavior was
the same as the usual ISO8601 timezone of "-0800", and that this
conformed to some sort of Posix standard.

I had posted patches for this, and have just modified the patch to be
cleaner and more robust.

Before committing this (or at least before completing our upcoming
beta period), I'd like confirmation that this actually matches
expected behavior for a machine implementing a "GMT+0800" (or similar)
time zone, and that it is indeed a Posix standard? Anyone??

This seems to be the case for me.

Debian GNU/Linux, using libc6 version 2.1.2:

linda:olly $ date
Sun Feb 6 23:55:52 GMT 2000
linda:olly $ TZ=GMT+8
linda:olly $ date
Sun Feb 6 15:56:26 GMT 2000
linda:olly $ TZ=posix/Etc/GMT+8
linda:olly $ date
Sun Feb 6 15:59:22 GMT+8 2000

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Lift up your heads, O ye gates; and be ye lift up, ye
everlasting doors; and the King of glory shall come
in. Who is this King of glory? The LORD strong and
mighty, the LORD mighty in battle."
Psalms 24:7,8

From bouncefilter Sun Feb 6 19:27:30 2000
Received: from hu.tm.ee (ppp782.tele2.ee [212.107.37.82])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA69261
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 19:27:25 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id C822F396B; Mon, 7 Feb 2000 02:34:41 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389E1321.25AB8C40@tm.ee>
Date: Mon, 07 Feb 2000 02:34:41 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: charpent@bacbuc.dyndns.org
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] An introduction and a plea ...
References: <20000206.17574200@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Emmanuel Charpentier wrote:

However, I've lurked on some of the PostgreSQL lists for 2 to 3 months
(through the Web interface), and I feel that I might offer some
advice, based on my past experience of seeing a lot of projects
growing (or dying, due to feeping creaturism(TM) ...).

So I will shamelessly pull my first plea, related to the proposed
change to the default behaviour of PostgreSQL in querying classes with
subclasses.

I *strongly* suggest not to change anything in the default behaviour,
which is what is expected from an SQL-compliant system, even if the
database in question uses inheritance internally.

I agree wrt the * returning different types of tuples from different
subtypes.

I somewhata disagree about default selects/updates/deletes working on
inherited tables by default - If we want PostgreSQL to evolve back
to an ORDBMS.

We should not change the defaul _yet_, but we should not exclude
the change in future. rather we should acknowledge the current state of
affairs wrt inheritance and declare it deprecated (dont use in new projects,
start fixing your old ones)

The reason for that plea is that a modification would crash any
program not explicitly written for inheritance features : such
features might be used by, say, the administrator and coere
programmers of a database, who are not necessarily publish this
internal use of inheritance to end-users.

I saw something similar when going from python 1.5.1 to 1.5.2 - suddenly
some broken usage became a show-stopping bug instead of just ignering it
with some hidden default usage. It did not byte me directly, but several
of our developers had never read the introductory parts of docs, or had
not understood what was said.

Currently inheritance features can be used in a very limited way -

1. for defining a table that shares some columns with some other table(s)
this usage is actually broken, as it currently results in tables that can't
be dumped properly after columns are added, and thus should be discouraged
anyway until it is fixed.

2. for selecting (and not updating/deleting) from a group of said broken
tables, using a non-ansi syntax. The performance is also most likely
suboptimal, as indexes are not inherited.

Therefore I would propose the following, more radical approach -

* officially acknowledge the current lacking OO support of PostgreSQL and
declare the current usages deprecated and soon-to-be-removed in 7.0

* not remove the support for them in the backend, but instead start to
investigate ways to fix the buga and add the missing features.

* hide the OO development behind "set ORDBMS to 'ON'", which case would
behave in the new way for the current two OO features
(create .. inherits .., and select), if it is set to 'off' (the default)
spit out a warning on each use but behave compatibly.
(maybe make psql check if it is invoked as osql and send the set command
automatically)

* for migrating databases provide a way to dump inherited tables as standalone
so that it would be easy for people to clear up the inherits-as-macro usage

* The OO development should solve the following problems (independent of which
syntax will be eventually used)

1. if a table inherits another table, it has to (at least) inherit the
following by default

1.1 columns - in a way that allows add/delete column (requires changes to
storage manager, probably introduction of deleted/missing columns)

1.2 indexes, both unique and ordinary, where unique indexes should be
unique
_over_all_tables_ involved

1.3 constraints, including being the foreign end of foreign key constraint

2. a way to go from OID to tuple

The must efficient solution seems to be a file with a simple structure
that
has records of (TUPLE_OID,TABLE_OID) wher a record is added at each
insert.
As this file is ordered wrt. TULE_OID and has fixed size records, it can
be efficiently searche with binary search. As it is append-only it is also
quite (probably most) efficient on inserts. I can't think of any solutions
using current structures which would be nearly as efficient. If we
sacrifice
space for lookup speed we may write all oids and never shrink that file
and
have a computed lookup whic would require at most one disk access per oid
lookup. We could use some kind of weighted binary search in any case.

The same kind of file could be used for re_introducing time-travel in an
efficient way.

3. a way to get full tuples (tuple type + all columns) from inherited
tables.

This would require minimal changes to wire protocol, but more changes to
client API's.

4.possibly a bit unrelated to OO, but still a must-do - Start working on a
binary cross-platform protocol, that could be used for _both_
insert/update/delete and select (instead of current single-platform select
only binary protocol)

It would mean adding PREPARE to the backend (already exists in SPI)
as well as smarter client libraries that would expose it and that could
marshal binary data given to BIND over wire. Having PREPARE-d queries
can also speed up our performance on standard benchmarks, as much of
prepare/optimise can be skipped.

From there on it gets a bit foggy as it is really a distant future (possibly
more than 1 year ;)

5. become even more object-oriented and add methods to tables that can do
different things depending on which table they operate on.

6. allow writing these mathods in a platform-independent language
(java/python/tcl/perl/...) and also passed from backend to frontend.

Furthermore, such a change
would forbid evolution of a database from a pure-relational to an
object-orien,ted one : the two representations would be incompatible.

Do you propose the two-separate-parsers way of doing things ?

It should also pointed out that most interface programs (such as ODBC
or JDBC drivers) are not and will not in a foreseeable future be
designed for use of these features. Modifying the default behaviour
would break them.

Standard SQL queries should give standard SQL responses.

OTOH, there is an evolving API for interfacing ObjectDatabases with Java

Apart from that, I am, after 17 years of exposure to the concepts of
object-oriented programming, still to be convinced of the value of
this paradigm.

My experience is exactly the opposite - after zenning the concept I'm unable
to write anything longer than 15 lines that is not OO, (with the possible
exclusion of SQL scripts, which do not fit nicely to that concept ;)

It does _not_ mean writing in an "OO language", but just a way of thinking
about problems and expressing these thoughts.

This is *not* to suggest that these developments should
be left over ! However, I *feel* that the real issues behind this
concept are not yet fully understood, and that some deep theoretical
work remains to be done

There will _always_ remain theoretical work to be done, at least for any
live concept.

(in logic, for example : while the
well-understood relational theory directly relates to set theory, I
think that a mathematically correct objects-and-types theory shoud
emanate from category theory but remains to be created ...).

Your thoughs ?

I suspect that OO programming as a whole could be complex enough that Goedels
theorem forbids any complete"mathematically correct objects-and-types theory"

----------------
Hannu

From bouncefilter Sun Feb 6 19:40:29 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA74847
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 19:39:56 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from tpf.co.jp ([126.0.1.56] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with ESMTP
id JAA12808; Mon, 07 Feb 2000 09:39:43 +0900
Message-ID: <389E148D.745D739C@tpf.co.jp>
Date: Mon, 07 Feb 2000 09:40:45 +0900
From: Hiroshi Inoue <Inoue@tpf.co.jp>
X-Mailer: Mozilla 4.51 [ja] (Win98; I)
X-Accept-Language: ja
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
References: <20000206154059U.t-ishii@sra.co.jp>
<200002060655.BAA09293@candle.pha.pa.us>
<20000206230412X.t-ishii@sra.co.jp> <24481.949852063@sss.pgh.pa.us>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

BTW, I have worked a little bit on this item. The idea is pretty
simple. Instead of doing a real fsync() in pg_fsync(), just marking it
so that we remember to do fsync() at the commit time. Following
patches illustrate the idea.

What would still need to be thought about is whether this scheme
preserves the ordering guarantee when a group of concurrent backends
is considered, rather than one backend in isolation. (I believe that
fsync() will apply to all dirty kernel buffers for a file, not just
those dirtied by the requesting process, so each backend's fsyncs can
affect the order in which other backends' writes hit the disk.)
Offhand I do not see any problems there, but it's the kind of thing
that requires more than offhand thought...

The following is an example of what I first pointed out.
I say about PostgreSQL shared buffers not kernel buffers.

Session-1
begin;
update A ...;

Session-2
begin;
select * fromB ..;
There's no PostgreSQL shared buffer available.
This backend has to force the flush of a free buffer
page. Unfortunately the page was dirtied by the
above operation of Session-1 and calls pg_fsync()
for the table A. However fsync() is postponed until
commit of this backend.

Session-1
commit;
There's no dirty buffer page for the table A.
So pg_fsync() isn't called for the table A.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Feb 6 19:55:29 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA77241
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 19:54:40 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA23494; Mon, 7 Feb 2000 11:54:08 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0iEdl3;
Mon Feb 7 11:53:48 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA02593; Mon, 7 Feb 2000 11:53:47 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd.6zlk_; Mon Feb 7 11:52:38 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA15889;
Mon, 7 Feb 2000 11:52:37 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
LAA25725; Mon, 7 Feb 2000 11:51:50 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389E16F7.CFB8CBCF@nimrod.itg.telecom.com.au>
Date: Mon, 07 Feb 2000 11:51:03 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Hannu Krosing <hannu@tm.ee>
CC: charpent@bacbuc.dyndns.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] An introduction and a plea ...
References: <20000206.17574200@localhost.localdomain>
<389E1321.25AB8C40@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hannu Krosing wrote:

2. a way to go from OID to tuple

The must efficient solution seems to be a file with a simple structure
that
has records of (TUPLE_OID,TABLE_OID) wher a record is added at each
insert.
As this file is ordered wrt. TULE_OID and has fixed size records, it can
be efficiently searche with binary search. As it is append-only it is also
quite (probably most) efficient on inserts. I can't think of any solutions
using current structures which would be nearly as efficient.

If you have your suggested indexes that apply over multiple relations, I
can't
see why that can't be used for this too. It just means that if you use
ODBMS it
is recommended that you do a CREATE INDEX oid_idx ON object (oid), where
"object"
is a conceptual super-class of all other objects.

Your append-only file would grow without limit, which I think is a bit
of a
problem for some apps. Also the way ODBMS will work is an application
will
ask for a chunk
of oids from the database, some of which may be later "wasted".(This is
how
Versant works and it is also a technique documented by Stonebraker in
his
postgres papers). This technique is so that applications don't have to
talk to the backend to create objects in the front end that need oids.
This means objects may not be created with oids in order.
So you have to store space for oids in your file that may not be used.

I think we need first more conventional style index that works well.
Then we
can experiment with more radical ideas.

The same kind of file could be used for re_introducing time-travel in an
efficient way.

How?

5. become even more object-oriented and add methods to tables that can do
different things depending on which table they operate on.

Does this definitely not work now?

From bouncefilter Sun Feb 6 20:14:32 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA83646
for <hackers@postgresql.org>; Sun, 6 Feb 2000 20:13:49 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12HckF-000LEMC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for hackers@postgresql.org; Sun, 6 Feb 2000 19:13:39 -0600 (CST)
Date: Sun, 6 Feb 2000 19:13:39 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Chris <chris@bitmead.com>
Cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Status of inheritance-changing patch
Message-ID: <20000206191339.A22682@rice.edu>
References: <389B9ACB.9F929BAE@bitmead.com> <7935.949770635@sss.pgh.pa.us>
<389CBEA0.984044ED@bitmead.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <389CBEA0.984044ED@bitmead.com>;
from chris@bitmead.com on Sun, Feb 06, 2000 at 11:21:52AM +1100

On Sun, Feb 06, 2000 at 11:21:52AM +1100, Chris wrote:

Tom Lane wrote:

(One thing that still needs to be looked at is
whether SQL 3 defines any comparable features, and
if so whether we ought to be following their syntax
and behavior.)

I just downloaded the SQL3 document from dec. I can't seem to make head
or tail of it. Can anybody understand what it's saying?

I can occasionall twist my brian in the specific way necessary to read
(and partially understand) standards. Got a URI for what you downloaded?

Ross

--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Sun Feb 6 20:27:30 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA85690
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 20:26:35 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA26032; Mon, 7 Feb 2000 12:26:03 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd03HVuR;
Mon Feb 7 12:25:33 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA21047; Mon, 7 Feb 2000 12:25:32 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpde3gzo_; Mon Feb 7 12:24:58 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA17277;
Mon, 7 Feb 2000 12:24:57 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
MAA26933; Mon, 7 Feb 2000 12:24:15 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389E1E8F.DBDDEDE3@nimrod.itg.telecom.com.au>
Date: Mon, 07 Feb 2000 12:23:27 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Hannu Krosing <hannu@tm.ee>
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] An introduction and a plea ...
References: <20000206.17574200@localhost.localdomain>
<389E1321.25AB8C40@tm.ee>
<389E16F7.CFB8CBCF@nimrod.itg.telecom.com.au>
<389E1F28.30DAB2A5@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hannu Krosing wrote:

The same kind of file could be used for re_introducing time-travel in an
efficient way.

How?

By writing (TID,TIMESTAMP) tuples there and using that info to retrieve tuples
active at specified time by examinimg TIDs in "deleted" tuples.
As bot TID and TIMESTAMP should be monotonuously growing again binary search
can be used on retrieve and inserts are append-only (meaning fast)

But since we are already storing all the time travel stuff already in
the
storage pages do we need this to reinstate time travel? Also if you
reinstate
time travel this way it will only work for people using this odbms
feature.
Wouldn't it be better to reinstate the old timetravel so it works for
everyone?

From bouncefilter Sun Feb 6 20:19:30 2000
Received: from hu.tm.ee (ppp782.tele2.ee [212.107.37.82])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA84351
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 20:18:41 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 326E03A16; Mon, 7 Feb 2000 03:26:00 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389E1F28.30DAB2A5@tm.ee>
Date: Mon, 07 Feb 2000 03:26:00 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: chris@bitmead.com
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] An introduction and a plea ...
References: <20000206.17574200@localhost.localdomain>
<389E1321.25AB8C40@tm.ee>
<389E16F7.CFB8CBCF@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Bitmead wrote:

Hannu Krosing wrote:

2. a way to go from OID to tuple

The must efficient solution seems to be a file with a simple structure
that
has records of (TUPLE_OID,TABLE_OID) wher a record is added at each
insert.
As this file is ordered wrt. TULE_OID and has fixed size records, it can
be efficiently searche with binary search. As it is append-only it is also
quite (probably most) efficient on inserts. I can't think of any solutions
using current structures which would be nearly as efficient.

If you have your suggested indexes that apply over multiple relations, I
can't see why that can't be used for this too.

The insert performance would be much worse for indexes than for append-only
file.

It just means that if you use ODBMS it is recommended that you do a
CREATE INDEX oid_idx ON object (oid), where "object"
is a conceptual super-class of all other objects.

Your append-only file would grow without limit, which I think is a bit
of a problem for some apps.

I meant vacuum to compress it (which AFAIK it does not do for indexes
currently)

Also the way ODBMS will work is an application will ask for a chunk
of oids from the database, some of which may be later "wasted".(This is
how Versant works and it is also a technique documented by Stonebraker in
his postgres papers). This technique is so that applications don't have to
talk to the backend to create objects in the front end that need oids.
This means objects may not be created with oids in order.
So you have to store space for oids in your file that may not be used.

Yes, it needs some more book-keeping than I thought (keep the oid-file pages
that could possibly be updated in memory until the front-end which requested
the oids disconnects), or just assume all oids will be used and compress the
unused ones below watermark out in VACUUM.

I think we need first more conventional style index that works well.
Then we can experiment with more radical ideas.

An index spanning multiple tables is quite radical anyway. Initially we could
get by with multiple indexes and extra (but slow) check for uniqueness (when
index is unique).

The same kind of file could be used for re_introducing time-travel in an
efficient way.

How?

By writing (TID,TIMESTAMP) tuples there and using that info to retrieve tuples
active at specified time by examinimg TIDs in "deleted" tuples.
As bot TID and TIMESTAMP should be monotonuously growing again binary search
can be used on retrieve and inserts are append-only (meaning fast)

Both cases assume that we are oriented on fast inserts, as b-tree would
probably
be faster than binary search on retrieves, but is much slower on inserts.

5. become even more object-oriented and add methods to tables that can do
different things depending on which table they operate on.

Does this definitely not work now?

AFAIK functions are selected based on their arguments which can be either a
full
tuple or several simple types, but not both.

So the first kind _may_ actually work, we must ask someone more familiar on
when
the actual function is selected for "SELECT T.func() from TAB* T" queries.

--------------
Hannu

From bouncefilter Sun Feb 6 21:30:30 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA01395
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 21:29:53 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA10158;
Sun, 6 Feb 2000 21:29:27 -0500 (EST)
To: charpent@bacbuc.dyndns.org
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Case sensitivity issues
In-reply-to: <20000206.22513400@localhost.localdomain>
References: <20000206.22513400@localhost.localdomain>
Comments: In-reply-to Emmanuel Charpentier <charpent@bacbuc.dyndns.org>
message dated "Sun, 06 Feb 2000 22:51:34 +0000"
Date: Sun, 06 Feb 2000 21:29:27 -0500
Message-ID: <10155.949890567@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Emmanuel Charpentier <charpent@bacbuc.dyndns.org> writes:

[ much snipped ]
This seems to me proof enough that the behaviour of PostgreSQL (or
ODBC driver) related to case sensitivity is not coherent.
Could some kind soul shed some light on this ?

It's hard to tell what your driver is doing, but the underlying backend
behavior is simple enough.

A table or field name written in an SQL query is forced to lowercase
*unless* it is written with double-quotes around it:

SELECT * FROM Table; -- refers to "table"

SELECT * FROM "Table"; -- refers to "Table"

Your debugging output shows that the CREATE TABLE statement is being
sent as-is, so the name is lowercased before the CREATE happens.
You didn't show what was being sent for your other queries like
sqlColumns(). I speculate that the driver is translating those into
SQL queries in which the provided name is quoted...

regards, tom lane

From bouncefilter Sun Feb 6 22:07:32 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA13518
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 22:06:55 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id TAA04614
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 19:06:28 -0800 (PST)
Message-Id: <3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 06 Feb 2000 19:04:18 -0800
To: pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: DISTINCT and ORDER BY bug?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

The following used to work in 6.5, works in Oracle, and is
very useful:

donb=# create table foo(c varchar);
CREATE
donb=# insert into foo values('abc');
INSERT 72649 1

donb=# select distinct c from foo order by upper(c);
ERROR: For SELECT DISTINCT, ORDER BY expressions must appear in target list
donb=#

In other words, we want to order ignoring case - in this case, users
within the Ars Digita Community system. We want don baccus to appear
next to Joe Blow rather than following Xena Xenophoba.

Is this now refused because it is non-standard? It seems a pity...

Of course, one can do "select distinct c, upper(c) as ignore ..."

but that forces the return of more data, so is slower, etc...

BTW the very fact that my testing of our partial port of this web
toolkit under V7 pre-beta has gotten this far is a very good sign.

Among other things, it makes heavy (if simple) use of referential
integrity, which has already uncovered two bugs in the port that
I've fixed.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Sun Feb 6 23:50:33 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA37731
for <pgsql-hackers@postgreSQL.org>; Sun, 6 Feb 2000 23:49:49 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id NAA18867
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 13:49:48 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id NAA08858
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 13:49:47 +0900
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_ctl man page
In-Reply-To: Your message of "Sun, 06 Feb 2000 12:49:58 +0900"
<20000206124958U.t-ishii@sra.co.jp>
References: <20000206124958U.t-ishii@sra.co.jp>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000207134947O.t-ishii@sra.co.jp>
Date: Mon, 07 Feb 2000 13:49:47 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 136

I got grammer corrections from Ed Loehr. Also, I modified some option
flag styles according to Thomas's suggestion. Thanks for those who
gave me suggestions.

Thomas, I have changed -m <opts> style to -smart, -fast... style. I
hope this was what you meant. Also, please note that I still stick
with smart/fast/immediate since I have been waiting for Vadim's
opinion...

Tatsuo Ishii
-------------------------------------------------------------------
NAME

pg_ctl - starts/stops/restarts postmaster

SYNOPSIS

pg_ctl [-w][-D database_dir][-p path_to_postmaster][-o "postmaster_opts"] start
pg_ctl [-w][-D database_dir][-smart|-fast|-immediate] stop
pg_ctl [-w][-D database_dir][-smart|-fast|-immediate][-o "postmaster_opts"] restart
pg_ctl [-D database_dir] status

DESCRIPTION

pg_ctl is a utility for starting, stopping or restarting postmaster.

Starting postmaster

To start postmaster:

pg_ctl start

If -w is supplied, pg_ctl waits for the database server comes up, by
watching for creation of the pid file (PGDATA/postmaster.pid), for up
to 60 seconds.

Parameters to invoke postmaster are taken from following sources:

Path to postmaster: found in the command search path
Database directory: PGDATA environment variable
Other parameters: PGDATA/postmaster.opts.default

postmaster.opts.default contains parameters for postmaster. With a
default installation, the "-S" option is enabled. So "pg_ctl start"
implies:

postmaster -S

Note that postmaster.opts.default is installed by initdb from
lib/postmaster.opts.default.sample under the PostgreSQL installation
directory (lib/postmaster.opts.default.sample is copied from
src/bin/pg_ctl/postmaster.opts.default.sample while installing
PostgreSQL).

To override default parameters you can use -D, -p and -o options.

-D database_dir
specifies the database directory

-p path_to_postmaster
specifies the path to postmaster

-o "postmaster_opts"
specifies any parameters for postmaster

Examples:

# blocks until postmaster comes up
pg_ctl -w start

# specifies postmaster path
pg_ctl -p /usr/local/pgsq/bin/postmaster start

# uses port 5433 and disables fsync
pg_ctl -o "-o -F -p 5433" start

Stopping postmaster

pg_ctl stop

stops postmaster.

There are several options for the stopping mode.

-w
waits for postmaster to shut down

-smart|-fast|-immediate
specifies the shutdown mode. smart mode waits for all
the clients to logout. This is the default.
fast mode sends SIGTERM to the backends, that means
active transactions get rolled back. immediate mode sends SIGUSR1
to the backends and lets them abort. In this case, database recovery
will be neccessary on the next startup.

Restarting postmaster

This is almost equivalent to stopping postmaster then starting it
again except that the parameters for postmaster used before stopping
it would be used too. This is done by saving them in
PGDATA/postmaster.opts file. -w, -D, -smart, -fast, -immediate and -o
can also be used in the restarting mode and they have same meanings as
described above.

Examples:

# restarts postmaster in the simplest form
pg_ctl restart

# restarts postmaster, waiting for it to shut down and to come up
pg_ctl -w restart

# uses port 5433 and disables fsync next time
pg_ctl -o "-o -F -p 5433" restart

Getting status from postmaster

To get status information from postmaster:

pg_ctl status

Following is sample outputs from pg_ctl.

pg_ctl: postmaster is running (pid: 13718)
options are:
/usr/local/src/pgsql/current/bin/postmaster
-p 5433
-D /usr/local/src/pgsql/current/data
-B 64
-b /usr/local/src/pgsql/current/bin/postgres
-N 32
-o '-F'

************

From bouncefilter Mon Feb 7 00:01:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA42981
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 00:01:27 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA13450;
Mon, 7 Feb 2000 00:00:59 -0500 (EST)
To: Chris <chris@bitmead.com>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Advice needed,
In-reply-to: <389D6F83.84CD0159@bitmead.com>
References: <389D6F83.84CD0159@bitmead.com>
Comments: In-reply-to Chris <chris@bitmead.com>
message dated "Sun, 06 Feb 2000 23:56:35 +1100"
Date: Mon, 07 Feb 2000 00:00:59 -0500
Message-ID: <13447.949899659@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris <chris@bitmead.com> writes:

I've been trying to implement UPDATE and DELETE to work on subclasses.

Good!

The change I made was basicly to add an "inh" parameter to
setTargetTable which I pass on down to addRangeTableEntry. From there I
expect it to be passed on to the executor and as I said it seems to work
ok without a where clause.

Hm. I do not believe that the executor is currently prepared to cope
with more than one target table for an UPDATE or DELETE. You'll
probably need to do some work in execMain.c and related files. Not
sure why it seemed to work at all...

regards, tom lane

From bouncefilter Mon Feb 7 00:25:32 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA46370
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 00:25:01 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA09153 for <pgsql-hackers@postgreSQL.org>;
Mon, 7 Feb 2000 16:24:28 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd.ePyt_;
Mon Feb 7 16:09:17 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA16351 for <pgsql-hackers@postgreSQL.org>;
Mon, 7 Feb 2000 16:09:16 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0pTbvt; Mon Feb 7 16:08:59 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA11124
for <pgsql-hackers@postgreSQL.org>;
Mon, 7 Feb 2000 16:08:58 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA04455
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 16:08:11 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389E530C.7FA60CCA@nimrod.itg.telecom.com.au>
Date: Mon, 07 Feb 2000 16:07:24 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: ONLY
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Been trying to read the SQL3 draft. My best guess is that this
is the appropriate section...

Let T be the table identified by
<ANSI> <table name>
<ISO > <table or query name>
contained in a <table specification> TS.

...

c) If ONLY is specified, then TS identifies a table fo the
rows
that do not have any corresponding row in any subtable of
T.

I assume this a round-about way of saying that "ONLY" is used to exclude
subtables?

BTW, I think in SQL3 the oid column is supposed to be called "IDENTITY".
Maybe, but who can read this thing? (Can we find the people who wrote
this document and have them taken out and flogged?).

From bouncefilter Mon Feb 7 00:26:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA47214
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 00:26:28 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA13477;
Mon, 7 Feb 2000 00:26:05 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
In-reply-to: <3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
References: <3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Sun, 06 Feb 2000 19:04:18 -0800"
Date: Mon, 07 Feb 2000 00:26:04 -0500
Message-ID: <13474.949901164@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Don Baccus <dhogaza@pacifier.com> writes:

The following used to work in 6.5, works in Oracle, and is
very useful:

donb=# select distinct c from foo order by upper(c);
ERROR: For SELECT DISTINCT, ORDER BY expressions must appear in target list

Well, it's not a bug --- it was an entirely deliberate change. It
might be a misfeature though. The case we were concerned about was

select distinct x from foo order by y;

which produces ill-defined results. If I recall the thread correctly,
Oracle and a number of other DBMSs reject this. I think your point is
that

select distinct x from foo order by f(x);

*is* well-defined, and useful. I think you are right, but how
far should we go in detecting common subexpressions? You might
want to contemplate the difference in these examples:

select distinct sin(x) from foo order by abs(sin(x));

select distinct random(x) from foo order by abs(random(x));

It would be interesting to poke at Oracle to find out just what they
consider a legitimate ORDER BY expression for a SELECT DISTINCT.

regards, tom lane

From bouncefilter Mon Feb 7 01:07:33 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA61189
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 01:07:08 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA09112; Mon, 7 Feb 2000 17:06:37 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdQ5u2U_;
Mon Feb 7 16:52:03 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA06595; Mon, 7 Feb 2000 16:52:02 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd3VJ7k_; Mon Feb 7 16:51:49 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA14804;
Mon, 7 Feb 2000 16:51:48 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA05957; Mon, 7 Feb 2000 16:51:05 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389E5D19.337D23DE@nimrod.itg.telecom.com.au>
Date: Mon, 07 Feb 2000 16:50:17 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Chris <chris@bitmead.com>, Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Advice needed,
References: <389D6F83.84CD0159@bitmead.com> <13447.949899659@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

The change I made was basicly to add an "inh" parameter to
setTargetTable which I pass on down to addRangeTableEntry. From there I
expect it to be passed on to the executor and as I said it seems to work
ok without a where clause.

Hm. I do not believe that the executor is currently prepared to cope
with more than one target table for an UPDATE or DELETE. You'll
probably need to do some work in execMain.c and related files. Not
sure why it seemed to work at all...

Been doing more tracing. The flow of code seems to be going the way one
might
expect.

Here is the strange thing. If I have
CREATE TABLE a (aa text);
CREATE TABLE b (bb text) inherits (a);

If I have a WHERE clause that updates at least one tuple in both a AND
b.

For example...
SELECT oid,* from ONLY a;
1234 | abcd
SELECT oid,* from ONLY b;
5678 | defg | NULL

Now if I have...
UPDATE a SET aa='zzzz' WHERE oid=1234 or oid=5678
it works ok. or...
UPDATE a SET aa='zzzz';
it works ok.
But if I have a WHERE clause that only touches "a" table or only touches
"b"
table, it just updates the wrong stuff, but appears to work. From then
on
it doesn't work at all.

Is there any function to print out a tuple?? I'm not sure how to do this
in the
debugger. Why can't pprint do it?

From bouncefilter Mon Feb 7 01:15:34 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA62250
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 01:15:25 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id WAA02262;
Sun, 6 Feb 2000 22:14:50 -0800 (PST)
Message-Id: <3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 06 Feb 2000 22:05:27 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <13474.949901164@sss.pgh.pa.us>
References: <3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:26 AM 2/7/00 -0500, Tom Lane wrote:

Well, it's not a bug --- it was an entirely deliberate change. It
might be a misfeature though.

Ahhh...getting subtle, are we? :)

The case we were concerned about was

select distinct x from foo order by y;

Yes...I remember some discussion regarding this.

which produces ill-defined results. If I recall the thread correctly,
Oracle and a number of other DBMSs reject this. I think your point is
that

select distinct x from foo order by f(x);

*is* well-defined, and useful. I think you are right, but how
far should we go in detecting common subexpressions?

Not sure...having not been into that part of the code (and busy at
the moment testing my rewrites of small portions of RI trigger
code I rewrote at Jan's request, after our "dispute" [which was more
or less "I'm 50% certain you're right!" "No! I'm 50% you're right!"
until I found the paragraph in Date's book which proved we were both
just about 50% right]) I can't really say.

I was hoping the standard might give some guidance?

You might
want to contemplate the difference in these examples:

select distinct sin(x) from foo order by abs(sin(x));

I'm not sure I see a problem here. My (brief) reading of the
standard tells me that "order by" follows everything else,
in other words, you get

select ... arbitrary complexity, with group by and all sorts of
cruft ...

then you take that result and apply the "order by" clause.

You'd get all the negative values followed by the positive
values, but you'd also get -1.0 and 1.0 if the database had
those values. Because they're distinct, and therefore live to
be ordered.

But I'm not sure about it...if you push me, I'll probably go dig
into the standard again (I was so successful with referential
"NO ACTION" last time, yeah, right, I sleep with Date's book under
my pillow at the moment!)

select distinct random(x) from foo order by abs(random(x));

Of course, real compiler systems (like I've spent my life working
on) have heuristic or, more modernly, other ways of deciding if a
function returns different values depending on when it is called.
In such systems, you only have to guarantee the correct answer, so
choosing wrong simply means the code runs slower.

"upper(column_value)" does not within a specific select. Column
value won't change. I can think of rules to think of but the
simplest might be that internal functions that are invariant when
their parameters are unchanged might be considered safe. Others,
not.

Also, the standard might simply say the result is implementation
dependent or (slightly worse) defined if the function returns
different values for a call with the same parameter list in a
single query. I don't know...it's an interesting question.

The other approach is to simply state that the function has one
and only one value during statement (SQL-statement, in this case)
execution, and yank the sucker out of there, execute it, and stuff
it in a temp variable. But that's probably too naive. Still, the
standard might say it is implementation defined as to whether or
not the function will be called once or more than once. The standard
only cares about embedded SQL but it might give guidance...

It would be interesting to poke at Oracle to find out just what they
consider a legitimate ORDER BY expression for a SELECT DISTINCT.

I have full-time access to an Oracle installation, so fire away
regarding examples and questions.

Not just on this narrow subject, but in general. I'm probably not the
ONLY person here with Oracle access, but I do have it, and my poking
at it won't hurt anything but Oracle's pride...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 01:19:33 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id BAA62818
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 01:18:43 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12HhKn-0003kMC; Mon, 7 Feb 100 07:07 MET
Message-Id: <m12HhKn-0003kMC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] ONLY
In-Reply-To: <389E530C.7FA60CCA@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 7, 2000 04:07:24 pm"
To: chris@bitmead.com
Date: Mon, 7 Feb 2000 07:07:41 +0100 (CET)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

BTW, I think in SQL3 the oid column is supposed to be called "IDENTITY".
Maybe, but who can read this thing? (Can we find the people who wrote
this document and have them taken out and flogged?).

Would that be enough? They'd sin on revenge, writing the next
specs. Cut off hands and rip out tounge (or something that
is really painful in in their terms - I'm unable to think
about anything), so they are never of danger for the human
community again.

In fact, it's easier for me to interpret a sendmail.cf file
than these specs. They'd been doing a better job by simply
writing a gram.y with some appropriate comments - more
readable and easier to adopt.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 7 01:15:33 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA62246
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 01:15:25 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id WAA02269;
Sun, 6 Feb 2000 22:14:51 -0800 (PST)
Message-Id: <3.0.1.32.20000206221124.01084170@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 06 Feb 2000 22:11:24 -0800
To: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] ONLY
In-Reply-To: <389E530C.7FA60CCA@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:07 PM 2/7/00 +1100, Chris Bitmead wrote:

BTW, I think in SQL3 the oid column is supposed to be called "IDENTITY".
Maybe, but who can read this thing? (Can we find the people who wrote
this document and have them taken out and flogged?).

It's not ALL that bad, my earlier comments were partly tongue in cheek.

Mostly, it is obvious that you have to digest the whole thing in order to
correctly understand bits and pieces. That was Jan's problem with
"NO ACTION" and RI, leading him to believe that this meant he should
leave dangling table references after deleting a referenced table. I
knew that was wrong, and figured it had to do with the general definition
of integrity constraints (i.e. there's a predicate function applied to
the enttire database that must be true at strictly-defined times, and if not,
errors spew forth and transactions roll backwards) but I'm damned if I
could find it. Thus our difficulty in deciding what PG should do for
such cases.

But I know it is there... :) And Jan was as relieved as me to learn
that it must be (because Date tells us so). Still, neither of us has
seen it, we're just trusting Date and common sense (occam's razor,
when in doubt, do the right thing).

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 01:13:34 2000
Received: from r149127-2815.dobiecenter.com ([209.217.149.127])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA61777
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 01:12:59 -0500 (EST)
(envelope-from taral@taral.net)
Received: from localhost (taral@localhost)
by r149127-2815.dobiecenter.com (8.9.3/8.9.3) with ESMTP id AAA27855;
Mon, 7 Feb 2000 00:12:47 -0600
X-Authentication-Warning: r149127-2815.dobiecenter.com: taral owned process
doing -bs
Date: Mon, 7 Feb 2000 00:12:47 -0600 (CST)
From: Taral <taral@taral.net>
X-Sender: taral@r149127-2815.dobiecenter.com
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
In-Reply-To: <13474.949901164@sss.pgh.pa.us>
Message-ID:
<Pine.LNX.4.10.10002070011270.27753-100000@r149127-2815.dobiecenter.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 7 Feb 2000, Tom Lane wrote:

Well, it's not a bug --- it was an entirely deliberate change. It
might be a misfeature though. The case we were concerned about was

select distinct x from foo order by y;

which produces ill-defined results.

Okay, I can understand this...

select distinct sin(x) from foo order by abs(sin(x));

select distinct random(x) from foo order by abs(random(x));

The thing here is that random() is not deterministic on its inputs,
whereas sin() is. Perhaps we should only allow fully deterministic ORDER
BY? (Ugh, another flag for functions...)

Taral

From bouncefilter Mon Feb 7 00:23:34 2000
Received: from picasso.realtyideas.com (IDENT:kaiq@207-18-128-210.flex.net
[207.18.128.210] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id AAA45950;
Mon, 7 Feb 2000 00:23:11 -0500 (EST)
(envelope-from kaiq@picasso.realtyideas.com)
Received: from localhost (kaiq@localhost)
by picasso.realtyideas.com (8.9.3/8.9.3) with ESMTP id AAA08026;
Mon, 7 Feb 2000 00:15:34 -0600
Date: Mon, 7 Feb 2000 00:15:34 -0600 (CST)
From: <kaiq@realtyideas.com>
To: Hannu Krosing <hannu@tm.ee>
cc: Chris <chris@bitmead.com>, Marten Feldtmann <marten@feki.toppoint.de>,
Peter Eisentraut <peter_e@gmx.net>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
Subject: Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL
In-Reply-To: <389C10F4.63DFB540@tm.ee>
Message-ID: <Pine.LNX.4.10.10002070004010.4446-100000@picasso.realtyideas.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

1) free is freedom, not free bear ;-) also, there are some sites
has oql draft -- like sql draft. sorry, can not remember.
2) good books, like " C++ object databases" (David Jordan) has
a lot material.
3) a lot of OODBM evaluation copy there. Not totally complied, but
together with 1 and 2, still can see what is going on.

so, no excuse for not knowing oodbm/oql :-) -- I'm waiting for
trying them on pg .

On Sat, 5 Feb 2000, Hannu Krosing wrote:

Chris wrote:

One very good point is the query language of the
rdbms systems. On the odbms side no standard is
really available, which can be seen as the sql of
the odbms.

There is a standard called OQL which is very similar to SQL. It's just
rather poorly supported.

I think the operative word here is "available". I know that SQL specs
are'nt freely available either, but due to SQL being already widely
supported one can get the general idea from many freely available sources,
like the bunch of freely downloadable DB's currently available for linux.
Most of them have some docs included.

It is still quite a job to reconstruct SQL92 from them ;)

I know now description (except a BNF syntax available from some ODBMS website)
that I could use to get some idea about OQL.

----------------------
Hannu

************

From bouncefilter Mon Feb 7 01:20:33 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA63033
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 01:20:01 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id WAA03401;
Sun, 6 Feb 2000 22:19:25 -0800 (PST)
Message-Id: <3.0.1.32.20000206221717.0107f4c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 06 Feb 2000 22:17:17 -0800
To: Taral <taral@taral.net>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.LNX.4.10.10002070011270.27753-100000@r149127-2815.dob
iecenter.com>
References: <13474.949901164@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:12 AM 2/7/00 -0600, Taral wrote:

The thing here is that random() is not deterministic on its inputs,
whereas sin() is. Perhaps we should only allow fully deterministic ORDER
BY? (Ugh, another flag for functions...)

Which, by it's nature is probably a misnomer, because I imagine that
PL/pgSQL functions would always have to be non deterministic whatever
their inputs? Given that unrecognized syntax is just tossed the
query executor. Thus calling any 'ole function without PL/pgSQL
really knowing what's going on?

So you probably end up with a LIST of functions by name that are built-in
and deterministic.

Or ... you simply say that results are really weird if the function has
undeterministic behavior and document it.

Tom's on the right path asking what the standard might say and what
delphic, incomprehensible answer the Oracle might have for us.

(the more I learn about the SQL standard, the more I appreciate the irony
of Oracle's corporate name!)

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 01:37:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA69335
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 01:37:04 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA13923;
Mon, 7 Feb 2000 01:36:44 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
In-reply-to: <3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
References: <3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Sun, 06 Feb 2000 22:05:27 -0800"
Date: Mon, 07 Feb 2000 01:36:43 -0500
Message-ID: <13920.949905403@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Don Baccus <dhogaza@pacifier.com> writes:

At 12:26 AM 2/7/00 -0500, Tom Lane wrote:

It would be interesting to poke at Oracle to find out just what they
consider a legitimate ORDER BY expression for a SELECT DISTINCT.

I have full-time access to an Oracle installation, so fire away
regarding examples and questions.

Well, try these on for size:

select distinct x from foo order by x+1;

select distinct x+1 from foo order by x+1;

select distinct x+1 from foo order by x;

select distinct x+1 from foo order by x+2;

select distinct x+y from foo order by x+y;

select distinct x,y from foo order by x+y;

select distinct x+y from foo order by x,y;

select distinct x+y from foo order by x-y;

A human can easily see that all but the last two are well-defined,
but I'll be a little surprised if Oracle knows it...

regards, tom lane

From bouncefilter Mon Feb 7 01:48:33 2000
Received: from relayer.zd.com (relayer.zd.com [155.40.130.200])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA70753
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 01:48:08 -0500 (EST)
(envelope-from Timothy_Dyck@zd.com)
Received: from mailer.zd.com ([155.40.32.223])
by relayer.zd.com (PMDF V5.2-32 #37280)
with SMTP id <0FPJ00K2OS6MX5@relayer.zd.com> for
pgsql-hackers@postgreSQL.org; Mon, 7 Feb 2000 01:47:11 -0500 (EST)
Received: by mailer.zd.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998))
id 8525687E.002555ED ; Mon, 07 Feb 2000 01:47:48 -0500
Date: Mon, 07 Feb 2000 01:41:26 -0500
From: Timothy Dyck <Timothy_Dyck@zd.com>
Subject: follow-up on PC Week Labs benchmark results
To: pgsql-hackers@postgreSQL.org
Message-id: <8525687E.002554B3.00@mailer.zd.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
X-Lotus-FromDomain: ZIFF-DAVIS@INET

Hi all, here are my responses to various questions:

First, there was one more syntax request I forgot to include before:

create view doesn't allow column aliases in the view definition: e.g.
create view myview (a,b,c) as select x,y,z ... doesn't work, but create
view myview select x as a, y as b, z as c ... works.

from Tom Lane:

Thanks for the report! I don't suppose you'd be interested in rerunning

your tests on current (pre-beta-7.0) sources?

(and other questions on what version to test)

We get a lot of that anytime we run tests. A simple answer is that PC Week
never benchmarks non-production, non-released code. The next question is
why not wait until version x when we are that much better? We have to put
the stake in the ground sometime, and this story was driven by the news of
InterBase going open source. We cover the news week by week, and all
stories have to have a current news hook of some kind. That being said,
when there is a significant change in the competitive landscape, I'd like
to run the tests again (esp. now that I have gotten all the scripts done).
In particular, I'd like to compare IB 6 with PG 7.x and MySQL later this
year (I didn't benchmark MySQL this time because I ran out of time, but
would very much like to.)

65536 buffer limit?

I was using a 4KB page size, so this was 256MB of cache. In this case, I
was using a database that was about 86 MB of data and indices, so I didn't
need this much cache. However, I could easily see a production database
server for a mid-size company equipped with 1 or 2 GB of RAM and I would
assign 80% of that RAM to the db cache. In future tests, I will be testing
with a 4 GB database and so will need to be using as big a cache as
PostgreSQL can support.

outer joins

As Don Baccus points out, simulating outer joins with a union and a not
exists gets hairy when you have more than two tables involved.
Interestingly, Sybase only supported outer joins as of two months ago
(12.0), though the others have supported them for some time.

(from Ed Loehr)

I was disappointed this benchmark did not include database recovery

and reliability measurements. Benchmarks ought to include the most
important characteristics of an RDBMS, and recovery/reliability is
certainly one of them

I quite agree, though, of course, there always a balancing of time to run
the tests vs. value of results gained. The benchmark I chose for PC Week's
use (AS3AP by Turbyfill, Orji and Bitton) is actually much more rounded
than most benchmarks (Wisconsin, TPC-A/B/C, etc.) because it includes a)
load time, b) index time, c) update stats time, d) DSS queries such as
aggregates and counts, e) is both single user and multiuser, and f) uses a
wide variety of data types, not just int and char.

In addition, I have a) extended the query set quite a bit to cover much
more of the SQL92 entry/intermediate level spec, and b) added query log
tables and consistency check queries to do some testing of proper ACID
properties.

Now on the specific issue of recovery, I decided a few years ago not to
measure that metric solely because the TPC-C test does such a good job of
checking for ACIDity. In fact, continual TPC-C testing is a big reason why
today's databases are so reliable. The problem here is that no open source
database has ever been tested by the TPC because none of the development
groups are TPC members. I'd certainly suggest that Red Hat or VA Linux do
this to get some database numbers on the board. It's a key credibility
test because just passing is a very good assurance of really debugged
transaction logging code.

From bouncefilter Mon Feb 7 01:50:33 2000
Received: from feivel.fam-meskes.de (h-62.96.160.210.host.de.colt.net
[62.96.160.210]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA70978
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 01:49:46 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id BD8B42BB9D; Mon, 7 Feb 2000 07:48:53 +0100 (CET)
Date: Mon, 7 Feb 2000 07:48:53 +0100
From: Michael Meskes <meskes@postgresql.org>
To: Emmanuel Charpentier <charpent@bacbuc.dyndns.org>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Case sensitivity issues
Message-ID: <20000207074853.A1134@fam-meskes.de>
Mail-Followup-To: Emmanuel Charpentier <charpent@bacbuc.dyndns.org>,
pgsql-hackers@postgresql.org
References: <20000206.22513400@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.0.1i
In-Reply-To: <20000206.22513400@localhost.localdomain>;
from charpent@bacbuc.dyndns.org on Sun, Feb 06, 2000 at
10:51:34PM +0000
Sender: michael@fam-meskes.de

On Sun, Feb 06, 2000 at 10:51:34PM +0000, Emmanuel Charpentier wrote:

I have lived that SQL database were not to be case-sensitive. However,

Which one? I have yet to work with one, that is unless you count Access as a
real database which it is not.

This interface mostly works, but has some odd behaviour :
/* Querying ��� usarrests ��� does ! Note that column names have been
lowercased as well ... */

Sure. SQL is case insesitive by default. Quote your case-sensitive string
with double-quotes and it works.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Mon Feb 7 04:57:35 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA22443
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 04:54:41 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <1JJL7P6K>; Mon, 7 Feb 2000 11:50:36 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C4F6@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'chris@bitmead.com'" <chris@bitmead.com>, pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] ONLY
Date: Mon, 7 Feb 2000 09:42:13 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Been trying to read the SQL3 draft. My best guess is that this
is the appropriate section...

Let T be the table identified by
<ANSI> <table name>
<ISO > <table or query name>
contained in a <table specification> TS.

...

c) If ONLY is specified, then TS identifies a table fo the
rows
that do not have any corresponding row in any
subtable of
T.

I assume this a round-about way of saying that "ONLY" is
used to exclude
subtables?

That's not what it sounds like to me. To me, this sounds like it will only
include those rows that do not have associated rows in sub-tables. That's
not the same as selecting rows without the associated sub-table rows. Kind
of a select * from TS where not exists (any rows in sub-tables of TS)

Looking at it again, it does sound very ambiguous, but I would still lean
(semantically, not using common sense) to what I wrote above. Of course,
common sense would dictate otherwise.

MikeA

From bouncefilter Mon Feb 7 03:32:36 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA06050
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 03:32:11 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id TAA11134;
Mon, 7 Feb 2000 19:31:14 +1100
Sender: chris@tech.com.au
Message-ID: <389E82D2.65784CF@bitmead.com>
Date: Mon, 07 Feb 2000 19:31:14 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
References: <3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<13474.949901164@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

select distinct x from foo order by y;

which produces ill-defined results.

Why is this ill-defined? If y is in x then it is also distinct and
there's no logic problem sorting on it.

From bouncefilter Mon Feb 7 03:43:35 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA07424
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 03:42:41 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id TAA11250
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:42:38 +1100
Sender: chris@tech.com.au
Message-ID: <389E857E.E96862AB@bitmead.com>
Date: Mon, 07 Feb 2000 19:42:38 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ONLY
References: <3.0.1.32.20000206221124.01084170@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

It's not ALL that bad, my earlier comments were
partly tongue in cheek.

<grumble> I think they're pretty bad. I did start reading from the
beginning, even reading the definitions and there are many things that
are not clear to me.

If you think it's not too bad, do you care to comment on the "ONLY"
situation?

From bouncefilter Mon Feb 7 07:13:09 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id HAA21957
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 07:12:36 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 29440 invoked by uid 1001); 7 Feb 2000 12:12:37 -0000
Date: Mon, 7 Feb 2000 07:12:37 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: pgsql-hackers@postgreSQL.org
Subject: New Globe
Message-ID: <Pine.BSF.4.05.10002070709530.29227-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I have the new developer's globe online. Please check your BIOs and
let me know if there's anything that needs correcting. For those
without pictures, don't be so shy. Submit a picture - if you need to
have one scanned it can be arranged.

And before I forget.. Good job on the globe, Jan!

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Mon Feb 7 07:25:09 2000
Received: from oxmail.ox.ac.uk (oxmail3.ox.ac.uk [129.67.1.180])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA23431
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 07:24:50 -0500 (EST)
(envelope-from mbeattie@sable.ox.ac.uk)
Received: from sable.ox.ac.uk ([163.1.2.4])
by oxmail.ox.ac.uk with esmtp (Exim 2.10 #1) id 12HnDk-0007ay-00
for pgsql-hackers@postgresql.org; Mon, 7 Feb 2000 12:24:48 +0000
Received: from mbeattie by sable.ox.ac.uk with local (Exim 3.13 #1)
id 12HnDk-0007r2-00
for pgsql-hackers@postgresql.org; Mon, 07 Feb 2000 12:24:48 +0000
Subject: Re: [HACKERS] Need confirmation of "Posix time standard" on FreeBSD
In-Reply-To: <389DF4B7.53AEA648@alumni.caltech.edu> from Thomas Lockhart at
"Feb 6, 2000 10:24:55 pm"
To: pgsql-hackers@postgresql.org
Date: Mon, 7 Feb 2000 12:24:48 +0000 (GMT)
From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <E12HnDk-0007r2-00@sable.ox.ac.uk>

Thomas Lockhart writes:

Someone mentioned recently that a timezone style of "GMT+0800" was on
their FreeBSD machine as an allowed time zone, that its behavior was
the same as the usual ISO8601 timezone of "-0800", and that this
conformed to some sort of Posix standard.

I had posted patches for this, and have just modified the patch to be
cleaner and more robust.

Before committing this (or at least before completing our upcoming
beta period), I'd like confirmation that this actually matches
expected behavior for a machine implementing a "GMT+0800" (or similar)
time zone, and that it is indeed a Posix standard? Anyone??

I can confirm that it is a POSIX standard. Section 8.1.1 "Extensions
to Time Functions" of POSIX 1003.1-1988 says TZ can be of the form
:characters
for implementation-defined behaviour or else
std offset [dst [offset][,start[/time],end[/time]]]
(spaces for readability only) where std is three or more bytes
designating the standard time zone (any characters except a leading
colon, digits, comma, minus, plus or NUL allowed) and offset is the
value one must add to the local time to arrive at Coordinated
Universal Time. offset is of the form hh[:mm[:ss]] with hh required
and may be a single digit. Followed by gory details about the rest of
the fields. Phew.

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

From bouncefilter Mon Feb 7 07:25:09 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA23441
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 07:25:00 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id VAA18394;
Mon, 7 Feb 2000 21:24:58 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-4 [133.137.84.4])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id VAA15061;
Mon, 7 Feb 2000 21:24:56 +0900
To: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-Reply-To: <24481.949852063@sss.pgh.pa.us>
References: <200002060655.BAA09293@candle.pha.pa.us>
<20000206230412X.t-ishii@sra.co.jp> <24481.949852063@sss.pgh.pa.us>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000207212856U.t-ishii@sra.co.jp>
Date: Mon, 07 Feb 2000 21:28:56 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 62

1. It doesn't guarantee that the right files are fsync'd. It would
in fact fsync whichever files happen to be using the same kernel
file descriptor numbers at the close of the transaction as the ones
you really wanted to fsync were using at the time fsync was requested.

Right. If a VFD is reused, the fd would not point to the same file
anymore.

You could possibly fix #1 by logging fsync requests at the vfd level;
then, whenever a vfd is closed to free up a kernel fd, check the fsync
flag and execute the pending fsync before closing the file. You could
possibly fix #2 by having transaction commit invoke the pg_fsync_pending
scan before it updates pg_log (and then fsyncing pg_log itself again
after).

I do not understand #2. I call pg_fsync_pending twice in
RecordTransactionCommit, one is after FlushBufferPool, and the other
is after TansactionIdCommit and FlushBufferPool. Or am I missing
something?

What would still need to be thought about is whether this scheme
preserves the ordering guarantee when a group of concurrent backends
is considered, rather than one backend in isolation. (I believe that
fsync() will apply to all dirty kernel buffers for a file, not just
those dirtied by the requesting process, so each backend's fsyncs can
affect the order in which other backends' writes hit the disk.)
Offhand I do not see any problems there, but it's the kind of thing
that requires more than offhand thought...

I thought about that too. If the ordering was that important, a
database managed by backends with -F on could be seriously
corrupted. I've never heard of such disasters caused by -F. So my
conclusion was that it's safe or I had been so lucky. Note that I'm
not talking about pg_log vs. relations but the ordering among
relations.

BTW, Hiroshi has noticed me an excellent point #3:

Session-1
begin;
update A ...;

Session-2
begin;
select * fromB ..;
There's no PostgreSQL shared buffer available.
This backend has to force the flush of a free buffer
page. Unfortunately the page was dirtied by the
above operation of Session-1 and calls pg_fsync()
for the table A. However fsync() is postponed until
commit of this backend.

Session-1
commit;
There's no dirty buffer page for the table A.
So pg_fsync() isn't called for the table A.

Seems there's no easy solution for this. Maybe now is the time to give
up my idea...
--
Tatsuo Ishii

From bouncefilter Mon Feb 7 07:31:09 2000
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net
[194.217.242.38]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA29383
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 07:30:59 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 12HnJc-000Pc2-0A; Mon, 7 Feb 2000 12:30:52 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id MAA01990;
Mon, 7 Feb 2000 12:30:52 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <129FQSMT>; Mon, 7 Feb 2000 12:29:57 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C179@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Vince Vielhaber'" <vev@michvhf.com>, pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] New Globe
Date: Mon, 7 Feb 2000 12:29:52 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

I've got to update my photo - as I shaved off the beard a few weeks ago
:-)

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: Monday, February 07, 2000 12:13 PM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] New Globe

I have the new developer's globe online. Please check your BIOs and
let me know if there's anything that needs correcting. For those
without pictures, don't be so shy. Submit a picture - if you need to
have one scanned it can be arranged.

And before I forget.. Good job on the globe, Jan!

Vince.
--
========================================================================
==
Vince Vielhaber -- KA8CSH email: vev@michvhf.com
http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
========================================================================
==

************

From bouncefilter Mon Feb 7 07:32:09 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id HAA31423
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 07:32:07 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 29481 invoked by uid 1001); 7 Feb 2000 12:32:09 -0000
Date: Mon, 7 Feb 2000 07:32:09 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Peter Mount <petermount@it.maidstone.gov.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] New Globe
In-Reply-To:
<1B3D5E532D18D311861A00600865478C70C179@exchange1.nt.maidstone.gov.uk>
Message-ID: <Pine.BSF.4.05.10002070731500.29227-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 7 Feb 2000, Peter Mount wrote:

I've got to update my photo - as I shaved off the beard a few weeks ago
:-)

Email it direct to me.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Mon Feb 7 09:19:10 2000
Received: from draal.apex.net.au (root@draal.apex.net.au [203.37.38.10])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA58720
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 09:18:44 -0500 (EST)
(envelope-from kleptog@cupid.suninternet.com)
Received: from kleptog (kleptog@ppp5-107.apex.net.au [210.9.66.107])
by draal.apex.net.au (8.9.3/8.9.3) with SMTP id BAA04870
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 01:18:26 +1100
Sender: kleptog@draal.apex.net.au
Message-ID: <389ED420.7F9E4870@cupid.suninternet.com>
Date: Tue, 08 Feb 2000 01:18:08 +1100
From: Martijn van Oosterhout <kleptog@cupid.suninternet.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.14 i586)
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Can you dereference an OID?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've checked the source, looked through various mailing
lists, etc. Considering that PostgreSQL is (at least partially)
an ORDBMS I would have thought it would be possible but I
can't see it.

Any ideas?

The other thing I wanted to ask is how to find which table/class
an oid is from but that has already been discussed on this list.
I agree with the classname idea is good.

Finally, is there a way around the scanner? I have a set of data
that needs to go into the database so I need to INSERT or UPDATE.
However, this data may contain quotes, backslashes, etc. Is there
a way of simply say "here is the literal data, no manipulation
required". Maybe as %length[literal data of given length].

Please CC any replies. It makes is easier to find them.

Martijn

From bouncefilter Mon Feb 7 09:25:10 2000
Received: from rage.hub.org (root@nat195.216.mpoweredpc.net [142.177.195.216])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA59636
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 09:24:13 -0500 (EST)
(envelope-from jeffm@pgsql.com)
Received: from localhost (jeffm@localhost)
by rage.hub.org (8.9.3/8.9.3) with ESMTP id KAA98387
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 10:24:26 -0400 (AST)
(envelope-from jeffm@pgsql.com)
X-Authentication-Warning: rage.hub.org: jeffm owned process doing -bs
Date: Mon, 7 Feb 2000 10:24:24 -0400 (AST)
From: "Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com>
X-Sender: jeffm@rage.hub.org
Reply-To: Jeff MacDonald <jeff@pgsql.com>
To: pgsql-hackers@postgresql.org
Subject: Longer Column Names
Message-ID: <Pine.BSF.4.10.10002071023250.10395-100000@rage.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Greets,

Will Postgres suffer any major performance hits from
recomiling with support for column names over 32 chars.
ie: 64 chars.

Jeff

======================================================
Jeff MacDonald
jeff@pgsql.com irc: bignose on EFnet
======================================================

From bouncefilter Mon Feb 7 09:46:11 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA66946
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 09:45:52 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA31827;
Mon, 7 Feb 2000 14:54:02 GMT
Sender: lockhart@hub.org
Message-ID: <389EDC8A.F1ED458D@alumni.caltech.edu>
Date: Mon, 07 Feb 2000 14:54:02 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Timothy Dyck <Timothy_Dyck@zd.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] follow-up on PC Week Labs benchmark results
References: <8525687E.002554B3.00@mailer.zd.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

create view doesn't allow column aliases in the view definition: e.g.
create view myview (a,b,c) as select x,y,z ... doesn't work, but create
view myview select x as a, y as b, z as c ... works.

Thanks for the heads up. We've never run into it before (and have not
had any requests for it), but will look at implementing it.

... PC Week never benchmarks non-production, non-released code...
... this story was driven by the news of
InterBase going open source.

Hmm. InterBase going open source seems to be a pre-alpha vaporware
feature so far ;)

In particular, I'd like to compare IB 6 with PG 7.x and MySQL later this
year (I didn't benchmark MySQL this time because I ran out of time, but
would very much like to.)

Great. We'll look forward to it. Also, it will be interesting to see
the relative performance and feature improvements over time; Postgres
has been living on "Internet time" for the last three or four years,
and I'll be suprised if other "Open Source" DBs can keep up.

In addition, I have a) extended the query set quite a bit to cover much
more of the SQL92 entry/intermediate level spec, and b) added query log
tables and consistency check queries to do some testing of proper ACID
properties.

You had inquired earlier about "when we would support complete SQL92"
(give or take a few words). What areas of entry level SQL92 are we
missing in your opinion (or should we wait for the article)?

btw, I've been amused and gratified by PC Week's obvious shift from
Open Source FUD generator to covering Open Source with a more even
hand. It's been months since the last time John Dodge referred to
"linux fanatics" with obvious scorn, and it is nice to see that y'all
are starting to get the point.

Regards.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Mon Feb 7 09:52:11 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA68014
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 09:51:48 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA31833;
Mon, 7 Feb 2000 14:59:45 GMT
Sender: lockhart@hub.org
Message-ID: <389EDDE1.2CEBC8E6@alumni.caltech.edu>
Date: Mon, 07 Feb 2000 14:59:45 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Need confirmation of "Posix time standard" on FreeBSD
References: <E12HnDk-0007r2-00@sable.ox.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I can confirm that it is a POSIX standard. Section 8.1.1 "Extensions
to Time Functions" of POSIX 1003.1-1988 says TZ can be of the form
:characters
for implementation-defined behaviour or else
std offset [dst [offset][,start[/time],end[/time]]]
(spaces for readability only) where std is three or more bytes
designating the standard time zone (any characters except a leading
colon, digits, comma, minus, plus or NUL allowed) and offset is the
value one must add to the local time to arrive at Coordinated
Universal Time. offset is of the form hh[:mm[:ss]] with hh required
and may be a single digit. Followed by gory details about the rest of
the fields. Phew.

Thanks for the info. How do they define "the standard time zone"? Is
it *any* time zone, or "GMT", or some other set of choices?

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Mon Feb 7 10:21:14 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA76435
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 10:20:54 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA10376;
Mon, 7 Feb 2000 07:19:15 -0800 (PST)
Message-Id: <3.0.1.32.20000207070355.010866f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 07:03:55 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <13920.949905403@sss.pgh.pa.us>
References: <3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:36 AM 2/7/00 -0500, Tom Lane wrote:

Don Baccus <dhogaza@pacifier.com> writes:

At 12:26 AM 2/7/00 -0500, Tom Lane wrote:

It would be interesting to poke at Oracle to find out just what they
consider a legitimate ORDER BY expression for a SELECT DISTINCT.

I have full-time access to an Oracle installation, so fire away
regarding examples and questions.

Well, try these on for size:

Here's what the Oracle proclaims:

select distinct x from foo order by x+1;
no rows selected

select distinct x+1 from foo order by x+1;
no rows selected

select distinct x+1 from foo order by x;
SQL> select distinct x+1 from foo order by x
*
ERROR at line 1:
ORA-01791: not a SELECTed expression

select distinct x+1 from foo order by x+2;
SQL> select distinct x+1 from foo order by x+2
*
ERROR at line 1:
ORA-01791: not a SELECTed expression

select distinct x+y from foo order by x+y;
SQL>
no rows selected

I also tried: select distinct x+y from foo order by y+x,
which fails.

select distinct x,y from foo order by x+y;
SQL>
no rows selected

select distinct x+y from foo order by x,y;
SQL> select distinct x+y from foo order by x,y
*
ERROR at line 1:
ORA-01791: not a SELECTed expression

select distinct x+y from foo order by x-y;
SQL> select distinct x+y from foo order by x-y
*
ERROR at line 1:
ORA-01791: not a SELECTed expression

My first thought is that it is following a simple rule:

For arithmetic "order by" expressions, either:

1. The exact expression must also appear in the "select" list,
and it must be exact, not just an expression that computes
the same value as the "order by" expression

or

2. all of the variables used by the expression must be listed
in the "select" list as simple column names, not as part of
an expression.

Must be true.

At least, the rule is simple if you can compare expression trees.

At this point I still am clueless regarding the standard, I think I'll
make Date my morning coffee date again.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 10:21:11 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA76365
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 10:20:20 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA10424;
Mon, 7 Feb 2000 07:19:28 -0800 (PST)
Message-Id: <3.0.1.32.20000207071035.0108a2c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 07:10:35 -0800
To: Chris <chris@bitmead.com>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] ONLY
In-Reply-To: <389E857E.E96862AB@bitmead.com>
References: <3.0.1.32.20000206221124.01084170@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 07:42 PM 2/7/00 +1100, Chris wrote:

Don Baccus wrote:

It's not ALL that bad, my earlier comments were
partly tongue in cheek.

<grumble> I think they're pretty bad. I did start reading from the
beginning, even reading the definitions and there are many things that
are not clear to me.

If you think it's not too bad, do you care to comment on the "ONLY"
situation?

Well, OK, I was trying to be nice. Let me put it in a way that insults
two standards committees at once:

It's no harder to read than the C++ standard.

How's that? :)

Date's primer takes potshots at it in almost every section. One way
in which the SQL standard IS worse than even your typically crummy
language standard is that it apparently is not internally consistent.
It contradicts itself in many areas, according to Date (who seems to
take real pleasure in pointing out specifics).

While all language standards have some bugs of this sort, the SQL standard
seems to be full of them.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 10:13:14 2000
Received: from oxmail.ox.ac.uk (oxmail4.ox.ac.uk [163.1.2.33])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA75224
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 10:12:19 -0500 (EST)
(envelope-from mbeattie@sable.ox.ac.uk)
Received: from sable.ox.ac.uk ([163.1.2.4])
by oxmail.ox.ac.uk with esmtp (Exim 2.10 #1)
id 12Hppg-0005j0-00; Mon, 7 Feb 2000 15:12:08 +0000
Received: from mbeattie by sable.ox.ac.uk with local (Exim 3.13 #1)
id 12Hppg-0004z6-00; Mon, 07 Feb 2000 15:12:08 +0000
Subject: Re: [HACKERS] Need confirmation of "Posix time standard" on FreeBSD
In-Reply-To: <389EDDE1.2CEBC8E6@alumni.caltech.edu> from Thomas Lockhart at
"Feb 7, 2000 02:59:45 pm"
To: lockhart@alumni.caltech.edu (Thomas Lockhart)
Date: Mon, 7 Feb 2000 15:12:08 +0000 (GMT)
From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Cc: pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <E12Hppg-0004z6-00@sable.ox.ac.uk>

Thomas Lockhart writes:

I can confirm that it is a POSIX standard. Section 8.1.1 "Extensions
to Time Functions" of POSIX 1003.1-1988 says TZ can be of the form
:characters
for implementation-defined behaviour or else
std offset [dst [offset][,start[/time],end[/time]]]
(spaces for readability only) where std is three or more bytes
designating the standard time zone (any characters except a leading
colon, digits, comma, minus, plus or NUL allowed) and offset is the
value one must add to the local time to arrive at Coordinated
Universal Time. offset is of the form hh[:mm[:ss]] with hh required
and may be a single digit. Followed by gory details about the rest of
the fields. Phew.

Thanks for the info. How do they define "the standard time zone"? Is
it *any* time zone, or "GMT", or some other set of choices?

It's "standard" in the sense of not-summer/not-daylight-savings rather
than in the "POSIX compliance" sense. In other words, std can be any
three bytes you like subject to the not-leading-colon, not-digits etc.
constraints above. Later in the section it says that summer time is
assumed to be one hour ahead of standard time if no offset follows
dst. Also,
If [an offset is] preceded by a "-"; the time zone shall be east of
the Prime Meridian; otherwise it shall be west (which may be
indicated by an optional preceding "+").
That's the bit which shows that the "+" is OK. Aha, but I've just
looked back at your original message and it refers to "GMT+0800"
whereas POSIX requires a ":" between the hours and minutes. So in
fact, "GMT+0800" is *not* legal and it should be "GMT+08:00" or
"GMT+08" or "GMT+8" (single digit hours are allowed).

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

From bouncefilter Mon Feb 7 10:21:11 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA76341
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 10:20:15 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA10460;
Mon, 7 Feb 2000 07:19:37 -0800 (PST)
Message-Id: <3.0.1.32.20000207071543.0108b150@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 07:15:43 -0800
To: Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] New Globe
In-Reply-To: <Pine.BSF.4.05.10002070709530.29227-100000@paprika.michvhf. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 07:12 AM 2/7/00 -0500, Vince Vielhaber wrote:

And before I forget.. Good job on the globe, Jan!

I love the stick-pins. And the photos are nice, too.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 10:33:11 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA81277
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 10:32:28 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA13336;
Mon, 7 Feb 2000 07:31:52 -0800 (PST)
Message-Id: <3.0.1.32.20000207072935.01086550@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 07:29:35 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Timothy Dyck <Timothy_Dyck@zd.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] follow-up on PC Week Labs benchmark results
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <389EDC8A.F1ED458D@alumni.caltech.edu>
References: <8525687E.002554B3.00@mailer.zd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:54 PM 2/7/00 +0000, Thomas Lockhart wrote:

... PC Week never benchmarks non-production, non-released code...
... this story was driven by the news of
InterBase going open source.

Hmm. InterBase going open source seems to be a pre-alpha vaporware
feature so far ;)

This is a good point as InterBase announced that their upcoming
Beta was going open source.

Did you test an early copy of their upcoming beta, or did you test
their current, non-Open Source product?

If you tested their upcoming beta, then it would seem fair to test
our upcoming beta, too :) If you tested their non-Open Source
current production version, then you're not testing two Open Source
databases...hmmm...

Of course, InterBase may've expanded on their earlier announcement
of what's going Open Source, I've not been tracking it.

In particular, I'd like to compare IB 6 with PG 7.x and MySQL later this
year (I didn't benchmark MySQL this time because I ran out of time, but
would very much like to.)

Actually, this slipped by me the first time.

Why benchmark MySQL? It's not a real RDBMS, it doesn't even pretend
to support ACID semantics. Clearly it is going to be faster than
databases that do because supporting ACID semantics is expensive.

This would be comparing apples with oranges, meaningless.

Now, don't get me wrong, for many application spaces mySQL is fine. If
you're running a bboard system for overclockers, for instance, you probably
would sigh in relief if disaster struck and you lost all your data.

On the other hand, if you're running an e-commerce site losing data is
not cool and mySQL is not appropriate.

Rather than benchmark, it would seem more useful to educate your readers
about the meaning of ACID, and how to decide when you need it and when you
don't. That would seem far more important, because in my experience many
people don't understand that there is a real difference between a program
that executes a subset of SQL in a simple manner, and an RDBMS that
passes the ACID test and happens to be driven by SQL queries.

If you were to benchmark in the context of such an article, it would make
some sense, because you could do so in order to answer the question, "How
much does ACID hurt performance?"

This would give your readers real information to help drive their choice
of software.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 10:59:12 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id KAA88756
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 10:58:15 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12HqNb-0003kMC; Mon, 7 Feb 100 16:47 MET
Message-Id: <m12HqNb-0003kMC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] New Globe
In-Reply-To: <Pine.BSF.4.05.10002070709530.29227-100000@paprika.michvhf.com>
from Vince Vielhaber at "Feb 7, 2000 07:12:37 am"
To: Vince Vielhaber <vev@michvhf.com>
Date: Mon, 7 Feb 2000 16:47:11 +0100 (CET)
CC: pgsql-hackers@postgreSQL.org
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have the new developer's globe online. Please check your BIOs and
let me know if there's anything that needs correcting. For those
without pictures, don't be so shy. Submit a picture - if you need to
have one scanned it can be arranged.

As core members, Tom Lane and me should move up into the
steering area, I think.

And before I forget.. Good job on the globe, Jan!

Did you succeed in rendering it?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 7 10:57:21 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA87764
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 10:57:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA19719;
Mon, 7 Feb 2000 10:56:43 -0500 (EST)
To: Chris <chris@bitmead.com>
cc: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
In-reply-to: <389E82D2.65784CF@bitmead.com>
References: <3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<13474.949901164@sss.pgh.pa.us> <389E82D2.65784CF@bitmead.com>
Comments: In-reply-to Chris <chris@bitmead.com>
message dated "Mon, 07 Feb 2000 19:31:14 +1100"
Date: Mon, 07 Feb 2000 10:56:43 -0500
Message-ID: <19716.949939003@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris <chris@bitmead.com> writes:

select distinct x from foo order by y;

which produces ill-defined results.

Why is this ill-defined? If y is in x then it is also distinct

Huh? The query specifies distinct values of x, and only x.
Consider
x y

1 1
1 10
2 0
2 11

"select distinct x" ought to produce one row with x=1, and one row with
x=2, and nothing else. If it implicitly did the distinct on y as well,
you'd get four rows with two x=1 and two x=2, which is not my idea of
"distinct x". But if you don't have four rows out, then there's no
meaningful way to order by y.

6.5.3 in fact produces four rows from this query, which is generally
conceded to be broken behavior.

regards, tom lane

From bouncefilter Mon Feb 7 11:04:23 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA92634
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 11:03:27 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA19772;
Mon, 7 Feb 2000 11:03:23 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
In-reply-to: <3.0.1.32.20000207070355.010866f0@mail.pacifier.com>
References: <3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
<3.0.1.32.20000207070355.010866f0@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Mon, 07 Feb 2000 07:03:55 -0800"
Date: Mon, 07 Feb 2000 11:03:23 -0500
Message-ID: <19769.949939403@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Don Baccus <dhogaza@pacifier.com> writes:

My first thought is that it is following a simple rule:

For arithmetic "order by" expressions, either:

1. The exact expression must also appear in the "select" list,
and it must be exact, not just an expression that computes
the same value as the "order by" expression

or

2. all of the variables used by the expression must be listed
in the "select" list as simple column names, not as part of
an expression.

Could be. How about cases like

select distinct x,y+1 from foo order by x+y+1;

At least, the rule is simple if you can compare expression trees.

I think we have something pretty similar for GROUP BY, actually,
so it may not be hard to make this work.

regards, tom lane

From bouncefilter Mon Feb 7 11:07:25 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA94001
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 11:06:27 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA19802;
Mon, 7 Feb 2000 11:06:23 -0500 (EST)
To: Jeff MacDonald <jeff@pgsql.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Longer Column Names
In-reply-to: <Pine.BSF.4.10.10002071023250.10395-100000@rage.hub.org>
References: <Pine.BSF.4.10.10002071023250.10395-100000@rage.hub.org>
Comments: In-reply-to "Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com>
message dated "Mon, 07 Feb 2000 10:24:24 -0400"
Date: Mon, 07 Feb 2000 11:06:23 -0500
Message-ID: <19799.949939583@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com> writes:

Will Postgres suffer any major performance hits from
recomiling with support for column names over 32 chars.
ie: 64 chars.

I doubt it'd make a large difference, except that your system
tables would get bigger. Try it and let us know what you see...

regards, tom lane

From bouncefilter Mon Feb 7 11:08:31 2000
Received: from ns1.aktrad.ru (ns1.aktrad.ru [195.218.140.4])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA94218
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 11:07:47 -0500 (EST)
(envelope-from hook@aktrad.ru)
Received: from sloth (sloth.aktrad.ru [195.218.140.13])
by ns1.aktrad.ru (8.9.3/8.9.3) with SMTP id TAA45607
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 19:07:05 +0300 (MSK)
Message-ID: <168201bf7185$65338ed0$0d8cdac3@aktrad.ru>
From: "Gene Sokolov" <hook@aktrad.ru>
To: <pgsql-hackers@postgresql.org>
References: <E12HnDk-0007r2-00@sable.ox.ac.uk>
Subject: Re: [HACKERS] Need confirmation of "Posix time standard" on FreeBSD
Date: Mon, 7 Feb 2000 19:07:12 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

From: "Malcolm Beattie" <mbeattie@sable.ox.ac.uk>

Thomas Lockhart writes:

Before committing this (or at least before completing our upcoming
beta period), I'd like confirmation that this actually matches
expected behavior for a machine implementing a "GMT+0800" (or similar)
time zone, and that it is indeed a Posix standard? Anyone??

I can confirm that it is a POSIX standard. Section 8.1.1 "Extensions
to Time Functions" of POSIX 1003.1-1988 says TZ can be of the form
:characters
for implementation-defined behaviour or else
std offset [dst [offset][,start[/time],end[/time]]]

It probably won't affect anything, but some implementations (FreeBSD most
notably) have a bug in parsing TZ light savings string. The M notation gives
one day off for switching to/from light savings. Actually, it incorrectly
assumes Sunday as 0 for Zeller Congruence when it's Saturday.

Gene Sokolov.

From bouncefilter Mon Feb 7 11:13:12 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA95310
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 11:12:39 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA01166;
Mon, 7 Feb 2000 11:11:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002071611.LAA01166@candle.pha.pa.us>
Subject: Re: [HACKERS] New Globe
In-Reply-To: <m12HqNb-0003kMC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Feb 7, 2000 04:47:11 pm"
To: Jan Wieck <wieck@debis.com>
Date: Mon, 7 Feb 2000 11:11:28 -0500 (EST)
CC: Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have the new developer's globe online. Please check your BIOs and
let me know if there's anything that needs correcting. For those
without pictures, don't be so shy. Submit a picture - if you need to
have one scanned it can be arranged.

As core members, Tom Lane and me should move up into the
steering area, I think.

Doing it right now.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 11:16:16 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id LAA96023
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 11:15:20 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 201 invoked by uid 1001); 7 Feb 2000 16:15:22 -0000
Date: Mon, 7 Feb 2000 11:15:22 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Jan Wieck <wieck@debis.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
In-Reply-To: <m12HqNb-0003kMC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.BSF.4.05.10002071114070.29828-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 7 Feb 2000, Jan Wieck wrote:

I have the new developer's globe online. Please check your BIOs and
let me know if there's anything that needs correcting. For those
without pictures, don't be so shy. Submit a picture - if you need to
have one scanned it can be arranged.

As core members, Tom Lane and me should move up into the
steering area, I think.

I leave those decisions to Marc. :)

And before I forget.. Good job on the globe, Jan!

Did you succeed in rendering it?

Yep. Did it on hub. Took (I think) 6 and a half hours.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Mon Feb 7 11:27:12 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA99098
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 11:27:00 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA29143;
Mon, 7 Feb 2000 08:26:23 -0800 (PST)
Message-Id: <3.0.1.32.20000207082146.0108a3b0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 08:21:46 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <19769.949939403@sss.pgh.pa.us>
References: <3.0.1.32.20000207070355.010866f0@mail.pacifier.com>
<3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
<3.0.1.32.20000207070355.010866f0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:03 AM 2/7/00 -0500, Tom Lane wrote:

Could be. How about cases like

select distinct x,y+1 from foo order by x+y+1;

SQL> select distinct x,y+1 from foo order by x+y+1
*
ERROR at line 1:
ORA-01791: not a SELECTed expression

At least, the rule is simple if you can compare expression trees.

I think we have something pretty similar for GROUP BY, actually,
so it may not be hard to make this work.

Actually, yes, you're probably right...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 11:36:12 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA04901
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 11:35:26 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA02832;
Mon, 7 Feb 2000 11:31:44 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002071631.LAA02832@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <20000207212856U.t-ishii@sra.co.jp> from Tatsuo Ishii at "Feb 7,
2000 09:28:56 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Mon, 7 Feb 2000 11:31:44 -0500 (EST)
CC: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

BTW, Hiroshi has noticed me an excellent point #3:

Session-1
begin;
update A ...;

Session-2
begin;
select * fromB ..;
There's no PostgreSQL shared buffer available.
This backend has to force the flush of a free buffer
page. Unfortunately the page was dirtied by the
above operation of Session-1 and calls pg_fsync()
for the table A. However fsync() is postponed until
commit of this backend.

Session-1
commit;
There's no dirty buffer page for the table A.
So pg_fsync() isn't called for the table A.

Seems there's no easy solution for this. Maybe now is the time to give
up my idea...

I hate to see you give up on this.

Don't tell me we fsync on every buffer write, and not just at
transaction commit? That is terrible.

What if we set a flag on the file descriptor stating we dirtied/wrote
one of its buffers during the transaction, and cycle through the file
descriptors on buffer commit and fsync all involved in the transaction.
We also fsync if we close a file descriptor and it was involved in the
transaction. We clear the "involved in this transaction" flag on commit
too.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 11:35:12 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA04784
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 11:34:53 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA02867;
Mon, 7 Feb 2000 11:32:30 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002071632.LAA02867@candle.pha.pa.us>
Subject: Re: [HACKERS] New Globe
In-Reply-To: <Pine.BSF.4.05.10002071114070.29828-100000@paprika.michvhf.com>
from Vince Vielhaber at "Feb 7, 2000 11:15:22 am"
To: Vince Vielhaber <vev@michvhf.com>
Date: Mon, 7 Feb 2000 11:32:30 -0500 (EST)
CC: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 7 Feb 2000, Jan Wieck wrote:

I have the new developer's globe online. Please check your BIOs and
let me know if there's anything that needs correcting. For those
without pictures, don't be so shy. Submit a picture - if you need to
have one scanned it can be arranged.

As core members, Tom Lane and me should move up into the
steering area, I think.

I leave those decisions to Marc. :)

And before I forget.. Good job on the globe, Jan!

Did you succeed in rendering it?

Yep. Did it on hub. Took (I think) 6 and a half hours.

That's it. No new developers. The globe takes too long to generate. :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 11:40:12 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA05769
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 11:39:48 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id LAA03244
for pgsql-hackers@postgreSQL.org; Mon, 7 Feb 2000 11:39:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002071639.LAA03244@candle.pha.pa.us>
Subject: Inprise/Corel merger
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 7 Feb 2000 11:39:21 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have just been told that Corel and Inprise are merging. That makes
Interbase a more formidable foe.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 11:41:12 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA05941
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 11:40:25 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA20021;
Mon, 7 Feb 2000 11:40:18 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-reply-to: <20000207212856U.t-ishii@sra.co.jp>
References: <200002060655.BAA09293@candle.pha.pa.us>
<20000206230412X.t-ishii@sra.co.jp> <24481.949852063@sss.pgh.pa.us>
<20000207212856U.t-ishii@sra.co.jp>
Comments: In-reply-to Tatsuo Ishii <t-ishii@sra.co.jp>
message dated "Mon, 07 Feb 2000 21:28:56 +0900"
Date: Mon, 07 Feb 2000 11:40:17 -0500
Message-ID: <20018.949941617@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

possibly fix #2 by having transaction commit invoke the pg_fsync_pending
scan before it updates pg_log (and then fsyncing pg_log itself again
after).

I do not understand #2. I call pg_fsync_pending twice in
RecordTransactionCommit, one is after FlushBufferPool, and the other
is after TansactionIdCommit and FlushBufferPool. Or am I missing
something?

Oh, OK. That's what I meant. The snippet you posted didn't show where
you were calling the fsync routine from.

I thought about that too. If the ordering was that important, a
database managed by backends with -F on could be seriously
corrupted. I've never heard of such disasters caused by -F.

This is why I think that fsync actually offers very little extra
protection ;-)

BTW, Hiroshi has noticed me an excellent point #3:

This backend has to force the flush of a free buffer
page. Unfortunately the page was dirtied by the
above operation of Session-1 and calls pg_fsync()
for the table A. However fsync() is postponed until
commit of this backend.

Session-1
commit;
There's no dirty buffer page for the table A.
So pg_fsync() isn't called for the table A.

Oooh, right. Backend A dirties the page, but leaves it sitting in
shared buffer. Backend B needs the buffer space, so it does the
fwrite of the page. Now if backend A wants to commit, it can fsync
everything it's written --- but does that guarantee the page that
was actually written by B will get flushed to disk? Not sure.

If the pending-fsync logic is based on either physical fds or vfds
then it definitely *won't* work; A might have found the desired page
sitting in buffer cache to begin with, and never have opened the
underlying file at all!

So it seems you would need to keep a list of all the relation files (and
segments) you've written to in the current xact, and open and fsync each
one just before writing/fsyncing pg_log. Even then, you're assuming
that fsync applied to a file via an fd belonging to one backend will
flush disk buffers written to the same file via *other* fds belonging
to *other* processes. I'm not sure that that is true on all Unixes...
heck, I'm not sure it's true on any. The fsync(2) man page here isn't
real specific.

regards, tom lane

From bouncefilter Mon Feb 7 11:49:12 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA07721
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 11:48:11 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA20059;
Mon, 7 Feb 2000 11:47:46 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-reply-to: <200002071631.LAA02832@candle.pha.pa.us>
References: <200002071631.LAA02832@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 07 Feb 2000 11:31:44 -0500"
Date: Mon, 07 Feb 2000 11:47:45 -0500
Message-ID: <20056.949942065@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Don't tell me we fsync on every buffer write, and not just at
transaction commit? That is terrible.

If you don't have -F set, yup. Why did you think fsync mode was
so slow?

What if we set a flag on the file descriptor stating we dirtied/wrote
one of its buffers during the transaction, and cycle through the file
descriptors on buffer commit and fsync all involved in the transaction.

That's exactly what Tatsuo was describing, I believe. I think Hiroshi
has pointed out a serious problem that would make it unreliable when
multiple backends are running: if some *other* backend fwrites the page
instead of your backend, and it doesn't fsync until *its* transaction is
done (possibly long after yours), then you lose the ordering guarantee
that is the point of the whole exercise...

regards, tom lane

From bouncefilter Mon Feb 7 11:59:12 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA10377
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 11:58:42 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA10483;
Mon, 7 Feb 2000 08:56:55 -0800 (PST)
Message-Id: <3.0.1.32.20000207085422.01092ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 08:54:22 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>, Tatsuo Ishii <t-ishii@sra.co.jp>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] TODO item
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
In-Reply-To: <200002071631.LAA02832@candle.pha.pa.us>
References: <20000207212856U.t-ishii@sra.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:31 AM 2/7/00 -0500, Bruce Momjian wrote:

I hate to see you give up on this.

Don't tell me we fsync on every buffer write, and not just at
transaction commit? That is terrible.

Won't we have many more options in this area, i.e. increasing performance
while maintaining on-disk data integrity, once WAL is implemented?

snapshot+WAL = your database so in theory -F on tables and
the transaction log would be safe as long as you have a snapshot and
as long as the WAL is being fsync'd and you have the disk space to
hold the WAL until you update your snapshot, no?

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 11:59:12 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA10329
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 11:58:29 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id LAA00857;
Mon, 7 Feb 2000 11:58:20 -0500
Message-ID: <389EF9A9.FEE547D5@wgcr.org>
Date: Mon, 07 Feb 2000 11:58:17 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] New Globe
References: <m12HqNb-0003kMC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Wieck wrote:

As core members, Tom Lane and me should move up into the
steering area, I think.

I was wondering when you two would be promoted. Congratulations.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Mon Feb 7 22:03:19 2000
Received: from bender.toppoint.de (bender.toppoint.de [195.244.243.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA91619;
Mon, 7 Feb 2000 22:02:25 -0500 (EST)
(envelope-from marten@feki.toppoint.de)
Received: (from uucp@localhost)
by bender.toppoint.de (8.9.3/8.9.3) id EAA12805;
Tue, 8 Feb 2000 04:01:38 +0100 (MET)

Received: (from marten@localhost)

by feki.toppoint.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id SAA03075;
Mon, 7 Feb 2000 18:06:18 +0100
From: Marten Feldtmann <marten@feki.toppoint.de>
Message-Id: <200002071706.SAA03075@feki.toppoint.de>
Subject: Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL
In-Reply-To:
<Pine.LNX.4.10.10002070004010.4446-100000@picasso.realtyideas.com>
from "kaiq@realtyideas.com" at "Feb 7, 2000 00:15:34 am"
To: kaiq@realtyideas.com
Date: Mon, 7 Feb 2000 18:06:18 +0100 (CET)
CC: Hannu Krosing <hannu@tm.ee>, Chris <chris@bitmead.com>,
Peter Eisentraut <peter_e@gmx.net>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
pgsql-sql@postgreSQL.org, pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

2) good books, like " C++ object databases" (David Jordan) has
a lot material.

As an example:

Cattel, "The Object Database Standard ODMG 2.0"

Morgan Kaufmann, ISBN 1 - 55860 - 463 -4

Marten Feldtmann

From bouncefilter Mon Feb 7 12:12:13 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA17447
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 12:11:16 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA20104;
Mon, 7 Feb 2000 12:10:40 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
In-reply-to: <3.0.1.32.20000207082146.0108a3b0@mail.pacifier.com>
References: <3.0.1.32.20000207070355.010866f0@mail.pacifier.com>
<3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
<3.0.1.32.20000207070355.010866f0@mail.pacifier.com>
<3.0.1.32.20000207082146.0108a3b0@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Mon, 07 Feb 2000 08:21:46 -0800"
Date: Mon, 07 Feb 2000 12:10:39 -0500
Message-ID: <20101.949943439@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Don Baccus <dhogaza@pacifier.com> writes:
SQL> select distinct x,y+1 from foo order by x+y+1

*
ERROR at line 1:
ORA-01791: not a SELECTed expression

Actually, that was a little unfair, since their parser no doubt parsed
"x+y+1" as (x+y)+1, leaving no common subexpression visible. Do they
accept

select distinct x,y+1 from foo order by x+(y+1)

At least, the rule is simple if you can compare expression trees.

I think we have something pretty similar for GROUP BY, actually,
so it may not be hard to make this work.

On further thought, I think the real implementation issue is that
doing SELECT DISTINCT ORDER BY requires either two sorting steps
(sort by DISTINCT fields, "uniq" filter, sort again by ORDER BY fields)
or else some very hairy logic to figure out that ORDER BY x+1
"implies" ORDER BY x. In fact I'm not sure it does imply it
in the general case. In your original example, the requested sort
was ORDER BY upper(x), but that doesn't guarantee that the tuples
will be ordered adequately for duplicate-x elimination. For example,
that ORDER BY might yield

Ansel Adams
Don Baccus
DON BACCUS
Don Baccus
Joe Blow
...

which is a valid sort by upper(x), but a uniq filter on plain x
will fail to get rid of the second occurrence of "Don Baccus" as
it should.

Possibly we could make this work by implicitly expanding the ORDER BY
to "ORDER BY upper(x), x" which would ensure that the duplicate x's
are brought together.  I am not sure this will give the right results
always, but it seems promising.  We are assuming here that upper(x)
gives equal outputs for equal inputs, so it would fall down on random(x)
--- I suppose we could refuse to do this if we see a function that is
marked non-constant-foldable in pg_proc...

regards, tom lane

From bouncefilter Mon Feb 7 12:23:13 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id MAA20251
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 12:23:09 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12Hrhc-0003kMC; Mon, 7 Feb 100 18:11 MET
Message-Id: <m12Hrhc-0003kMC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] New Globe
In-Reply-To: <200002071632.LAA02867@candle.pha.pa.us> from Bruce Momjian at
"Feb 7, 2000 11:32:30 am"
To: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Mon, 7 Feb 2000 18:11:56 +0100 (CET)
CC: Vince Vielhaber <vev@michvhf.com>, Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yep. Did it on hub. Took (I think) 6 and a half hours.

That's it. No new developers. The globe takes too long to generate. :-)

Not as much as a problem you might think it is. The default
make target is a poor quality image, rendering aprox. 2
minutes on my 333MHz PII. So adding/removing pins can be
verified/tested quickly.

Only rendering the final image in full quality is what pushes
the CPU against the wall.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 7 12:13:13 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA17710
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 12:12:23 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id MAA00908
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 12:12:25 -0500
Message-ID: <389EFCF6.CC28F902@wgcr.org>
Date: Mon, 07 Feb 2000 12:12:22 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: PostgreSQL 7 RPMs coming soon
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is a heads up about some changes I'm considering for the PostgreSQL
7.0 RPMS. If the RPMs do not interest you, or you are not involved in
supporting PostgreSQL in the RPM form, then feel free to hit delete.

I wanted to get feedback from the group before I made any changes -- 7.0
is
slated to go beta Feb 15, and I plan on having RPM's available within a
few hours of the official beta release. I already have feedback from my
contact at RedHat -- and it is complete agreement with the changes I am
proposing.

First, 7.0 has changed many small things about the operation of the
system, including a new procedural language (plperl), a reorganized
regression test suite, and a new 'pg_ctl' command to start and stop the
postmaster.

As a result, I will be having to make some minor changes; and there is
one major change I want to make.

1.) I want to move the actual database directory from /var/lib/pgsql to
/var/lib/pgsql/data -- this will give the ability to store backups and
other scratch data in /var/lib/pgsql without disturbing the main
database, in an FHS-compliant manner (the current regression tests AND
upgrade scripts are not in compliance with the FHS in terms of their
packaging, unfortunately -- I want to rectify this). This of course will
require sufficient documentation -- and I will provide functionality to
use an existing data structure in /var/lib/pgsql instead, until the user
moves it (new installations will default the initdb to
/var/lib/pgsql/data).

2.) I will be enabling logs and logrotate functionality in the next
release.

3.) /etc/rc.d/init.d/postgresql will be rewritten to use the pg_ctl
command, instead of doing the start/stop manually.

4.) The new plperl language will go in postgresql-perl.

5.) I am considering splitting out pgaccess and the tk client from
postgresql-tcl to postgresql-tk -- I have had several requests from
users of servers that are using the tcl client and the pltcl language
who do not have X11 installed, a current requirement for the
installation of postgresql-tcl.

6.) And, of course, an update to version 7.0. This will involve
extensive testing for Alpha, Sparc, and MIPS support -- I am hoping that
Ryan Kirkpatrick and Uncle George can get the Alpha patches in order for
7.0, as I don't believe Tom had time to do the fmgr rewrite like he
wanted. I am also hoping that a number of people with MIPS, ARM, Alpha,
and Sparc (both 32 and 64) will volunteer to beta test 7.0.

The initial builds will be done for Intel only -- until I get patches
and/or confirmation of build on other architectures from those who are
able to test those.

If you have additional suggestions for improving the RPM distribution,
please e-mail them to me.

TIA for your feedback.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Mon Feb 7 12:07:12 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA15809
for <hackers@postgresql.org>; Mon, 7 Feb 2000 12:06:56 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA02971;
Mon, 7 Feb 2000 17:15:04 GMT
Sender: lockhart@hub.org
Message-ID: <389EFD98.D95CFA3F@alumni.caltech.edu>
Date: Mon, 07 Feb 2000 17:15:04 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>,
Jan Wieck <jwieck@debis.com>
Subject: status
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm working on getting "table shape" from the outer join syntax.
Pretty sure I'm close, and will get to the parser stuff *soon*.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Mon Feb 7 12:39:17 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA26911
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 12:38:56 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA08496;
Mon, 7 Feb 2000 12:35:53 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002071735.MAA08496@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <20056.949942065@sss.pgh.pa.us> from Tom Lane at "Feb 7,
2000 11:47:45 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 7 Feb 2000 12:35:53 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Don't tell me we fsync on every buffer write, and not just at
transaction commit? That is terrible.

If you don't have -F set, yup. Why did you think fsync mode was
so slow?

What if we set a flag on the file descriptor stating we dirtied/wrote
one of its buffers during the transaction, and cycle through the file
descriptors on buffer commit and fsync all involved in the transaction.

That's exactly what Tatsuo was describing, I believe. I think Hiroshi
has pointed out a serious problem that would make it unreliable when
multiple backends are running: if some *other* backend fwrites the page
instead of your backend, and it doesn't fsync until *its* transaction is
done (possibly long after yours), then you lose the ordering guarantee
that is the point of the whole exercise...

OK, I understand now. You are saying if my backend dirties a buffer,
but another backend does the write, would my backend fsync() that buffer
that the other backend wrote.

I can't imagine how fsync could flush _only_ the file discriptor buffers
modified by the current process. It would have to affect all buffers
for the file descriptor.

BSDI says:

Fsync() causes all modified data and attributes of fd to be moved to a
permanent storage device. This normally results in all in-core modified
copies of buffers for the associated file to be written to a disk.

Looking at the BSDI kernel, there is a user-mode file descriptor table,
which maps to a kernel file descriptor table. This table can be shared,
so a file descriptor opened multiple times, like in a fork() call. The
kernel table maps to an actual file inode/vnode that maps to a file.
The only thing that is kept in the file descriptor table is the current
offset in the file (struct file in BSD). There is no mapping of who
wrote which blocks.

In fact, I would suggest that any kernel implementation that could track
such things would be pretty broken. I can imagine some cases the use of
that mapping of blocks to file descriptors would cause compatibility
problems. Those buffers have to be shared by all processes.

So, I think we are safe if we can either keep that file descriptor open
until commit, or re-open it and fsync it on commit. That assume a
re-open is hitting the same file. My opinion is that we should just
fsync it on close and not worry about a reopen.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 12:37:13 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA26585
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 12:37:05 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA08509;
Mon, 7 Feb 2000 12:36:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002071736.MAA08509@candle.pha.pa.us>
Subject: Re: [HACKERS] New Globe
In-Reply-To: <m12Hrhc-0003kMC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Feb 7, 2000 06:11:56 pm"
To: Jan Wieck <wieck@debis.com>
Date: Mon, 7 Feb 2000 12:36:29 -0500 (EST)
CC: Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yep. Did it on hub. Took (I think) 6 and a half hours.

That's it. No new developers. The globe takes too long to generate. :-)

Not as much as a problem you might think it is. The default
make target is a poor quality image, rendering aprox. 2
minutes on my 333MHz PII. So adding/removing pins can be
verified/tested quickly.

Only rendering the final image in full quality is what pushes
the CPU against the wall.

That map is just too cool.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 13:23:14 2000
Received: from rage.hub.org (root@nat195.216.mpoweredpc.net [142.177.195.216])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA39132
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 13:22:23 -0500 (EST)
(envelope-from jeffm@pgsql.com)
Received: from localhost (jeffm@localhost)
by rage.hub.org (8.9.3/8.9.3) with ESMTP id OAA99253;
Mon, 7 Feb 2000 14:20:07 -0400 (AST) (envelope-from jeffm@pgsql.com)
X-Authentication-Warning: rage.hub.org: jeffm owned process doing -bs
Date: Mon, 7 Feb 2000 14:20:06 -0400 (AST)
From: "Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com>
X-Sender: jeffm@rage.hub.org
Reply-To: Jeff MacDonald <jeff@pgsql.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Jeff MacDonald <jeff@pgsql.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Longer Column Names
In-Reply-To: <19799.949939583@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.10002071419070.10395-100000@rage.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Ok sounds good then. got a few questions..

1: how to change this (i assume it's in the source, and not a
configure otpion)

2: will it require and initdb , backup, reinstall . or just
recompilie and let her rip.

jeff

======================================================
Jeff MacDonald
jeff@pgsql.com irc: bignose on EFnet
======================================================

On Mon, 7 Feb 2000, Tom Lane wrote:

"Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com> writes:

Will Postgres suffer any major performance hits from
recomiling with support for column names over 32 chars.
ie: 64 chars.

I doubt it'd make a large difference, except that your system
tables would get bigger. Try it and let us know what you see...

regards, tom lane

************

From bouncefilter Mon Feb 7 13:32:13 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA41381
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 13:31:23 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA01183;
Mon, 7 Feb 2000 13:27:20 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002071827.NAA01183@candle.pha.pa.us>
Subject: Re: fsync alternatives (was: Re: [HACKERS] TODO item)
In-Reply-To: <20000207103646.A25520@fw.wintelcom.net> from Alfred Perlstein at
"Feb 7, 2000 10:36:46 am"
To: Alfred Perlstein <bright@wintelcom.net>
Date: Mon, 7 Feb 2000 13:27:20 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

So, I think we are safe if we can either keep that file descriptor open
until commit, or re-open it and fsync it on commit. That assume a
re-open is hitting the same file. My opinion is that we should just
fsync it on close and not worry about a reopen.

I'm pretty sure that the standard is that a close on a file _should_
fsync it.

This is not true. close flushes the user buffers to kernel buffers. It
does not force to physical disk in all cases, I think. There is really
no need to force them to disk on close. The only time they have to be
forced to disk is when the system shuts down, or on an fsync call.

In re the fsync problems...

I came across this option when investigating implementing range fsync()
for FreeBSD, 'O_FSYNC'/'O_SYNC'.

Why not keep 2 file descritors open for each datafile, one opened
with O_FSYNC (exists but not documented in FreeBSD) and one normal?
This garantees sync writes for all write operations on that fd.

We actually don't want this. We like to just fsync the file descriptor
and retroactively fsync all our writes. fsync allows us to decouple the
write and the fsync, which is what we really are attempting to do. Our
current behavour is to do write/fsync together, which is wasteful.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 13:47:13 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id NAA47020
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 13:46:38 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12Ht0s-0003kMC; Mon, 7 Feb 100 19:35 MET
Message-Id: <m12Ht0s-0003kMC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: RI project status
To: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Date: Mon, 7 Feb 2000 19:35:54 +0100 (CET)
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Good news!

FYI, with contributions from Stephan Szabo and Don Baccus,
the FOREIGN KEY project made impressive progress during the
last days.

pg_dump is now able to dump FK constraints.

pg_dump arranges to disable/reenable all triggers during data
only reload.

ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY is fully
implemented, and all existing data in the altered table is
verified to satisfy the new constraint.

The table actually created can be self referenced in the
constraints.

In contrast to my proposal, MATCH FULL and MATCH
<unspecified> will both be fully supported in 7.0 already. So
only MATCH PARTIAL will be left for 7.1.

The open items left for 7.0 are now the file buffering for
the trigger queue, the parser problem with NOT DEFERRABLE
(where Thomas actually jumps in), building a regression suite
and documentation.

Many thanks to the two guys above. Without them, FOREIGN KEY
would not only have failed to be finished in time. There
would have been a big mistake maken for NO ACTION at all,
leaving a huge hole for possible violations and not
conforming to the standard.

There is more to do after 7.0 is out, like ensuring that a
unique constraint is defined on referenced PK columns,
changing RESTRICT actions to fire as soon as possible and
ensuring uniqueness of constraint names. But what has been
done so far is IMHO really a major leap forward.

7.0 will have better FOREIGN KEY support than I expected.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 7 13:14:13 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA37507
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 13:13:54 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id KAA09838;
Mon, 7 Feb 2000 10:36:46 -0800 (PST)
Date: Mon, 7 Feb 2000 10:36:46 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: fsync alternatives (was: Re: [HACKERS] TODO item)
Message-ID: <20000207103646.A25520@fw.wintelcom.net>
References: <20056.949942065@sss.pgh.pa.us>
<200002071735.MAA08496@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200002071735.MAA08496@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Mon, Feb 07, 2000 at 12:35:53PM
-0500

* Bruce Momjian <pgman@candle.pha.pa.us> [000207 10:14] wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Don't tell me we fsync on every buffer write, and not just at
transaction commit? That is terrible.

If you don't have -F set, yup. Why did you think fsync mode was
so slow?

What if we set a flag on the file descriptor stating we dirtied/wrote
one of its buffers during the transaction, and cycle through the file
descriptors on buffer commit and fsync all involved in the transaction.

That's exactly what Tatsuo was describing, I believe. I think Hiroshi
has pointed out a serious problem that would make it unreliable when
multiple backends are running: if some *other* backend fwrites the page
instead of your backend, and it doesn't fsync until *its* transaction is
done (possibly long after yours), then you lose the ordering guarantee
that is the point of the whole exercise...

OK, I understand now. You are saying if my backend dirties a buffer,
but another backend does the write, would my backend fsync() that buffer
that the other backend wrote.

I can't imagine how fsync could flush _only_ the file discriptor buffers
modified by the current process. It would have to affect all buffers
for the file descriptor.

BSDI says:

Fsync() causes all modified data and attributes of fd to be moved to a
permanent storage device. This normally results in all in-core modified
copies of buffers for the associated file to be written to a disk.

Looking at the BSDI kernel, there is a user-mode file descriptor table,
which maps to a kernel file descriptor table. This table can be shared,
so a file descriptor opened multiple times, like in a fork() call. The
kernel table maps to an actual file inode/vnode that maps to a file.
The only thing that is kept in the file descriptor table is the current
offset in the file (struct file in BSD). There is no mapping of who
wrote which blocks.

In fact, I would suggest that any kernel implementation that could track
such things would be pretty broken. I can imagine some cases the use of
that mapping of blocks to file descriptors would cause compatibility
problems. Those buffers have to be shared by all processes.

So, I think we are safe if we can either keep that file descriptor open
until commit, or re-open it and fsync it on commit. That assume a
re-open is hitting the same file. My opinion is that we should just
fsync it on close and not worry about a reopen.

I'm pretty sure that the standard is that a close on a file _should_
fsync it.

In re the fsync problems...

I came across this option when investigating implementing range fsync()
for FreeBSD, 'O_FSYNC'/'O_SYNC'.

Why not keep 2 file descritors open for each datafile, one opened
with O_FSYNC (exists but not documented in FreeBSD) and one normal?
This garantees sync writes for all write operations on that fd.

Most unicies offer an open flag for this type of access although the name
will vary (Linux/Solaris uses O_SYNC afaik).

When a sync write is needed then use that filedescriptor to do the writing,
and use the normal one for non-sync writes.

This would fix the problem where another backend causes an out-of-order
or unsafe fsync to occur.

Another option is using mmap() and msync() to achive the same effect, the
only problem with mmap() is that under most i386 systems you are limited
to a < 4gig (2gig with FreeBSD) mapping that would have to be 'windowed'
over the datafiles, however depending on the locality of accesses this
may be much more effecient that read/write semantics.
Not to mention that a lot of unicies have broken mmap() implementations
and problems with merged vm/buffercache.

Yes, I haven't looked at the backend code, just hoping to offer some
useful suggestions.

-Alfred

From bouncefilter Mon Feb 7 13:54:14 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA48144
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 13:53:55 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id KAA23625;
Mon, 7 Feb 2000 10:52:28 -0800 (PST)
Message-Id: <3.0.1.32.20000207103737.01090c10@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 10:37:37 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] DISTINCT and ORDER BY bug?
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <20101.949943439@sss.pgh.pa.us>
References: <3.0.1.32.20000207082146.0108a3b0@mail.pacifier.com>
<3.0.1.32.20000207070355.010866f0@mail.pacifier.com>
<3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206190418.0107cca0@mail.pacifier.com>
<3.0.1.32.20000206220527.01084ad0@mail.pacifier.com>
<3.0.1.32.20000207070355.010866f0@mail.pacifier.com>
<3.0.1.32.20000207082146.0108a3b0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:10 PM 2/7/00 -0500, Tom Lane wrote:

Don Baccus <dhogaza@pacifier.com> writes:
SQL> select distinct x,y+1 from foo order by x+y+1

*
ERROR at line 1:
ORA-01791: not a SELECTed expression

Actually, that was a little unfair, since their parser no doubt parsed
"x+y+1" as (x+y)+1, leaving no common subexpression visible. Do they
accept

select distinct x,y+1 from foo order by x+(y+1)

Yes, it does. So, they must be doing some level of common expression
analysis, for real.

At least, the rule is simple if you can compare expression trees.

I think we have something pretty similar for GROUP BY, actually,
so it may not be hard to make this work.

On further thought, I think the real implementation issue is that
doing SELECT DISTINCT ORDER BY requires either two sorting steps
(sort by DISTINCT fields, "uniq" filter, sort again by ORDER BY fields)

Yes.

or else some very hairy logic to figure out that ORDER BY x+1
"implies" ORDER BY x. In fact I'm not sure it does imply it
in the general case. In your original example, the requested sort
was ORDER BY upper(x), but that doesn't guarantee that the tuples
will be ordered adequately for duplicate-x elimination.

I realize that. I would assume that a double-sort penalty might
be incurred, i.e. the select distinct ... is executed followed by
the order by.

Possibly we could make this work by implicitly expanding the ORDER BY
to "ORDER BY upper(x), x" which would ensure that the duplicate x's
are brought together.

That would be another approach, too, if it works for all cases...

I am not sure this will give the right results
always, but it seems promising.  We are assuming here that upper(x)
gives equal outputs for equal inputs, so it would fall down on random(x)
--- I suppose we could refuse to do this if we see a function that is
marked non-constant-foldable in pg_proc...

Something like that, yes.

I just checked Date while off having coffee, and it is clear that the
SQL standard specifies that ORDER BY operates on COLUMNS, not expressions.
So the restriction that's now imposed is indeed standard compliant. However,
some level of extension in this area would be very useful, and my guess is
that examples like the one that started this discussion are very common.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 13:55:14 2000
Received: from r149127-2815.dobiecenter.com ([209.217.149.127])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA48300
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 13:54:42 -0500 (EST)
(envelope-from taral@taral.net)
Received: from localhost (taral@localhost)
by r149127-2815.dobiecenter.com (8.9.3/8.9.3) with ESMTP id MAA29846;
Mon, 7 Feb 2000 12:54:06 -0600
X-Authentication-Warning: r149127-2815.dobiecenter.com: taral owned process
doing -bs
Date: Mon, 7 Feb 2000 12:54:06 -0600 (CST)
From: Taral <taral@taral.net>
X-Sender: taral@r149127-2815.dobiecenter.com
To: Don Baccus <dhogaza@pacifier.com>
cc: Chris <chris@bitmead.com>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ONLY
In-Reply-To: <3.0.1.32.20000207071035.0108a2c0@mail.pacifier.com>
Message-ID:
<Pine.LNX.4.10.10002071252500.28588-100000@r149127-2815.dobiecenter.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 7 Feb 2000, Don Baccus wrote:

While all language standards have some bugs of this sort, the SQL standard
seems to be full of them.

*sigh* I hate it when people do this. YOU try writing a standard with that
much information such that nobody will come back to you and say "you left
such-and-such undefined". It's _very_ hard and requires a lot of
definitions. I'll admit, however, that section summaries would be nice --
I had to wade through way too much stuff to find out what MATCH FULL
meant exactly.

Taral

From bouncefilter Mon Feb 7 13:58:14 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA48886
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 13:57:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA02211;
Mon, 7 Feb 2000 13:54:32 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002071854.NAA02211@candle.pha.pa.us>
Subject: Re: fsync alternatives (was: Re: [HACKERS] TODO item)
In-Reply-To: <20000207111736.D25520@fw.wintelcom.net> from Alfred Perlstein at
"Feb 7, 2000 11:17:36 am"
To: Alfred Perlstein <bright@wintelcom.net>
Date: Mon, 7 Feb 2000 13:54:32 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yes, the way I understand it is that one backend doing the fsync
will sync the entire file perhaps forcing a sync in the middle of
a somewhat critical update being done by another instance of the
backend.

We don't mind that. Until the transaction is marked as complete, they
can fsync anything we want. We just want all stuff modified by a
transaction fsynced before a transaction is marked as completed.

I'm aware of the performance implications sync writes cause, but
using fsync after every write seems to cause massive amounts of
unessesary disk IO that could be avoided with using explicit
sync descriptors with little increase in complexity considering
what I understand of the current implementation.

Yes.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 14:14:15 2000
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA56118
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 14:13:30 -0500 (EST)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id WAA01746;
Mon, 7 Feb 2000 22:12:31 +0300 (GMT)
Date: Mon, 7 Feb 2000 22:12:31 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PostgreSQL 7 RPMs coming soon
In-Reply-To: <389EFCF6.CC28F902@wgcr.org>
Message-ID: <Pine.GSO.3.96.SK.1000207220744.18475a-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Lamar,

I got report from bulgarian user who had problem with locale under
MANDRAKE caused by 'su -l postgres ...' I'll forward it to you.
Incorrectly configured i18n (LC_ALL) could override (?) locale
settings even if LC_CTYPE, LC_COLLATE explicitly specified in
startup script. I think you could check if all locale environment
are consistent with each other.

Oleg
On Mon, 7 Feb 2000, Lamar Owen wrote:

Date: Mon, 07 Feb 2000 12:12:22 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] PostgreSQL 7 RPMs coming soon

This is a heads up about some changes I'm considering for the PostgreSQL
7.0 RPMS. If the RPMs do not interest you, or you are not involved in
supporting PostgreSQL in the RPM form, then feel free to hit delete.

I wanted to get feedback from the group before I made any changes -- 7.0
is
slated to go beta Feb 15, and I plan on having RPM's available within a
few hours of the official beta release. I already have feedback from my
contact at RedHat -- and it is complete agreement with the changes I am
proposing.

First, 7.0 has changed many small things about the operation of the
system, including a new procedural language (plperl), a reorganized
regression test suite, and a new 'pg_ctl' command to start and stop the
postmaster.

As a result, I will be having to make some minor changes; and there is
one major change I want to make.

1.) I want to move the actual database directory from /var/lib/pgsql to
/var/lib/pgsql/data -- this will give the ability to store backups and
other scratch data in /var/lib/pgsql without disturbing the main
database, in an FHS-compliant manner (the current regression tests AND
upgrade scripts are not in compliance with the FHS in terms of their
packaging, unfortunately -- I want to rectify this). This of course will
require sufficient documentation -- and I will provide functionality to
use an existing data structure in /var/lib/pgsql instead, until the user
moves it (new installations will default the initdb to
/var/lib/pgsql/data).

2.) I will be enabling logs and logrotate functionality in the next
release.

3.) /etc/rc.d/init.d/postgresql will be rewritten to use the pg_ctl
command, instead of doing the start/stop manually.

4.) The new plperl language will go in postgresql-perl.

5.) I am considering splitting out pgaccess and the tk client from
postgresql-tcl to postgresql-tk -- I have had several requests from
users of servers that are using the tcl client and the pltcl language
who do not have X11 installed, a current requirement for the
installation of postgresql-tcl.

6.) And, of course, an update to version 7.0. This will involve
extensive testing for Alpha, Sparc, and MIPS support -- I am hoping that
Ryan Kirkpatrick and Uncle George can get the Alpha patches in order for
7.0, as I don't believe Tom had time to do the fmgr rewrite like he
wanted. I am also hoping that a number of people with MIPS, ARM, Alpha,
and Sparc (both 32 and 64) will volunteer to beta test 7.0.

The initial builds will be done for Intel only -- until I get patches
and/or confirmation of build on other architectures from those who are
able to test those.

If you have additional suggestions for improving the RPM distribution,
please e-mail them to me.

TIA for your feedback.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

************

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Mon Feb 7 13:54:14 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA48109
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 13:53:44 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id LAA11184;
Mon, 7 Feb 2000 11:17:36 -0800 (PST)
Date: Mon, 7 Feb 2000 11:17:36 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: fsync alternatives (was: Re: [HACKERS] TODO item)
Message-ID: <20000207111736.D25520@fw.wintelcom.net>
References: <20000207103646.A25520@fw.wintelcom.net>
<200002071827.NAA01183@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200002071827.NAA01183@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Mon, Feb 07, 2000 at 01:27:20PM
-0500

* Bruce Momjian <pgman@candle.pha.pa.us> [000207 11:00] wrote:

So, I think we are safe if we can either keep that file descriptor open
until commit, or re-open it and fsync it on commit. That assume a
re-open is hitting the same file. My opinion is that we should just
fsync it on close and not worry about a reopen.

I'm pretty sure that the standard is that a close on a file _should_
fsync it.

This is not true. close flushes the user buffers to kernel buffers. It
does not force to physical disk in all cases, I think. There is really
no need to force them to disk on close. The only time they have to be
forced to disk is when the system shuts down, or on an fsync call.

In re the fsync problems...

I came across this option when investigating implementing range fsync()
for FreeBSD, 'O_FSYNC'/'O_SYNC'.

Why not keep 2 file descritors open for each datafile, one opened
with O_FSYNC (exists but not documented in FreeBSD) and one normal?
This garantees sync writes for all write operations on that fd.

We actually don't want this. We like to just fsync the file descriptor
and retroactively fsync all our writes. fsync allows us to decouple the
write and the fsync, which is what we really are attempting to do. Our
current behavour is to do write/fsync together, which is wasteful.

Yes, the way I understand it is that one backend doing the fsync
will sync the entire file perhaps forcing a sync in the middle of
a somewhat critical update being done by another instance of the
backend.

Since the current behavior seems to be write/fsync/write/fsync...
instead of write/write/write/fsync you may as well try opening the
filedescriptor with O_FSYNC on operating systems that support it to
avoid the cross-fsync problem.

Another option is to use O_FSYNC descriptiors and aio_write to
allow a sync writes to be 'backgrounded'. More and more unix OS's
are supporting aio nowadays.

I'm aware of the performance implications sync writes cause, but
using fsync after every write seems to cause massive amounts of
unessesary disk IO that could be avoided with using explicit
sync descriptors with little increase in complexity considering
what I understand of the current implementation.

Basically it would seem to be a good hack until you get the algorithm
to batch fsyncs working. (write/write/write.../fsync) At that point
you may want to window over the files using msync(), but there may
be a better way, one that allows a vector of io to be scheduled for
sync write in one go, rather than a buffer at a time.

-Alfred

From bouncefilter Mon Feb 7 14:28:14 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA59450
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 14:27:47 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA06372;
Mon, 7 Feb 2000 11:26:57 -0800 (PST)
Message-Id: <3.0.1.32.20000207111939.01095d10@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 11:19:39 -0800
To: Taral <taral@taral.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] ONLY
Cc: Chris <chris@bitmead.com>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
In-Reply-To: <Pine.LNX.4.10.10002071252500.28588-100000@r149127-2815.dob
iecenter.com>
References: <3.0.1.32.20000207071035.0108a2c0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:54 PM 2/7/00 -0600, Taral wrote:

On Mon, 7 Feb 2000, Don Baccus wrote:

While all language standards have some bugs of this sort, the SQL standard
seems to be full of them.

*sigh* I hate it when people do this. YOU try writing a standard with that
much information such that nobody will come back to you and say "you left
such-and-such undefined".

I was at the very first organizational meeting for the creation of a
standard for Pascal, and was very active at the beginning of that
process (delegating it to someone else in my company when it got bogged
down in paralytic discussions over whether to use a comma or semicolon to
separate particular clauses, etc).

Since the BSI nailed me to the cross and made me agree to be one
of a half-dozen folks who met annually to accept or reject proposed
additions to their test suite, I'm actually quite used to having folks
tell me "you left such-and-such undefined". "you" in the collective sense
of those who drafted the standard. Sometimes they were even right.

I was also the BSI's designated technical consultant to the ISO
committee convened by the BSI to standardize Modula-2. Though I
got out of that thankless task after a year. I don't even know
if they ever finished, because I dropped out of the computer industry
shortly thereafter.

So ... I am aware of how hard the problem is. And I've spent far
too much of my life reading and reviewing proposed standards.

The SQL seems to have more than its fair share of contradictions.

Then again, SQL is far more complex than either of the languages I
mentioned above. So's C++, and its standard is a morass that reflects
the fact that the language itself is a morass. And Bjarne's just an...oh,
let's not go there.

I had friends (and one employee) on the ANSI committee, and dropped in on
one meeting just to lend a sympathetic ear. I'm really glad I was smart
enough to never come back, one meeting was enough!

It's _very_ hard and requires a lot of definitions.

Yes, I know. That doesn't change the fact that the result in this
case is extremely opaque!

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 14:57:14 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id OAA71604
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 14:56:53 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12Hu6r-0003kMC; Mon, 7 Feb 100 20:46 MET
Message-Id: <m12Hu6r-0003kMC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Using libpq.dll from Delphi
To: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Date: Mon, 7 Feb 2000 20:46:09 +0100 (CET)
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi folks,

some days ago, I got a file "libpq.pas" as a response for
some help to use the libpq interface directly from Delphi
under Windows.

The guy said we can use it freely, and that it isn't anything
more than just porting the libpq-fe.h from C to Pascal. I
asked for a little README to put both together under
./interfaces, and got nothing back :-(.

I'm not familiar with Delphi. Could someone else verify the
stuff and write that README? AFAIK he found the libpq.dll in
the pgaccess corner of a past release.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 7 14:48:14 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA69489
for <hackers@postgresql.org>; Mon, 7 Feb 2000 14:48:01 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63482 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S448553AbQBGTrG>;
Mon, 7 Feb 2000 20:47:06 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12Hu9r-0001jp-00; Mon, 07 Feb 2000 20:49:15 +0100
Date: Mon, 7 Feb 2000 20:49:15 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Duplicate table names
In-Reply-To: <389DAF82.A8F8B561@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0002070016470.13872-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-06, Thomas Lockhart mentioned:

The following query is rejected (and always has been afaik):

select * from t1, t1;

Does this rejection have any basis in SQL92? (I haven't looked; hoping
someone else has.)

Not according to the way I decoded it. It's a join of t1 with itself and
you get all columns twice.

istm that

select x from t1, t1;

would have trouble, but the wildcard could do the Right Thing even

This is the same problem as

select x from t1, t2;

where both t1 and t2 have a column x. It's an error. It's not an error if
column x is unambiguous. Chances are pretty good (=100%) that there will
be ambiguity if you list the same table twice, but there's no reason to
reject this for the reason it gives now.

[snip]

I'm thinking of implementing this by allowing multiple RTEs to have
the *same* table alias, (as long as there aren't column name conflicts
in the "visible" columns), so that, at least internally,

select * from t1 tx, t3 tx;

becomes legal as long as t1 and t3 do not share common column names.

This seems perfectly legal as well, even if they do share column names.
Any reference to tx.y will fail due to ambiguity, but it shouldn't merely
because of name checking.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 7 14:49:32 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA69544
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 14:48:20 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64203 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S292921AbQBGTrf>;
Mon, 7 Feb 2000 20:47:35 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12HuAI-0001lF-00; Mon, 07 Feb 2000 20:49:42 +0100
Date: Mon, 7 Feb 2000 20:49:42 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] psql -e and -n flags
In-Reply-To: <24524.949852482@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002062340050.13872-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-06, Tom Lane mentioned:

Furthermore, does anyone have anything to say in defence of the -n ("no
readline") option? If not, I'd be tempted to "hide" it now, since it may
be a popular option letter to have available in the future.

readline automatically turns off if the input is not coming from a
terminal, right? That seems like the only really compelling reason
to have -n (since you wouldn't want script commands filling your
history or being subject to tab-completion). I suppose someone who

You're right, readline is of course not used if the session is not
interactive. The fact of the matter is that the flag isn't even checked in
that case and things like loading the history file (a real hog) is not
done either.

really hated tab-completion might want a way to turn off just that
feature, though --- is there a way?

Sure. Put
$if psql
set disable-completion on
$endif
in your ~/.inputrc. (Whoever came up with that double negative, though?)

BTW, if you need one more item for your psql todo list ;-) ... when
looking at EXPLAIN outputs it's possible to get NOTICE messages that
fill many screensful. It might be nice if NOTICEs went through the
pager like query results do.

Oh boy, I can't promise anything there at this point in time.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 7 14:49:19 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA69688
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 14:49:02 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61357 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S24637AbQBGTsU>;
Mon, 7 Feb 2000 20:48:20 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12HuAW-0001lV-00; Mon, 07 Feb 2000 20:49:56 +0100
Date: Mon, 7 Feb 2000 20:49:56 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] psql -e and -n flags
In-Reply-To: <389DA2A0.EC14B8D3@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0002062350010.13872-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-06, Thomas Lockhart mentioned:

The suggestion I have is to offer the traditional behaviour with a single
-e flag, so there's little change for anyone switching from <7.0, and the
"full" echo mode with two -e flags. I'd then change the flags in the
regression drivers to -e -e. Comments? Better ideas?

Hmm. imho having a *count* of switch options being significant is the
wrong way to go. It gets in the way of things like

# alias ps psql -e
# ps -e postgres

where someone has defined a "convenience" alias for everyone and
someone else uses it later. Also, it is a style of switch invocation
not appearing elsewhere afaik.

I don't like it either, but I wasn't sure of a better way.

I'd suggest a switch style like "-ee" or "-eb" (backend) or "-ev"
(verbatim) or ??? Comments?

Well that is an option style that doesn't appear anywhere either other
than perhaps find(1). getopt() would read "-ee" exactly as "-e -e", a
behaviour which conforms to POSIX and GNU and ROW (rest of world).

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 7 14:49:14 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA69690
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 14:49:03 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61467 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S448553AbQBGTsX>;
Mon, 7 Feb 2000 20:48:23 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12HuAk-0001ll-00; Mon, 07 Feb 2000 20:50:10 +0100
Date: Mon, 7 Feb 2000 20:50:10 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Don Baccus <dhogaza@pacifier.com>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] psql -e and -n flags
In-Reply-To: <3.0.1.32.20000206080311.0105fe70@mail.pacifier.com>
Message-ID: <Pine.LNX.4.21.0002062354290.13872-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-06, Don Baccus mentioned:

At 02:07 PM 2/6/00 +0100, Peter Eisentraut wrote:

The suggestion I have is to offer the traditional behaviour with a single
-e flag, so there's little change for anyone switching from <7.0, and the
"full" echo mode with two -e flags. I'd then change the flags in the
regression drivers to -e -e. Comments? Better ideas?

"-E"? Or another flag? I think "-e -e" is a real kludge. If I

You're ignoring that -E is already used. It would be my first choice as
well, but it's a compatibility break. How about -a ("all")?

thought the full-echo mode were only useful for regression tests I wouldn't
care, but I like the idea of a full echo and I'm sure others do, too, so
I'd rather see it be receive full flag citizenship rather than the double
"-e" bit.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 7 14:53:14 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA70497
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 14:52:21 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61808 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S211000AbQBGTvc>;
Mon, 7 Feb 2000 20:51:32 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12HuE3-0001ps-00; Mon, 07 Feb 2000 20:53:35 +0100
Date: Mon, 7 Feb 2000 20:53:35 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_ctl man page
In-Reply-To: <20000207134947O.t-ishii@sra.co.jp>
Message-ID: <Pine.LNX.4.21.0002072051550.6572-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-07, Tatsuo Ishii mentioned:

I got grammer corrections from Ed Loehr. Also, I modified some option
flag styles according to Thomas's suggestion. Thanks for those who
gave me suggestions.

Thomas, I have changed -m <opts> style to -smart, -fast... style. I
hope this was what you meant. Also, please note that I still stick
with smart/fast/immediate since I have been waiting for Vadim's
opinion...

Ugh, that's not a compliant option style. What was wrong with -m
<opt>? How about --smart, etc.? But 'single dash, multiple letters' is
evil.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 7 15:34:15 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA84665
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 15:34:10 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA01290;
Mon, 7 Feb 2000 12:33:25 -0800 (PST)
Message-Id: <3.0.1.32.20000207122612.0109c7f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 12:26:12 -0800
To: Peter Eisentraut <peter_e@gmx.net>,
Thomas Lockhart <lockhart@alumni.caltech.edu>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Duplicate table names
Cc: Postgres Hackers List <hackers@postgreSQL.org>
In-Reply-To: <Pine.LNX.4.21.0002070016470.13872-100000@localhost.localdo main>
References: <389DAF82.A8F8B561@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 08:49 PM 2/7/00 +0100, Peter Eisentraut wrote:

Not according to the way I decoded it. It's a join of t1 with itself and
you get all columns twice.

...

This is the same problem as

select x from t1, t2;

where both t1 and t2 have a column x. It's an error. It's not an error if
column x is unambiguous. Chances are pretty good (=100%) that there will
be ambiguity if you list the same table twice, but there's no reason to
reject this for the reason it gives now.

I believe that Peter's right on all counts.

[snip]

I'm thinking of implementing this by allowing multiple RTEs to have
the *same* table alias, (as long as there aren't column name conflicts
in the "visible" columns), so that, at least internally,

select * from t1 tx, t3 tx;

becomes legal as long as t1 and t3 do not share common column names.

This seems perfectly legal as well, even if they do share column names.
Any reference to tx.y will fail due to ambiguity, but it shouldn't merely
because of name checking.

Actually, according to Date an explicit range variable must be
unique within a given scope.

Does Postgres implement scope? Apparently JOIN opens a new
scope...so do subselects.

select * from t1 tx, t3 tx is not legal SQL

select * from t1 tx, (select * from t3 tx) is legal SQL.

The tx inside the subselect hides the outer tx, just like
any 'ole block-structured language.

Date takes over six pages of fairly terse prose with few examples to
define the scope of range variables in and out of JOIN expressions.
A bit over one page of that is devoted to scoping issues unique
to JOINs, which I don't feel like reading at the moment!

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 15:34:15 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA84646
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 15:34:06 -0500 (EST)
(envelope-from oleg@sai.msu.su)
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id PAA03695
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 15:31:45 -0500 (EST)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id XAA03279
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 23:31:23 +0300 (GMT)
Date: Mon, 7 Feb 2000 23:31:22 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: hackers@postgreSQL.org
Subject: network_ops in 7.0 and pg_dump question
Message-ID: <Pine.GSO.3.96.SK.1000207232451.18475j-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

what's happen with network_ops in current CVS ?
I just synced sources and couldn't load dump from 6.5.3 -
problem occures on
CREATE INDEX "face_key" on "face" using btree ( "eid" "int4_ops", "ip" "network_ops" );

The message I got:
CREATE
ERROR: DefineIndex: network_ops class not found

Table face:
election=# \d face
Table "face"
Attribute | Type | Modifier
-----------+------------+----------
eid | integer |
ip | inet |
vdate | datetime |
ftrs | smallint[] |

Also, does new pg_dump is aware about order of defining of function
and tables, when function is used in CREATE TABLE, for example:
CREATE TABLE "applicant" (
"candx" int2 DEFAULT next_applicant ( ) NOT NULL,
"candidate" text,
"candt" int2,
"img" text);
but function next_applicant() is dumped in 6.5.3 after CREATE TABLE
and this cause an error. I had manually edit dump file to reverse order :-)

Regards,

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Mon Feb 7 15:53:15 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA91812
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 15:52:49 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA11461;
Mon, 7 Feb 2000 15:52:01 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002072052.PAA11461@candle.pha.pa.us>
Subject: Re: [HACKERS] network_ops in 7.0 and pg_dump question
In-Reply-To: <Pine.GSO.3.96.SK.1000207232451.18475j-100000@ra> from Oleg
Bartunov at "Feb 7, 2000 11:31:22 pm"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Mon, 7 Feb 2000 15:52:01 -0500 (EST)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

what's happen with network_ops in current CVS ?
I just synced sources and couldn't load dump from 6.5.3 -
problem occures on
CREATE INDEX "face_key" on "face" using btree ( "eid" "int4_ops", "ip" "network_ops" );

The message I got:
CREATE
ERROR: DefineIndex: network_ops class not found

Oops, my fault. There was some confusing links in the catalog for the
ip/cidr types. They pointed to the same *ops, which made the table
non-unique, so the cache would grab a random matching entry. The new
system has separate *ops for each type. We were basically using the
cache on a non-unique entry. We would grab the first match. The new
code uses the same underlying functions, but moves the duplication down
one level.

Now, how to convert these? Not supplying the ops works fine, but
pg_dump supplies the ops. Maybe in gram.y, if they supply network_ops,
we should just remove that from being passed to the backend for a few
releases. Comments?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 15:47:15 2000
Received: from hu.tm.ee (ppp731.tele2.ee [212.107.37.31])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA90245
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 15:46:15 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 75F913A20; Mon, 7 Feb 2000 22:53:30 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389F30C9.915DDC4A@tm.ee>
Date: Mon, 07 Feb 2000 22:53:29 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: chris@bitmead.com
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] An introduction and a plea ...
References: <20000206.17574200@localhost.localdomain>
<389E1321.25AB8C40@tm.ee>
<389E16F7.CFB8CBCF@nimrod.itg.telecom.com.au>
<389E1F28.30DAB2A5@tm.ee>
<389E1E8F.DBDDEDE3@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Bitmead wrote:

Hannu Krosing wrote:

The same kind of file could be used for re_introducing time-travel in an
efficient way.

How?

By writing (TID,TIMESTAMP) tuples there and using that info to retrieve tuples
active at specified time by examinimg TIDs in "deleted" tuples.
As bot TID and TIMESTAMP should be monotonuously growing again binary search
can be used on retrieve and inserts are append-only (meaning fast)

But since we are already storing all the time travel stuff already in
the storage pages do we need this to reinstate time travel?

If we want to query for old tuples by wallclock time (which is not stored) and
not only by transaction-id (which are) we need something to go from wc-time to
tid
and back.

Also if you reinstate time travel this way it will only work for people using
this odbms feature.
Wouldn't it be better to reinstate the old timetravel so it works for
everyone?

It would be probably better to do it under another set, probably at dbinit
(or createdb) time.

so maybe

set TIME_TRAVEL to 'on';
CREATE DATABASE TIME_TRAVELLERS_DB;

would create a database that can use the time-travel features.

It could of course be included in the db create statement:

CREATE DATABASE TIME_TRAVELLERS_DB WITH TIME_TRAVEL='ON';

BTW, have you considered making OO a per-database feature or at least the
default being settable when creating the database.

-----------------------
Hannu

From bouncefilter Mon Feb 7 16:15:16 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA01002
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 16:14:35 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id NAA15958;
Mon, 7 Feb 2000 13:13:44 -0800 (PST)
Message-Id: <3.0.1.32.20000207130301.0109a750@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 13:03:01 -0800
To: Peter Eisentraut <peter_e@gmx.net>,
Thomas Lockhart <lockhart@alumni.caltech.edu>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Duplicate table names
Cc: Postgres Hackers List <hackers@postgreSQL.org>
In-Reply-To: <3.0.1.32.20000207122612.0109c7f0@mail.pacifier.com>
References: <Pine.LNX.4.21.0002070016470.13872-100000@localhost.localdo main>
<389DAF82.A8F8B561@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:26 PM 2/7/00 -0800, Don Baccus wrote:

select * from t1 tx, t3 tx;

becomes legal as long as t1 and t3 do not share common column names.

This seems perfectly legal as well, even if they do share column names.
Any reference to tx.y will fail due to ambiguity, but it shouldn't merely
because of name checking.

Actually, according to Date an explicit range variable must be
unique within a given scope.

I consulted the Oracle, and it agrees with Peter, hmmm...and the
wording in Date's a bit ambiguous, he's not clear as to whether
the range variable must be unique when DEFINED, or must only be
unique if it is referenced, i.e. select tx.foo from t1 tx, t3 tx
is ambiguous.

Reading further into Date, he says that

select ... from t1

implicitly defines t1 as a range variable, and since

select ... from t1, t1 is legal, then range variables need not be
unique to be defined, 'cause according to the standard this
causes two range variables named t1 to be implicitly defined.

So, his comment about uniqueness within scope applies to whether
or not you can explicitly REFERENCE, not DEFINE the range var.

Sorry for the confusion...Peter was right all along.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 16:05:15 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA98752
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 16:04:43 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA12439;
Mon, 7 Feb 2000 16:03:10 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002072103.QAA12439@candle.pha.pa.us>
Subject: Re: [HACKERS] network_ops in 7.0 and pg_dump question
In-Reply-To: From "(env:" "pgman)" at "Feb 7, 2000 03:52:01 pm"
To: pgman@candle.pha.pa.us
Date: Mon, 7 Feb 2000 16:03:10 -0500 (EST)
CC: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I am applying a patch to gram.y to supress network_ops from coming in.
That should fix the problem. Will commit in a few minutes.

Hi,

what's happen with network_ops in current CVS ?
I just synced sources and couldn't load dump from 6.5.3 -
problem occures on
CREATE INDEX "face_key" on "face" using btree ( "eid" "int4_ops", "ip" "network_ops" );

The message I got:
CREATE
ERROR: DefineIndex: network_ops class not found

Oops, my fault. There was some confusing links in the catalog for the
ip/cidr types. They pointed to the same *ops, which made the table
non-unique, so the cache would grab a random matching entry. The new
system has separate *ops for each type. We were basically using the
cache on a non-unique entry. We would grab the first match. The new
code uses the same underlying functions, but moves the duplication down
one level.

Now, how to convert these? Not supplying the ops works fine, but
pg_dump supplies the ops. Maybe in gram.y, if they supply network_ops,
we should just remove that from being passed to the backend for a few
releases. Comments?

-- 
Bruce Momjian                        |  http://www.op.net/~candle
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 16:12:15 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA00232
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 16:11:28 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12HvRL-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Mon, 7 Feb 2000 15:11:23 -0600 (CST)
Date: Mon, 7 Feb 2000 15:11:23 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: pgsql-hackers@postgresql.org
Subject: CFH: Mariposa, distributed DB
Message-ID: <20000207151123.A25083@rice.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i

This is a Call For Hackers:

Some time ago, I floated a little discussion on this list about doing
some distributed database work with PostgreSQL. The project got back
burnered at work, but now has a timeline for needing a solution "this
summer." Recent discussions on this list about Postgres's historical
object roots got me back to the Berkeley db sites, and reminded me about
Mariposa, which is Stonebraker's take on distributed DBs.

http://s2k-ftp.cs.berkeley.edu:8000:8000/mariposa/

StoneBraker has gone on to commercialize Mariposa as Cohera, which seems
to be one of those Enterprise Scale products where if you need to ask
how much a license costs, you can't afford it ;-)

Sounds like now would be a good time to re-visit Mariposa, and see what
good ideas can be folded over into PostgreSQL. Mariposa was funded by
ARPA and ARO, and was used by NASA as the database part of the Sequoia
Project, which became Big Sur, looking to unify the various kinds of
geophysical data collected by earth observing missions.

The code is an offshoot of Postgres95, with lots of nasty '#ifdef P95's
scattered around. The split predates lots of good work by the PostgreSQL
team to clean up years of academic cruft that had accumulated, so merging
is not trivial.

Anyway, anyone interested in taking a look at this with me? I think the
place to start (i.e., where I'm starting) is to get the June-1996 alpha
release of Mariposa to compile on a current system (I'm running Linux
myself.) I've been doing a compare-and-contrast, staring at source code,
but I think I need a running system to decide how the parts fit together.

Then, plan what features to 'fold' into pgsql, and run a proposal past
this list, some time later in the 7.x series, perhaps in a couple of
months (you guys will probably be on 8.x by then!) Hopefully, not take-up
too much of the core developers time until we're talking integration.

Anyone else interested, I'm using the tarball from:

ftp://epoch.cs.berkeley.edu/pub/mariposa/src/alpha-1/mariposa-alpha-1.tar.gz

If this really takes off, I can host CVS of the mariposa and pgsql
sources, as well as web pages, mailing list, whatever. If it's just a
couple of us (or me all by myself ;-) we'll keep it simple.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Mon Feb 7 16:15:17 2000
Received: from hu.tm.ee (ppp731.tele2.ee [212.107.37.31])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA00983
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 16:14:25 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 9B8893A20; Mon, 7 Feb 2000 23:21:47 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389F376B.F4ADC7F0@tm.ee>
Date: Mon, 07 Feb 2000 23:21:47 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Timothy Dyck <Timothy_Dyck@zd.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] follow-up on PC Week Labs benchmark results
References: <8525687E.002554B3.00@mailer.zd.com>
<3.0.1.32.20000207072935.01086550@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

In particular, I'd like to compare IB 6 with PG 7.x and MySQL later this
year (I didn't benchmark MySQL this time because I ran out of time, but
would very much like to.)

Actually, this slipped by me the first time.

Why benchmark MySQL? It's not a real RDBMS, it doesn't even pretend
to support ACID semantics. Clearly it is going to be faster than
databases that do because supporting ACID semantics is expensive.

I remember some reports of it still being slower on more complex queries.

This would be comparing apples with oranges, meaningless.

Now, don't get me wrong, for many application spaces mySQL is fine. If
you're running a bboard system for overclockers, for instance, you probably
would sigh in relief if disaster struck and you lost all your data.

On the other hand, if you're running an e-commerce site losing data is
not cool and mySQL is not appropriate.

Rather than benchmark, it would seem more useful to educate your readers
about the meaning of ACID, and how to decide when you need it and when you
don't. That would seem far more important, because in my experience many
people don't understand that there is a real difference between a program
that executes a subset of SQL in a simple manner, and an RDBMS that
passes the ACID test and happens to be driven by SQL queries.

You probably can get ACID behaviour from MySQL by serializing at transaction
level ;)

------------
Hannu

From bouncefilter Mon Feb 7 16:24:20 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA02811
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 16:23:49 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA21093;
Mon, 7 Feb 2000 16:23:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002072123.QAA21093@candle.pha.pa.us>
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
In-Reply-To: <20000207151123.A25083@rice.edu> from "Ross J. Reedstrom" at "Feb
7, 2000 03:11:23 pm"
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Date: Mon, 7 Feb 2000 16:23:06 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

This is a Call For Hackers:

Some time ago, I floated a little discussion on this list about doing
some distributed database work with PostgreSQL. The project got back
burnered at work, but now has a timeline for needing a solution "this
summer." Recent discussions on this list about Postgres's historical
object roots got me back to the Berkeley db sites, and reminded me about
Mariposa, which is Stonebraker's take on distributed DBs.

http://s2k-ftp.cs.berkeley.edu:8000:8000/mariposa/

I have looked at the code. I have files that show all the diffs they
made to it and they have some new files. It was hard for me to see what
they were doing. Looks like they hacked up the executor and put in some
translation layer to talk to some databroker. It seems like an awfully
complicated way to do it. I would not bother getting it to run, but
figure out what they were trying to do, and why, and see how we can
implement it. My guess is that they had one central server for each
table, and you went to that server to get information.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 16:37:16 2000
Received: from hu.tm.ee (ppp731.tele2.ee [212.107.37.31])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA09290
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 16:36:55 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id C4A703991; Mon, 7 Feb 2000 23:44:14 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389F3CAE.9E4C249A@tm.ee>
Date: Mon, 07 Feb 2000 23:44:14 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
References: <20000207151123.A25083@rice.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ross J. Reedstrom" wrote:

Anyone else interested, I'm using the tarball from:

ftp://epoch.cs.berkeley.edu/pub/mariposa/src/alpha-1/mariposa-alpha-1.tar.gz

Is mariposa licence compatible with ours ?

------------------
Hannu

From bouncefilter Mon Feb 7 16:51:17 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA11442
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 16:50:41 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12Hw37-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Mon, 7 Feb 2000 15:50:25 -0600 (CST)
Date: Mon, 7 Feb 2000 15:50:25 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
Message-ID: <20000207155025.A25285@rice.edu>
References: <20000207151123.A25083@rice.edu>
<200002072123.QAA21093@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <200002072123.QAA21093@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Mon, Feb 07, 2000 at 04:23:06PM
-0500

On Mon, Feb 07, 2000 at 04:23:06PM -0500, Bruce Momjian wrote:

This is a Call For Hackers:

Some time ago, I floated a little discussion on this list about doing
some distributed database work with PostgreSQL. The project got back
burnered at work, but now has a timeline for needing a solution "this
summer." Recent discussions on this list about Postgres's historical
object roots got me back to the Berkeley db sites, and reminded me about
Mariposa, which is Stonebraker's take on distributed DBs.

http://s2k-ftp.cs.berkeley.edu:8000:8000/mariposa/

I have looked at the code. I have files that show all the diffs they
made to it and they have some new files. It was hard for me to see what
they were doing. Looks like they hacked up the executor and put in some
translation layer to talk to some databroker. It seems like an awfully
complicated way to do it. I would not bother getting it to run, but
figure out what they were trying to do, and why, and see how we can
implement it. My guess is that they had one central server for each
table, and you went to that server to get information.

Actually, this being an academic project, there's lots of design
documents about how it's _supposed_ to work. Stonebraker calls in an
'agoric' distributed database, as in agora, market. The various db
servers offer tables (or even specific views on tables) 'for sale', and
bid against/with each other to provide the data to clients requesting
it. The idea behind it is to us a micro-economic market model to do
your distributed optimizations for you, rather than have the DBAs decide
what tables go where, what tables need to be shadowed, etc. The win is
supposedly massive scaleability: they Cohera site talks about 10000s
of servers.

As I said, I've been doing the compare existing source code thing,
but thought working code might be more revealing, and give my project
manager something to see progress on ;-) Your right, though, that the
most productive way to go, in the long run, might be to reimplement what
they've described, in the current pgsql tree, using the Mariposa source
as an example implementation.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Mon Feb 7 16:56:16 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA12190
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 16:55:28 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA73584
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 17:55:26 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 7 Feb 2000 17:55:26 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Re: ipmeter-user: Ipmeter + MySql ?? (fwd)
Message-ID: <Pine.BSF.4.21.0002071754280.25537-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

We're getting there *muhahaha* Finally, a project *based* on PostgreSQL
first!! :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

---------- Forwarded message ----------
Date: Mon, 7 Feb 2000 22:04:14 +0100
From: Gunther Stammwitz <Gunther@Stammwitz.de>
Reply-To: ipmeter-user@ipmeter.com
To: ipmeter-user@ipmeter.com
Subject: Re: ipmeter-user: Ipmeter + MySql ??

<useless info deleted>

Gunther Stammwitz wrote:

Hello,

I've just downloaded the latest version of ipmeter, but I cant get it
working. It looks like Ipmeter requires PostgreSql.
The problem is: I'm running mysql. Is there any chance to get it
running with mysql or do I have to change my database.

I'm afraid you will have to switch to PostgreSQL, since IPmeter 1.0
requires
user-defined datatypes.

If yes: can i
run mysql + postgresql parallel ?

Other than performance, there's no reason why not.

Best Regards,

- Lorand

--
Computer: A device to speed and automate errors
Lorand Bruhacs, Internet Engineer
IP23 Gesellschaft fuer IP-basierte Dienstleistungen mbH

From bouncefilter Mon Feb 7 16:57:16 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA12408
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 16:56:53 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12Hw9L-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Mon, 7 Feb 2000 15:56:51 -0600 (CST)
Date: Mon, 7 Feb 2000 15:56:51 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Hannu Krosing <hannu@tm.ee>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
Message-ID: <20000207155651.B25285@rice.edu>
References: <20000207151123.A25083@rice.edu> <389F3CAE.9E4C249A@tm.ee>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <389F3CAE.9E4C249A@tm.ee>;
from hannu@tm.ee on Mon, Feb 07, 2000 at 11:44:14PM +0200

On Mon, Feb 07, 2000 at 11:44:14PM +0200, Hannu Krosing wrote:

"Ross J. Reedstrom" wrote:

Anyone else interested, I'm using the tarball from:

ftp://epoch.cs.berkeley.edu/pub/mariposa/src/alpha-1/mariposa-alpha-1.tar.gz

Is mariposa licence compatible with ours ?

It better be, it's the same license ;-) That is, Mariposa is a branch off
the Postgres95 tree. Actually, it's a good question: the PG95 license
would have let them put just about any license on Mariposa they wanted.

After running both COPYRIGHT files throught fmt, here's the diff output:

wallace$ diff COPYRIGHT COPYRIGHT.pgsql
1c1,2
< Mariposa Distributed Data Base Management System
---

PostgreSQL Data Base Management System (formerly known as Postgres,
then as Postgres95).

3c4
< Copyright (c) 1994-6 Regents of the University of California
---

Copyright (c) 1994-7 Regents of the University of California

21d21
<
wallace$

So, it is word for word the PostgreSQL license.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Mon Feb 7 16:58:16 2000
Received: from hu.tm.ee (ppp731.tele2.ee [212.107.37.31])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA12546
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 16:57:35 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id D18833991; Tue, 8 Feb 2000 00:04:52 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <389F4184.C968145F@tm.ee>
Date: Tue, 08 Feb 2000 00:04:52 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
References: <200002072123.QAA21093@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

This is a Call For Hackers:

Some time ago, I floated a little discussion on this list about doing
some distributed database work with PostgreSQL. The project got back
burnered at work, but now has a timeline for needing a solution "this
summer." Recent discussions on this list about Postgres's historical
object roots got me back to the Berkeley db sites, and reminded me about
Mariposa, which is Stonebraker's take on distributed DBs.

http://s2k-ftp.cs.berkeley.edu:8000:8000/mariposa/

It has a nice concept of simulating free market for distributed query
optimisation. Auctions, brokers and all ...

I have looked at the code. I have files that show all the diffs they
made to it and they have some new files. It was hard for me to see what
they were doing. Looks like they hacked up the executor and put in some
translation layer to talk to some databroker.

The broker was for determining where to get the data from - as each table
could be queried from several sites there had to be a mechanism for the
planner to figure out the cheapest (or fastest if "money" was not a problem)

It seems like an awfully
complicated way to do it. I would not bother getting it to run, but
figure out what they were trying to do, and why, and see how we can
implement it. My guess is that they had one central server for each
table, and you went to that server to get information.

They would not have needed the broker for such a simple scheme

IIRC they had no central table, but they doubled the length of oid and
made it to include the site id of the site that created the tuple.

It could be that they restricted changing a tuple to that site ?

The site to go for information was determined by an auction where each site
offered speed and cost for looking up the data. Usually the didn't also
quarantee the latest data, just the "best effort".

-------------------
Hannu

From bouncefilter Mon Feb 7 17:09:16 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA18223
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 17:08:32 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA24389;
Mon, 7 Feb 2000 17:08:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002072208.RAA24389@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: ipmeter-user: Ipmeter + MySql ?? (fwd)
In-Reply-To: <Pine.BSF.4.21.0002071754280.25537-100000@thelab.hub.org> from
The
Hermit Hacker at "Feb 7, 2000 05:55:26 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 7 Feb 2000 17:08:14 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

We're getting there *muhahaha* Finally, a project *based* on PostgreSQL
first!! :)

I'm afraid you will have to switch to PostgreSQL, since IPmeter 1.0
requires
user-defined datatypes.

Aw, gee, shame MySQL doesn't have them. :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 17:24:16 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA22438
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 17:23:34 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id OAA10718;
Mon, 7 Feb 2000 14:22:18 -0800 (PST)
Message-Id: <3.0.1.32.20000207141956.010a30d0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 14:19:56 -0800
To: Hannu Krosing <hannu@tm.ee>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
Cc: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <389F4184.C968145F@tm.ee>
References: <200002072123.QAA21093@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:04 AM 2/8/00 +0200, Hannu Krosing wrote:

The site to go for information was determined by an auction where each site
offered speed and cost for looking up the data. Usually the didn't also
quarantee the latest data, just the "best effort".

I just glanced at the website. They explicitly mention that they don't
require global synchronization, because it would slow down response time
for many things (with thousands of server, that sounds like an
understatement).

So, yes, it would appear they don't guarantee the latest data.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 17:58:16 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA38147
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 17:58:03 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12Hx6V-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Mon, 7 Feb 2000 16:57:59 -0600 (CST)
Date: Mon, 7 Feb 2000 16:57:59 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
Message-ID: <20000207165759.A25647@rice.edu>
References: <200002072123.QAA21093@candle.pha.pa.us> <389F4184.C968145F@tm.ee>
<3.0.1.32.20000207141956.010a30d0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <3.0.1.32.20000207141956.010a30d0@mail.pacifier.com>;
from dhogaza@pacifier.com on Mon, Feb 07, 2000 at 02:19:56PM -0800

Seems there was more than just going back to the Berkeley site that
reminded me of Mariposa. A principle new functionality in Mariposa is
the ability to 'fragment' a class, based on a user-defined partitioning
function. The example used is a widgets class, which is partitioned on
the 'location' field (i.e., the warehouse the widget is stored in)

CREATE TABLE widgets (
part_no int4,
location char16,
on_hand int4,
on_order int4,
commited int4
) PARTITION ON LOCATION USING btchar16cmp;

Then, the table is filled with tuples, all containing locations of either
'Miami' or 'New York'.

SELECT * from widgets;

works as expected.

Later, this table is fragmented:

SPLIT FRAGMENT widgets INTO widgets_mi, widgets_ny AT 'Miami';

Now, the original table widgets is _empty_: all the tuples with location <=
'Miami' go to widgets_mi, location > 'Miami' go to widgets_ny.

SELECT * from widgets;

Still returns all the tuples! So, this works sort of the way Chris Bitmead
has implemented subclasses: widgets_mi and widgets_ny are subclasses of
the widgets class, so selects return everything below. They differ in
that only PARTITIONed classes can be FRAGMENTed.

The distributed part comes in with the MOVE FRAGMENT command. This
transfers the 'master' copy of a table to the designated host, so future
access to that FRAGMENT will go over the network.

There's also a COPY FRAGMENT command, that sets up a local cache of a
fragment, with a periodic update time. These copies may be either
READONLY, or (default) READ/WRITE. Seems updates are timed only (simple
extension would be to implement write through behavior)

All this is coming from the Mariposa User's Manual, which is an extended
version of the Postgres95 User's Manual.

As to latest vs. best effort: One defines a BidCurve, who's dimensions are
Cost and Time. A flat curve should get you that latest data. And, since
the DataBroker and Bidder are both implemented as Tcl scripts, so it
would be possible to define a bid policy that only buys the latest data,
regardless of how long it's going to take.

Oh, BTW, yes that does put _two_ interpreted Tcl scripts on the execution
path for every query. Wonder what _that'll_ do for execution time. However,
it's like planning/optimization time, in that it's spent per query, rather
than per tuple.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

On Mon, Feb 07, 2000 at 02:19:56PM -0800, Don Baccus wrote:

At 12:04 AM 2/8/00 +0200, Hannu Krosing wrote:

The site to go for information was determined by an auction where each site
offered speed and cost for looking up the data. Usually the didn't also
quarantee the latest data, just the "best effort".

I just glanced at the website. They explicitly mention that they don't
require global synchronization, because it would slow down response time
for many things (with thousands of server, that sounds like an
understatement).

So, yes, it would appear they don't guarantee the latest data.

From bouncefilter Mon Feb 7 18:08:17 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA39303
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 18:07:34 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61341 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S151610AbQBGXGr>;
Tue, 8 Feb 2000 00:06:47 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12HxGh-0003ld-00
for pgsql-hackers@postgresql.org; Tue, 08 Feb 2000 00:08:31 +0100
Date: Tue, 8 Feb 2000 00:08:30 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: psql and libpq fixes
Message-ID: <Pine.LNX.4.21.0002072312340.6572-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

libpq should be back to normal (printing and all). Sorry once again for
the mess.

The psql quoting issue should be fixed as well. As is usual for
hand-crafted parsers, there's probably something I overlooked, so feel
free to bring that to my attention. I haven't done anything about the
echo options yet, although I'm leaning towards "-a".

While we're at it, there's a setting that causes psql to stop execution of
a script on an error (since usually the later commands will be depending
on the successful completion of earlier ones). I was wondering if that
should be the default if you use the -f option.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 7 18:08:22 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA39337
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 18:07:55 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61902 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S178237AbQBGXHQ>;
Tue, 8 Feb 2000 00:07:16 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12HxHH-0003m0-00; Tue, 08 Feb 2000 00:09:07 +0100
Date: Tue, 8 Feb 2000 00:09:07 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] PostgreSQL 7 RPMs coming soon
In-Reply-To: <389EFCF6.CC28F902@wgcr.org>
Message-ID: <Pine.LNX.4.21.0002072114160.6572-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-07, Lamar Owen mentioned:

1.) I want to move the actual database directory from /var/lib/pgsql to
/var/lib/pgsql/data -- this will give the ability to store backups and
other scratch data in /var/lib/pgsql without disturbing the main
database, in an FHS-compliant manner (the current regression tests AND
upgrade scripts are not in compliance with the FHS in terms of their
packaging, unfortunately -- I want to rectify this). This of course will
require sufficient documentation -- and I will provide functionality to
use an existing data structure in /var/lib/pgsql instead, until the user
moves it (new installations will default the initdb to
/var/lib/pgsql/data).

What exactly is FHS and what do they say? I am vaguely phantasizing about
doing a little work on the build process for the next release; is that
something that could be addressed?

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 7 18:18:17 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA41122
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 18:17:48 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA15797; Tue, 8 Feb 2000 10:17:15 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0ynluV;
Tue Feb 8 10:17:03 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA05871; Tue, 8 Feb 2000 10:17:02 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0nY.gA; Tue Feb 8 10:14:36 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA15867;
Tue, 8 Feb 2000 10:14:31 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA28516; Tue, 8 Feb 2000 10:13:57 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389F517C.BCFB586B@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 10:13:00 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
References: <Pine.BSF.4.05.10002070709530.29227-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vince Vielhaber wrote:

I have the new developer's globe online. Please check your BIOs and
let me know if there's anything that needs correcting. For those
without pictures, don't be so shy. Submit a picture - if you need to
have one scanned it can be arranged.

And before I forget.. Good job on the globe, Jan!

How much code do I have to contribute to get a marker on Sydney? :)

From bouncefilter Mon Feb 7 18:12:28 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA39982
for <pgsql-hackers@postgresql.org>; Mon, 7 Feb 2000 18:11:43 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61529 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S135221AbQBGXKz>;
Tue, 8 Feb 2000 00:10:55 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12HxL3-0003oC-00; Tue, 08 Feb 2000 00:13:01 +0100
Date: Tue, 8 Feb 2000 00:13:01 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Jeff MacDonald <jeff@pgsql.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Longer Column Names
In-Reply-To: <Pine.BSF.4.10.10002071419070.10395-100000@rage.hub.org>
Message-ID: <Pine.LNX.4.21.0002080011520.6572-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-07, Jeff MacDonald <jeff@pgsql.com> mentioned:

Ok sounds good then. got a few questions..

1: how to change this (i assume it's in the source, and not a
configure otpion)

in src/include/postgres_ext.h the macro NAMEDATALEN

2: will it require and initdb , backup, reinstall . or just
recompilie and let her rip.

Oh yeah, the whole deal. See also comments near the above location.

jeff

======================================================
Jeff MacDonald
jeff@pgsql.com irc: bignose on EFnet
======================================================

On Mon, 7 Feb 2000, Tom Lane wrote:

"Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com> writes:

Will Postgres suffer any major performance hits from
recomiling with support for column names over 32 chars.
ie: 64 chars.

I doubt it'd make a large difference, except that your system
tables would get bigger. Try it and let us know what you see...

regards, tom lane

************

************

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 7 18:16:20 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA40664
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 18:15:35 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id SAA01721;
Mon, 7 Feb 2000 18:15:34 -0500
Message-ID: <389F520F.C114611E@wgcr.org>
Date: Mon, 07 Feb 2000 18:15:28 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PostgreSQL 7 RPMs coming soon
References: <Pine.LNX.4.21.0002072114160.6572-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Eisentraut wrote:

database, in an FHS-compliant manner (the current regression tests AND
upgrade scripts are not in compliance with the FHS in terms of their

[snip]

What exactly is FHS and what do they say? I am vaguely phantasizing about
doing a little work on the build process for the next release; is that
something that could be addressed?

FHS 2.0 is the Filesystem Hierarchy Standard, successor to the Linux
FileSystem Standard (FSSTND). You may find the full document at
http://www.pathname.com/fhs/

Currently, in order to get PostgreSQL into RPM form requires a number of
mungifications -- the current prefix parameter is set to /usr, which
puts binaries and shared libs in the right place -- but everything else
is moved into place manually. It is a rather kludgy build script (ask
Thomas, he knows). To look at the build script (in RPM parlance, a
'spec file'), load up
http://www.ramifordistat.net/postgres/unpacked/non-beta/postgresql-6.5.3-3.spec
(one line; it'll probably wrap on your e-mail client).

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Mon Feb 7 18:18:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA41213
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 18:18:13 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA21592;
Mon, 7 Feb 2000 18:16:50 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-reply-to: <200002071735.MAA08496@candle.pha.pa.us>
References: <200002071735.MAA08496@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 07 Feb 2000 12:35:53 -0500"
Date: Mon, 07 Feb 2000 18:16:49 -0500
Message-ID: <21589.949965409@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I can't imagine how fsync could flush _only_ the file discriptor buffers
modified by the current process. It would have to affect all buffers
for the file descriptor.

Yeah, you're probably right. After thinking about it, I can't believe
that a disk block buffer inside the kernel has any record of which FD
it was written by (after all, it could have been dirtied through more
than one FD since it was last synced to disk). All it's got is a file
inode number and a block number within the file. Presumably fsync()
searches the buffer cache for blocks that match the FD's inode number
and schedules I/O for all the ones that are dirty.

So, I think we are safe if we can either keep that file descriptor open
until commit, or re-open it and fsync it on commit. That assume a
re-open is hitting the same file. My opinion is that we should just
fsync it on close and not worry about a reopen.

There's still the problem that your backend might never have opened the
relation file at all, still less done a write through its fd or vfd.
I think we would need to have a separate data structure saying "these
relations were dirtied in the current xact" that is not tied to fd's or
vfd's. Maybe the relcache would be a good place to keep such a flag.

Transaction commit would look like:

* scan buffer cache for dirty buffers, fwrite each one that belongs
to one of the relations I'm trying to commit;

* open and fsync each segment of each rel that I'm trying to commit
(or maybe just the dirtied segments, if we want to do the bookkeeping
at that level of detail);

* make pg_log entry;

* write and fsync pg_log.

fsync-on-close is probably a waste of cycles. The only way that would
matter is if someone else were doing a RENAME TABLE on the rel, thus
preventing you from reopening it. I think we could just put the
responsibility on the renamer to fsync the file while he's doing it
(in fact I think that's already in there, at least to the extent of
flushing the buffer cache).

regards, tom lane

From bouncefilter Mon Feb 7 18:21:17 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA41792
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 18:20:47 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA19029; Tue, 8 Feb 2000 10:20:15 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdsKCu._;
Tue Feb 8 10:19:47 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA11182; Tue, 8 Feb 2000 10:19:45 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0fMV4L; Tue Feb 8 10:18:39 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA20314;
Tue, 8 Feb 2000 10:18:38 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA28694; Tue, 8 Feb 2000 10:18:04 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389F5274.6FBBD39E@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 10:17:08 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Chris <chris@bitmead.com>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ONLY
References: <3.0.1.32.20000206221124.01084170@mail.pacifier.com>
<3.0.1.32.20000207071035.0108a2c0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

While all language standards have some bugs of this sort, the SQL standard
seems to be full of them.

Does SQL3 seem to be going anywhere, or has the world lost interest in
it?

From bouncefilter Mon Feb 7 18:25:17 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA42626
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 18:24:31 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id PAA03765;
Mon, 7 Feb 2000 15:24:03 -0800 (PST)
Message-Id: <3.0.1.32.20000207151801.010a6a90@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 15:18:01 -0800
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
In-Reply-To: <20000207165759.A25647@rice.edu>
References: <3.0.1.32.20000207141956.010a30d0@mail.pacifier.com>
<200002072123.QAA21093@candle.pha.pa.us> <389F4184.C968145F@tm.ee>
<3.0.1.32.20000207141956.010a30d0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:57 PM 2/7/00 -0600, Ross J. Reedstrom wrote:

CREATE TABLE widgets (
part_no int4,
location char16,
on_hand int4,
on_order int4,
commited int4
) PARTITION ON LOCATION USING btchar16cmp;

Oracle's partitioning is fixed, in other words once you choose a
condition to split on, you can't change it. In other words, in
your example:

Then, the table is filled with tuples, all containing locations of either
'Miami' or 'New York'.

After splitting the table into ">'Miami'" and "<='Miami" fragments,
I've been told that you can't (say) change it to ">'Boston'" and
have the proper rows move automatically.

In practice, partioning is often used to split tables on dates. You
might want to partion off your old tax data at the 7-yr old mark, and
each year as you do your taxes move the oldest tax data in your
"recent taxes" table split off to your "older taxes" table.

Apparently, Informix is smart enough to do this for you.

Since a couple of the people associated with the project are Informix
people, do you have any idea if Mariposa is able to do this?

SELECT * from widgets;

works as expected.

Later, this table is fragmented:

SPLIT FRAGMENT widgets INTO widgets_mi, widgets_ny AT 'Miami';

In other words some sort of "update the two tables AT <some new criteria>"

Whatever the answer to my question, Mariposa certainly looks interesting.
It's functionality that folks who do data warehousing really need.

Oh, BTW, yes that does put _two_ interpreted Tcl scripts on the execution
path for every query. Wonder what _that'll_ do for execution time. However,
it's like planning/optimization time, in that it's spent per query, rather
than per tuple.

Probably not as bad as you think, if they're simple and short. Once
someone has this up and running and integrated with PostgreSQL and
robust and reliable we can measure it and change to something else if
necessary :)

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 18:26:17 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id SAA42862
for <hackers@postgresql.org>; Mon, 7 Feb 2000 18:25:30 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 1897 invoked by uid 1001); 7 Feb 2000 23:25:35 -0000
Message-ID: <XFMail.000207182535.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.4.21.0002072141280.6572-100001@localhost.localdomain>
Date: Mon, 07 Feb 2000 18:25:35 -0500 (EST)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Peter Eisentraut <peter_e@gmx.net>, hackers@postgresql.org
Subject: Re: [HACKERS] New Globe

On 07-Feb-00 Peter Eisentraut wrote:

Bruce mentioned I should be on there, I hope y'all aren't disgruntled,
yet. ;)

I meant to mention that I was putting you there anyway and making up a
bio if necessary :)

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Mon Feb 7 18:32:17 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA44366
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 18:32:06 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA21656;
Mon, 7 Feb 2000 18:30:51 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
Subject: Re: [HACKERS] network_ops in 7.0 and pg_dump question
In-reply-to: <200002072052.PAA11461@candle.pha.pa.us>
References: <200002072052.PAA11461@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 07 Feb 2000 15:52:01 -0500"
Date: Mon, 07 Feb 2000 18:30:51 -0500
Message-ID: <21653.949966251@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Now, how to convert these? Not supplying the ops works fine, but
pg_dump supplies the ops. Maybe in gram.y, if they supply network_ops,
we should just remove that from being passed to the backend for a few
releases. Comments?

Ugly, but probably the best stopgap for backwards compatibility ...
at least I can't think of a better answer, since we have no way to
change what 6.5 pg_dump will dump.

You're only going to suppress "network_ops" if it appears in the
ops position of a CREATE INDEX, right? Don't want to stop people
from using the name for fields and so on.

regards, tom lane

From bouncefilter Mon Feb 7 18:37:17 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA45370
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 18:36:28 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA04734; Tue, 8 Feb 2000 10:35:55 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdnvdnv_;
Tue Feb 8 10:35:40 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA05279; Tue, 8 Feb 2000 10:35:38 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdOKWrH_; Tue Feb 8 10:34:32 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA05926;
Tue, 8 Feb 2000 10:34:22 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA29174; Tue, 8 Feb 2000 10:33:47 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389F5623.EB540669@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 10:32:51 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Alfred Perlstein <bright@wintelcom.net>, Tom Lane <tgl@sss.pgh.pa.us>,
Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: fsync alternatives (was: Re: [HACKERS] TODO item)
References: <200002071827.NAA01183@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

So, I think we are safe if we can either keep that file descriptor open
until commit, or re-open it and fsync it on commit. That assume a
re-open is hitting the same file. My opinion is that we should just
fsync it on close and not worry about a reopen.

I'm pretty sure that the standard is that a close on a file _should_
fsync it.

This is not true. close flushes the user buffers to kernel buffers. It
does not force to physical disk in all cases, I think.

fclose flushes user buffers to kernel buffers. close only frees the file
descriptor for re-use.

From bouncefilter Mon Feb 7 18:35:17 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA45136
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 18:35:13 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA21703;
Mon, 7 Feb 2000 18:34:59 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"Tatsuo Ishii" <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-reply-to: <000001bf71c4$79e14b80$2801007e@tpf.co.jp>
References: <000001bf71c4$79e14b80$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Tue, 08 Feb 2000 08:38:46 +0900"
Date: Mon, 07 Feb 2000 18:34:59 -0500
Message-ID: <21700.949966499@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

Is it still valuable to solve this item in current spec ?

I'd be inclined to forget about it for now, and see what happens
with WAL. It looks like a fair amount of work for a problem that
will go away anyway in a release or so...

regards, tom lane

From bouncefilter Mon Feb 7 18:37:17 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA45458
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 18:37:06 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA21736;
Mon, 7 Feb 2000 18:36:53 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
Subject: Re: [HACKERS] network_ops in 7.0 and pg_dump question
In-reply-to: <200002072052.PAA11461@candle.pha.pa.us>
References: <200002072052.PAA11461@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 07 Feb 2000 15:52:01 -0500"
Date: Mon, 07 Feb 2000 18:36:53 -0500
Message-ID: <21733.949966613@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Now, how to convert these? Not supplying the ops works fine, but
pg_dump supplies the ops. Maybe in gram.y, if they supply network_ops,
we should just remove that from being passed to the backend for a few
releases. Comments?

Actually, rather than hacking gram.y, it seems like it would be cleaner
to put the kluge in whatever part of the parser looks up the ops name.

Of course a kluge is a kluge no matter what...

regards, tom lane

From bouncefilter Mon Feb 7 18:33:18 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA44595
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 18:33:02 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id IAA13446; Tue, 08 Feb 2000 08:32:48 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Tatsuo Ishii" <t-ishii@sra.co.jp>, <pgsql-hackers@postgreSQL.org>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Subject: RE: [HACKERS] TODO item
Date: Tue, 8 Feb 2000 08:38:46 +0900
Message-ID: <000001bf71c4$79e14b80$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <200002071735.MAA08496@candle.pha.pa.us>

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Don't tell me we fsync on every buffer write, and not just at
transaction commit? That is terrible.

If you don't have -F set, yup. Why did you think fsync mode was
so slow?

What if we set a flag on the file descriptor stating we dirtied/wrote
one of its buffers during the transaction, and cycle through the file
descriptors on buffer commit and fsync all involved in the

transaction.

That's exactly what Tatsuo was describing, I believe. I think Hiroshi
has pointed out a serious problem that would make it unreliable when
multiple backends are running: if some *other* backend fwrites the page
instead of your backend, and it doesn't fsync until *its* transaction is
done (possibly long after yours), then you lose the ordering guarantee
that is the point of the whole exercise...

OK, I understand now. You are saying if my backend dirties a buffer,
but another backend does the write, would my backend fsync() that buffer
that the other backend wrote.

I can't imagine how fsync could flush _only_ the file discriptor buffers
modified by the current process. It would have to affect all buffers
for the file descriptor.

BSDI says:

Fsync() causes all modified data and attributes of fd to be
moved to a
permanent storage device. This normally results in all
in-core modified
copies of buffers for the associated file to be written to a disk.

Looking at the BSDI kernel, there is a user-mode file descriptor table,
which maps to a kernel file descriptor table. This table can be shared,
so a file descriptor opened multiple times, like in a fork() call. The
kernel table maps to an actual file inode/vnode that maps to a file.
The only thing that is kept in the file descriptor table is the current
offset in the file (struct file in BSD). There is no mapping of who
wrote which blocks.

In fact, I would suggest that any kernel implementation that could track
such things would be pretty broken. I can imagine some cases the use of
that mapping of blocks to file descriptors would cause compatibility
problems. Those buffers have to be shared by all processes.

So, I think we are safe if we can either keep that file descriptor open
until commit, or re-open it and fsync it on commit. That assume a
re-open is hitting the same file. My opinion is that we should just
fsync it on close and not worry about a reopen.

I asked about this question 4 months ago but got no answer.
Obviouly this needs not only md/fd stuff changes but also bufmgr
changes. Keeping dirtied list of segments of each backend seems
to work. But I'm afraid of other oversights.

The problem is that this feature is very difficult to verify.
In addtion WAL would solve this item naturally.

Is it still valuable to solve this item in current spec ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Feb 7 19:02:17 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA53146
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:01:33 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA27846;
Mon, 7 Feb 2000 18:48:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002072348.SAA27846@candle.pha.pa.us>
Subject: Re: [HACKERS] New Globe
In-Reply-To: <389F517C.BCFB586B@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 8, 2000 10:13:00 am"
To: chris@bitmead.com
Date: Mon, 7 Feb 2000 18:48:28 -0500 (EST)
CC: Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Vince Vielhaber wrote:

I have the new developer's globe online. Please check your BIOs and
let me know if there's anything that needs correcting. For those
without pictures, don't be so shy. Submit a picture - if you need to
have one scanned it can be arranged.

And before I forget.. Good job on the globe, Jan!

How much code do I have to contribute to get a marker on Sydney? :)

That's a good question. We normally give "pins" out to people who have
contributed a code over a significant period of time. For example,
Peter Eisentraut is almost ready for a pin. We would normally wait for
his feature patches to be released, and then wait a few months to see if
he is still around. We look for people who we feel are in this for the
long haul.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 19:00:17 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA52946
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:00:05 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA28607 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 10:59:32 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdsb.rv_;
Tue Feb 8 10:59:00 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA10404 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 10:58:59 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0dgT3m; Tue Feb 8 10:58:14 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA28241
for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 10:58:13 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA29801
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 10:57:36 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389F5BB7.9B7C3EEC@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 10:56:39 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ONLY
References: <3.0.1.32.20000207071035.0108a2c0@mail.pacifier.com>
<3.0.1.32.20000207111939.01095d10@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

*sigh* I hate it when people do this. YOU try writing a standard with that
much information such that nobody will come back to you and say "you left
such-and-such undefined".

Like someone else said, if they at least supplied a compilable gram.y
we'd
at least have a definitive syntax, and could restrain ourselves to
arguing
about the meanings.

From bouncefilter Mon Feb 7 19:05:17 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA53554
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:04:55 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA28209;
Mon, 7 Feb 2000 19:02:19 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080002.TAA28209@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <21589.949965409@sss.pgh.pa.us> from Tom Lane at "Feb 7,
2000 06:16:49 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 7 Feb 2000 19:02:19 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

So, I think we are safe if we can either keep that file descriptor open
until commit, or re-open it and fsync it on commit. That assume a
re-open is hitting the same file. My opinion is that we should just
fsync it on close and not worry about a reopen.

There's still the problem that your backend might never have opened the
relation file at all, still less done a write through its fd or vfd.
I think we would need to have a separate data structure saying "these
relations were dirtied in the current xact" that is not tied to fd's or
vfd's. Maybe the relcache would be a good place to keep such a flag.

Transaction commit would look like:

* scan buffer cache for dirty buffers, fwrite each one that belongs
to one of the relations I'm trying to commit;

* open and fsync each segment of each rel that I'm trying to commit
(or maybe just the dirtied segments, if we want to do the bookkeeping
at that level of detail);

By fsync'ing on close, we can not worry about file descriptors that were
forced out of the file descriptor cache during the transaction.

If we dirty a buffer, we have to mark the buffer as dirty, and the file
descriptor associated with that buffer needing fsync. If someone else
writes and removes that buffer from the cache before we get to commit
it, the file descriptor flag will tell us the file descriptor needs
fsync.

We have to:

write our dirty buffers
fsync all file descriptors marked as "written" during our transaction
fsync all file descriptors on close when being cycled out of fd cache
(fd close has to write dirty buffers before fsync)

So we have three states for a write:

still in dirty buffer
file descriptor marked as dirty/need fsync
file descriptor removed from cache, fsync'ed on close

Seems this covers all the cases.

* make pg_log entry;

* write and fsync pg_log.

Yes.

fsync-on-close is probably a waste of cycles. The only way that would
matter is if someone else were doing a RENAME TABLE on the rel, thus
preventing you from reopening it. I think we could just put the
responsibility on the renamer to fsync the file while he's doing it
(in fact I think that's already in there, at least to the extent of
flushing the buffer cache).

I hadn't thought of that case. I was thinking of file descriptor cache
removal, or don't they get removed if they are in use? If not, you can
skip my close examples.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 19:03:17 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA53319
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:03:14 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA28216;
Mon, 7 Feb 2000 19:02:52 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080002.TAA28216@candle.pha.pa.us>
Subject: Re: [HACKERS] New Globe
In-Reply-To: <XFMail.000207182535.vev@michvhf.com> from Vince Vielhaber at
"Feb
7, 2000 06:25:35 pm"
To: Vince Vielhaber <vev@michvhf.com>
Date: Mon, 7 Feb 2000 19:02:52 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On 07-Feb-00 Peter Eisentraut wrote:

Bruce mentioned I should be on there, I hope y'all aren't disgruntled,
yet. ;)

I meant to mention that I was putting you there anyway and making up a
bio if necessary :)

Great.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 19:07:17 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA53712
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:06:18 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA28228;
Mon, 7 Feb 2000 19:03:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080003.TAA28228@candle.pha.pa.us>
Subject: Re: [HACKERS] network_ops in 7.0 and pg_dump question
In-Reply-To: <21653.949966251@sss.pgh.pa.us> from Tom Lane at "Feb 7,
2000 06:30:51 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 7 Feb 2000 19:03:29 -0500 (EST)
CC: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Now, how to convert these? Not supplying the ops works fine, but
pg_dump supplies the ops. Maybe in gram.y, if they supply network_ops,
we should just remove that from being passed to the backend for a few
releases. Comments?

Ugly, but probably the best stopgap for backwards compatibility ...
at least I can't think of a better answer, since we have no way to
change what 6.5 pg_dump will dump.

You're only going to suppress "network_ops" if it appears in the
ops position of a CREATE INDEX, right? Don't want to stop people
from using the name for fields and so on.

No, just at that part in the grammar.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 19:08:17 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA53903
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:07:46 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA28242;
Mon, 7 Feb 2000 19:05:01 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080005.TAA28242@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <21700.949966499@sss.pgh.pa.us> from Tom Lane at "Feb 7,
2000 06:34:59 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 7 Feb 2000 19:05:01 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

Is it still valuable to solve this item in current spec ?

I'd be inclined to forget about it for now, and see what happens
with WAL. It looks like a fair amount of work for a problem that
will go away anyway in a release or so...

But is seems Tatsuo is pretty close to it. I personally would like to
see it in 7.0. Even with WAL, we may decide to allow non-WAL mode, and
if so, this code would still be useful.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 19:08:17 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA53931
for <hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:08:12 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA28249;
Mon, 7 Feb 2000 19:05:34 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080005.TAA28249@candle.pha.pa.us>
Subject: Re: [HACKERS] network_ops in 7.0 and pg_dump question
In-Reply-To: <21733.949966613@sss.pgh.pa.us> from Tom Lane at "Feb 7,
2000 06:36:53 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 7 Feb 2000 19:05:33 -0500 (EST)
CC: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Now, how to convert these? Not supplying the ops works fine, but
pg_dump supplies the ops. Maybe in gram.y, if they supply network_ops,
we should just remove that from being passed to the backend for a few
releases. Comments?

Actually, rather than hacking gram.y, it seems like it would be cleaner
to put the kluge in whatever part of the parser looks up the ops name.

Of course a kluge is a kluge no matter what...

I like it in gram.y because it is more visible there and easier to
remove later.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 19:08:20 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA53906
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:07:47 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA28292;
Mon, 7 Feb 2000 19:07:33 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080007.TAA28292@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <000001bf71c4$79e14b80$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Feb 8, 2000 08:38:46 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 7 Feb 2000 19:07:33 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org,
Tom Lane <tgl@sss.pgh.pa.us>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

So, I think we are safe if we can either keep that file descriptor open
until commit, or re-open it and fsync it on commit. That assume a
re-open is hitting the same file. My opinion is that we should just
fsync it on close and not worry about a reopen.

I asked about this question 4 months ago but got no answer.
Obviouly this needs not only md/fd stuff changes but also bufmgr
changes. Keeping dirtied list of segments of each backend seems
to work. But I'm afraid of other oversights.

I don't think so. We can just mark file descriptors as needing fsync().
By doing that, we can spin through the buffer cache for each need_fsync
file desciptor, perform any writes needed, and fsync the descriptor.
Seems like little redesign needed, except for adding the need_fsync
flag. Should be no more than about 20 lines.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 19:47:21 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA64648
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:46:49 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA22507;
Mon, 7 Feb 2000 19:46:30 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and libpq fixes
In-reply-to: <Pine.LNX.4.21.0002072312340.6572-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002072312340.6572-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Tue, 08 Feb 2000 00:08:30 +0100"
Date: Mon, 07 Feb 2000 19:46:30 -0500
Message-ID: <22504.949970790@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

While we're at it, there's a setting that causes psql to stop execution of
a script on an error (since usually the later commands will be depending
on the successful completion of earlier ones). I was wondering if that
should be the default if you use the -f option.

Sounds useful, but you can't make it the default without breaking existing
scripts. Trivial example is this common idiom:
DROP TABLE t1; -- in case it already exists
CREATE TABLE t1;
COPY ...

In general, an existing script is not going to be written with the idea
that psql will cut it off at the knees for provoking an error. If the
author *does* want all the rest of the commands to be skipped on error,
he'll just have written BEGIN and END around the whole script.

regards, tom lane

From bouncefilter Mon Feb 7 20:00:18 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA65972
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 19:59:25 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA13526; Tue, 08 Feb 2000 09:58:33 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Tatsuo Ishii" <t-ishii@sra.co.jp>, <pgsql-hackers@postgreSQL.org>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Subject: RE: [HACKERS] TODO item
Date: Tue, 8 Feb 2000 10:04:31 +0900
Message-ID: <000101bf71d0$74df7100$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <200002080002.TAA28209@candle.pha.pa.us>

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian

So, I think we are safe if we can either keep that file

descriptor open

until commit, or re-open it and fsync it on commit. That assume a
re-open is hitting the same file. My opinion is that we should just
fsync it on close and not worry about a reopen.

There's still the problem that your backend might never have opened the
relation file at all, still less done a write through its fd or vfd.
I think we would need to have a separate data structure saying "these
relations were dirtied in the current xact" that is not tied to fd's or
vfd's. Maybe the relcache would be a good place to keep such a flag.

Transaction commit would look like:

* scan buffer cache for dirty buffers, fwrite each one that belongs
to one of the relations I'm trying to commit;

* open and fsync each segment of each rel that I'm trying to commit
(or maybe just the dirtied segments, if we want to do the bookkeeping
at that level of detail);

By fsync'ing on close, we can not worry about file descriptors that were
forced out of the file descriptor cache during the transaction.

If we dirty a buffer, we have to mark the buffer as dirty, and the file
descriptor associated with that buffer needing fsync. If someone else

What is the file descriptors associated with buffers ?
Would you call heap_open() etc each time when a buffer is about
to be dirtied?

I don't object to you strongly but I ask again.

There's already -F option for speeding up.
Who would want non-WAL mode with strict reliabilty after WAL
is implemented ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Feb 7 20:10:18 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA67356
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 20:09:43 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id RAA17870;
Mon, 7 Feb 2000 17:08:27 -0800 (PST)
Message-Id: <3.0.1.32.20000207170611.01096db0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 17:06:11 -0800
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>,
"Bruce Momjian" <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: RE: [HACKERS] TODO item
Cc: "Tatsuo Ishii" <t-ishii@sra.co.jp>, <pgsql-hackers@postgreSQL.org>,
"Tom Lane" <tgl@sss.pgh.pa.us>
In-Reply-To: <000101bf71d0$74df7100$2801007e@tpf.co.jp>
References: <200002080002.TAA28209@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:04 AM 2/8/00 +0900, Hiroshi Inoue wrote:

There's already -F option for speeding up.
Who would want non-WAL mode with strict reliabilty after WAL
is implemented ?

Exactly. I suspect WAL will actually run faster, or at least
will have that potential when its existence is fully exploited,
than non-WAL non -F.

And it seems to me that touching something as crucial as
disk management in a fundamental way one week before the
release of a hopefully solid beta is pushing things a bit.

But, then again, I'm the resident paranoid conservative, I
guess.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Feb 7 20:52:27 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA76622
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 20:51:33 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA22602;
Tue, 8 Feb 2000 10:51:27 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA20608;
Tue, 8 Feb 2000 10:51:27 +0900
To: peter_e@gmx.net
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_ctl man page
In-Reply-To: Your message of "Mon, 7 Feb 2000 20:53:35 +0100 (CET)"
<Pine.LNX.4.21.0002072051550.6572-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002072051550.6572-100000@localhost.localdomain>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000208105126W.t-ishii@sra.co.jp>
Date: Tue, 08 Feb 2000 10:51:26 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 20

I got grammer corrections from Ed Loehr. Also, I modified some option
flag styles according to Thomas's suggestion. Thanks for those who
gave me suggestions.

Thomas, I have changed -m <opts> style to -smart, -fast... style. I
hope this was what you meant. Also, please note that I still stick
with smart/fast/immediate since I have been waiting for Vadim's
opinion...

Ugh, that's not a compliant option style. What was wrong with -m
<opt>? How about --smart, etc.? But 'single dash, multiple letters' is
evil.

Oh, I'm confused now. Thomas, could you let me know what you think?
Lamar is trying to use pg_ctl for his RPM project, and we need
decision on that.
--
Tatsuo Ishii

From bouncefilter Mon Feb 7 22:01:19 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA91498
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 22:01:05 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA27057;
Mon, 7 Feb 2000 22:00:35 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"Tatsuo Ishii" <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-reply-to: <000101bf71d0$74df7100$2801007e@tpf.co.jp>
References: <000101bf71d0$74df7100$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Tue, 08 Feb 2000 10:04:31 +0900"
Date: Mon, 07 Feb 2000 22:00:35 -0500
Message-ID: <27054.949978835@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

If we dirty a buffer, we have to mark the buffer as dirty, and the file
descriptor associated with that buffer needing fsync. If someone else

What is the file descriptors associated with buffers ?

I was about to make exactly that remark. A shared buffer doesn't have
an "associated file descriptor", certainly not one that's valid across
multiple backends.

AFAICS no bookkeeping based on file descriptors (either kernel FDs
or vfds) can possibly work correctly in the multiple-backend case.
We *have to* do the bookkeeping on a relation basis, and that
potentially means (re)opening the relation's file at xact commit
in order to do an fsync. There is no value in having one backend
fsync an FD before closing the FD, because that does not take
account of what other backends may have done or do later with that
same file through their own FDs for it. If we do not do an fsync
at end of transaction, we cannot be sure that writes initiated by
*other* backends will be complete.

There's already -F option for speeding up.
Who would want non-WAL mode with strict reliabilty after WAL
is implemented ?

Yes. We have a better solution in the pipeline, so ISTM it's not
worth expending a lot of effort on a stopgap.

regards, tom lane

From bouncefilter Mon Feb 7 22:01:19 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA91479
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 22:00:53 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA05584;
Mon, 7 Feb 2000 22:00:40 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080300.WAA05584@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <000101bf71d0$74df7100$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Feb 8, 2000 10:04:31 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 7 Feb 2000 22:00:40 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org,
Tom Lane <tgl@sss.pgh.pa.us>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

* open and fsync each segment of each rel that I'm trying to commit
(or maybe just the dirtied segments, if we want to do the bookkeeping
at that level of detail);

By fsync'ing on close, we can not worry about file descriptors that were
forced out of the file descriptor cache during the transaction.

If we dirty a buffer, we have to mark the buffer as dirty, and the file
descriptor associated with that buffer needing fsync. If someone else

What is the file descriptors associated with buffers ?
Would you call heap_open() etc each time when a buffer is about
to be dirtied?

WriteBuffer -> FlushBuffer to flush buffer. Buffer can be either marked
dirty or written/fsync to disk.

If written/fsync, smgr_flush -> mdflush -> _mdfd_getseg gets MdfdVec
structure of file descriptor.

When doing flush here, mark MdfdVec structure new element needs_fsync to
true. Don't do fsync yet.

If just marked dirty, also mark MdfdVec.needs_fsync as true.

Do we currently all write dirty buffers on transaction commit? We
certainly must already do that in fsync mode.

On commit, run through virtial file descriptor table and do fsyncs on
file descriptors. No need to find the buffers attached to file
descriptors. They have already been written by other code. They just
need fsync.

There's already -F option for speeding up.
Who would want non-WAL mode with strict reliabilty after WAL
is implemented ?

Let's see what Vadim says. Seems like a nice performance boost and 7.0
could be 6 months away. If we didn't ship with fsync enabled, I
wouldn't care. Also, Vadim has a new job, so we really can't be sure
about WAL in 7.1.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Feb 7 22:27:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA95841
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 22:27:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA27679;
Mon, 7 Feb 2000 22:26:19 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-reply-to: <200002080007.TAA28292@candle.pha.pa.us>
References: <200002080007.TAA28292@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 07 Feb 2000 19:07:33 -0500"
Date: Mon, 07 Feb 2000 22:26:19 -0500
Message-ID: <27676.949980379@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Seems like little redesign needed, except for adding the need_fsync
flag. Should be no more than about 20 lines.

If you think this is a twenty line fix, take a deep breath and back
away slowly. You have not understood the problem.

The problem comes in when *some other* backend has written out a
shared buffer that contained a change that our backend made as part
of the transaction that it now wants to commit. Without immediate-
fsync-on-write (the current solution), there is no guarantee that the
other backend will do an fsync any time soon; it might be busy in
a very long-running transaction. Our backend must fsync that file,
and it must do so after the other backend flushed the buffer. But
there is no existing data structure that our backend can use to
discover that it must do this. The shared buffer cannot record it;
it might belong to some other file entirely by now (and in any case,
the shared buffer is noplace to record per-transaction status info).
Our backend cannot use either FD or VFD to record it, since it might
never have opened the relation file at all, and certainly might have
closed it again (and recycled the FD or VFD) before the other backend
flushed the shared buffer. The relcache might possibly work as a
place to record the need for fsync --- but I am concerned about the
relcache's willingness to drop entries if they are not currently
heap_open'd; also, md/fd don't currently use the relcache at all.

This is not a trivial change.

regards, tom lane

From bouncefilter Mon Feb 7 22:30:26 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA96333
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 22:29:49 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA00577 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 14:29:16 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd08L24u;
Tue Feb 8 14:28:56 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA12166 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 14:28:54 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd12ymA_; Tue Feb 8 14:28:20 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA28952
for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 14:28:19 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
OAA04355
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 14:27:44 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389F8CF8.F2E54991@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 14:26:48 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: ExecInitAppend
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In ExecInitAppend it initialises all the subplans...

for (i = 0; i < nplans; i++)
{
...
appendstate->as_whichplan = i;
exec_append_initialize_next(node);
..
}

And then at the end of the function, it initialises the first plan
again...

appendstate->as_whichplan = 0;
exec_append_initialize_next(node);

return TRUE;

Is this code correct? Should the first plan really be initialised twice?

From bouncefilter Mon Feb 7 22:23:20 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA94983
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 22:22:47 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id MAA13644; Tue, 08 Feb 2000 12:21:54 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Tatsuo Ishii" <t-ishii@sra.co.jp>, <pgsql-hackers@postgreSQL.org>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Subject: RE: [HACKERS] TODO item
Date: Tue, 8 Feb 2000 12:27:54 +0900
Message-ID: <000201bf71e4$7c79c320$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <200002080300.WAA05584@candle.pha.pa.us>

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]

wouldn't care. Also, Vadim has a new job, so we really can't be sure
about WAL in 7.1.

Oops,it's a big problem.
If so,we may have to do something about this item.
However it seems too late for 7.0.
This isn't a kind of item which beta could verify.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Feb 7 22:51:20 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA98804
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 22:51:04 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA19699 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 14:50:32 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdEtFA__;
Tue Feb 8 14:50:05 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA10656 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 14:50:04 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0EhIeh; Tue Feb 8 14:49:07 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA17156
for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 14:49:06 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
OAA04873
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 14:48:31 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389F91D7.E52113F9@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 14:47:35 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: UPDATE on subclass
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Been doing more tracing...

The problem with UPDATE on inheritance hierarchies is that when it gets
down into ExecSeqScan, the value of...

node->scanstate->css_currentScanDesc->rs_rd->rd_id

is not equal to the value of...

node->plan.state->es_result_relation_info->ri_RelationDesc->rd_id

On the first scan, the former is equal to the relation for the base
class
and the latter is equal to the relation for the subclass.

Any thoughts anyone?

From bouncefilter Mon Feb 7 23:16:20 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA05014
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 23:15:28 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA10588 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 15:14:56 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdKQcsK_;
Tue Feb 8 15:14:42 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA11653 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 15:14:41 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0wul.4; Tue Feb 8 15:13:43 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA07717
for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 15:13:42 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
PAA05446
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 15:13:07 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389F979B.51A62C09@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 15:12:11 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] UPDATE on subclass
References: <389F91D7.E52113F9@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hmm. In exec_append_initialize_next

nth(whichplan, rtable)
refers to the subclass and ...
nth(whichplan, appendstate->as_result_relation_info_list);
refers to the baseclass.

Is there something that is constructing one of these
structures in reverse order?

Chris Bitmead wrote:

Been doing more tracing...

The problem with UPDATE on inheritance hierarchies is that when it gets
down into ExecSeqScan, the value of...

node->scanstate->css_currentScanDesc->rs_rd->rd_id

is not equal to the value of...

node->plan.state->es_result_relation_info->ri_RelationDesc->rd_id

On the first scan, the former is equal to the relation for the base
class
and the latter is equal to the relation for the subclass.

Any thoughts anyone?

************

From bouncefilter Mon Feb 7 23:28:22 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA06870
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 23:27:27 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA20711 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 15:26:55 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdzVARn_;
Tue Feb 8 15:26:32 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA27000 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 15:26:31 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd5If9f_; Tue Feb 8 15:25:45 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA18070
for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 15:25:45 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
PAA05716
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 15:25:10 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389F9A6E.CD58046B@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 15:24:14 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Is this it?
References: <389F91D7.E52113F9@nimrod.itg.telecom.com.au>
<389F979B.51A62C09@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In ExecInitAppend it has a loop...

foreach(rtentryP, rtable)
{

resultList = lcons(rri, resultList);
}

appendstate->as_result_relation_info_list = resultList;

If I'm not mistaken this will generate the as_result_relation_info_list
in the reverse order to the rtentry list, which is wrong... right?

From bouncefilter Mon Feb 7 23:28:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA06883
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 23:27:39 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA27995;
Mon, 7 Feb 2000 23:27:11 -0500 (EST)
To: chris@bitmead.com
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ExecInitAppend
In-reply-to: <389F8CF8.F2E54991@nimrod.itg.telecom.com.au>
References: <389F8CF8.F2E54991@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Tue, 08 Feb 2000 14:26:48 +1100"
Date: Mon, 07 Feb 2000 23:27:10 -0500
Message-ID: <27992.949984030@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

In ExecInitAppend it initialises all the subplans...
And then at the end of the function, it initialises the first plan
again...
Is this code correct? Should the first plan really be initialised twice?

Probably not --- I imagine that's wasting memory, or worse. Do things
still work if you remove the extra initialize call?

regards, tom lane

From bouncefilter Mon Feb 7 23:51:21 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA11546
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 23:50:21 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA09993; Tue, 8 Feb 2000 15:49:50 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdJDvVp_;
Tue Feb 8 15:49:34 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA25159; Tue, 8 Feb 2000 15:49:33 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0rcVgL; Tue Feb 8 15:48:29 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA06166;
Tue, 8 Feb 2000 15:48:28 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
PAA06238; Tue, 8 Feb 2000 15:47:49 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389F9FBC.FB352F00@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 15:46:52 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ExecInitAppend
References: <389F8CF8.F2E54991@nimrod.itg.telecom.com.au>
<27992.949984030@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

In ExecInitAppend it initialises all the subplans...
And then at the end of the function, it initialises the first plan
again...
Is this code correct? Should the first plan really be initialised twice?

Probably not --- I imagine that's wasting memory, or worse. Do things
still work if you remove the extra initialize call?

This code looks ugly because it sets appendstate->as_whichplan so that
exec_append_initialise_next knows which plan it's supposed to initialise
-
yucky side effect.

I suspect it will stop working if the last call is removed because it
*may*
be relying on the first plan to be initialised last, so that the estate
variables are initialised to the first plan. It may work if the plans
are initialised in reverse order, but the right way is probably to
reorganise the code.

From bouncefilter Mon Feb 7 23:55:23 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA12248
for <pgsql-hackers@postgreSQL.org>; Mon, 7 Feb 2000 23:55:06 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA13837 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 15:54:34 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdpMrrW_;
Tue Feb 8 15:54:15 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA00741 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 15:54:14 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0KhnX2; Tue Feb 8 15:53:36 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA10292
for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 15:53:35 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
PAA06360
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 15:53:00 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389FA0F5.34427139@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 15:52:05 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Is this it?
References: <389F91D7.E52113F9@nimrod.itg.telecom.com.au>
<389F979B.51A62C09@nimrod.itg.telecom.com.au>
<389F9A6E.CD58046B@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Bitmead wrote:

In ExecInitAppend it has a loop...

foreach(rtentryP, rtable)
{

resultList = lcons(rri, resultList);
}

appendstate->as_result_relation_info_list = resultList;

This seems to be the problem. I'm going to change the above line to...

appendstate->as_result_relation_info_list = lreverse(resultList);

After I do this, UPDATE and DELETE start working for me on subclasses.

I'll prepare a full patch for inclusion in 7.1 (Unless you want it for
7.0 :-).

From bouncefilter Tue Feb 8 00:16:21 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA16848
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 00:15:35 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA17034;
Mon, 7 Feb 2000 21:14:25 -0800 (PST)
Message-Id: <3.0.1.32.20000207205946.010a6610@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 20:59:46 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, "Hiroshi Inoue" <Inoue@tpf.co.jp>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] TODO item
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"Tatsuo Ishii" <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
In-Reply-To: <27054.949978835@sss.pgh.pa.us>
References: <000101bf71d0$74df7100$2801007e@tpf.co.jp>
<000101bf71d0$74df7100$2801007e@tpf.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:00 PM 2/7/00 -0500, Tom Lane wrote:

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

There's already -F option for speeding up.
Who would want non-WAL mode with strict reliabilty after WAL
is implemented ?

Yes. We have a better solution in the pipeline, so ISTM it's not
worth expending a lot of effort on a stopgap.

Thanks to both of you.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Tue Feb 8 00:07:21 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA15053
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 00:06:32 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA22472 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 16:06:00 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0oawB3;
Tue Feb 8 16:05:37 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA13689 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 16:05:37 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdxU3Sr_; Tue Feb 8 16:05:09 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA18894
for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 16:05:08 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA06635
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 16:04:33 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389FA3AA.81A961B3@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 16:03:38 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Regression tests...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is there a step-by-step guide somewhere that tells me how to add a new
regression test? I've had a bit of a hunt around, and exactly what to do
to add a test isn't clear.

From bouncefilter Tue Feb 8 00:16:21 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA16993
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 00:16:10 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA17042;
Mon, 7 Feb 2000 21:14:27 -0800 (PST)
Message-Id: <3.0.1.32.20000207210351.010b11a0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Feb 2000 21:03:51 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] TODO item
Cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <27676.949980379@sss.pgh.pa.us>
References: <200002080007.TAA28292@candle.pha.pa.us>
<200002080007.TAA28292@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:26 PM 2/7/00 -0500, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Seems like little redesign needed, except for adding the need_fsync
flag. Should be no more than about 20 lines.

If you think this is a twenty line fix, take a deep breath and back
away slowly. You have not understood the problem.

And, again, thank you.

This is not a trivial change.

I was actually through that code months ago, wondering why (ahem)
PG was so stupid about disk I/O and reached the same conclusion.

Therefore, I was more than pleased when a simple fix to get rid
of fsync's on read-only transactions arose. In my application
space, this alone gave a huge performance boost.

WAL...that's it. If Vadim is going to be unavailable because
of his new job, we'll need to figure out another way to do it.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Tue Feb 8 00:59:22 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA24104
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 00:59:19 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA04370 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 16:58:47 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdbrIqa_;
Tue Feb 8 16:58:14 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA16704 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 16:58:13 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0oO.V3; Tue Feb 8 16:57:38 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA11438
for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 16:57:37 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA07792
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 16:57:02 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389FAFF6.44B7F6ED@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 16:56:06 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Bug in cursors??
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

I came across this comment in exec_append_initialize_next....

/* ----------------
* initialize the scan
* (and update the range table appropriately)
* (doesn't this leave the range table hosed for anybody upstream
* of the Append node??? - jolly )
* ----------------
*/

I took a stab at guessing what this might mean, and ran the following
test.
It looks like a bug. Can anybody shed any light on whether the above
comment is likely to relate to this bug, and is there anybody who is
so intimate with this code that they are willing to fix it?

# Comment: b and c inherit from a. d inherits from b.
chrisb=# begin work;
BEGIN
chrisb=# select aa from a;
aa
----
(0 rows)

chrisb=# select aa from b;
aa
-----
ppp
(1 row)

chrisb=# select aa from c;
aa
-------
cmore
(1 row)

chrisb=# select aa from d;
aa
-------
dmore
(1 row)

chrisb=# select aa from a*;
aa
-------
ppp
cmore
dmore
(3 rows)

chrisb=# declare cu cursor for select aa from a*;
SELECT
chrisb=# fetch forward 1 in cu;
aa
-----
ppp
(1 row)

chrisb=# fetch forward 1 in cu;
aa
-------
cmore
(1 row)

chrisb=# fetch backward 1 in cu;
aa
----
(0 rows)

From bouncefilter Tue Feb 8 01:25:23 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA29577
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 01:25:20 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-1.r12.ncbrvr.InfoAve.Net [207.144.84.71])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with SMTP id BAA02354
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 01:25:18 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: pgsql-hackers@postgresql.org
Subject: Questions on 7.0 for RPM building
Date: Tue, 8 Feb 2000 00:58:57 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00020801315100.00598@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

First, thanks to Peter Eisentraut for putting back pqbool -- I now can build
Pg...

Now, I have a few questions:
1.) What's the deal with the man pages now? In 6.5.x, src/man contained
the man pages. (Then, in the 6.5.2 RPM's and later, an extra tarball of updated
man pages was added on top of the existing ones). In 7.0, they are in
doc/man.tar.gz -- however, there are many that are no longer there, unless I
have overlooked them. Furthermore, while the command names destroy* have been
changed to drop*, the man pages haven't changed. Also, the man3 section has
disappeared. (I realize Thomas is busy with outer joins et al -- this is just
a listing of what I've found -- I'm not by any means fussing...).

2.) Missing man pages that I have found (lost??) thus far:
pg_ctl (being worked on, AFAIK)
ecpg.1
pg_passwd.1
pg_encoding.1
pg_hba.conf.5

3.) Extraneous man pages:
pgadmin.1 (PgAdmin is a Windows program.....)

Also, when building the plperl module, a .so is not being created, nor is it
being installed.

I will continue to bang on the build process for the RPM's as we get closer to
beta.....

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Feb 8 01:07:21 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA25727
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 01:06:24 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA00265;
Tue, 8 Feb 2000 01:06:15 -0500 (EST)
To: chris@bitmead.com
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Regression tests...
In-reply-to: <389FA3AA.81A961B3@nimrod.itg.telecom.com.au>
References: <389FA3AA.81A961B3@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Tue, 08 Feb 2000 16:03:38 +1100"
Date: Tue, 08 Feb 2000 01:06:14 -0500
Message-ID: <262.949989974@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Is there a step-by-step guide somewhere that tells me how to add a new
regression test? I've had a bit of a hunt around, and exactly what to do
to add a test isn't clear.

There's not that much to it, assuming you don't need any platform-
specific variations in the expected output. You make a script under
regress/sql/, add its name in an appropriate place in
sql/run_check.tests, run it, and drop the results file into expected/
(hopefully after manual verification ;-))

BTW, am I right in thinking that sql/tests is now dead code? If so,
we should flush it, or more likely rename run_check.tests to just tests.
Jan?

regards, tom lane

From bouncefilter Tue Feb 8 01:10:21 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA26406
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 01:09:59 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA12592 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 17:09:27 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdDJt0s_;
Tue Feb 8 17:09:15 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA28958 for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 17:09:14 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdmpsTQ_; Tue Feb 8 17:08:34 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA20005
for <pgsql-hackers@postgreSQL.org>;
Tue, 8 Feb 2000 17:08:33 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
RAA08220
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 17:07:58 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <389FB286.4669AC35@nimrod.itg.telecom.com.au>
Date: Tue, 08 Feb 2000 17:07:02 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
References: <200002072348.SAA27846@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yep those pop-up pictures on the globe are cool.

My initial reaction - I'm glad I've got a beard, because it looks to
be a pre-requisite for hacking on postgresql!!!

Bruce Momjian wrote:

Vince Vielhaber wrote:

I have the new developer's globe online. Please check your BIOs and
let me know if there's anything that needs correcting. For those
without pictures, don't be so shy. Submit a picture - if you need to
have one scanned it can be arranged.

And before I forget.. Good job on the globe, Jan!

How much code do I have to contribute to get a marker on Sydney? :)

That's a good question. We normally give "pins" out to people who have
contributed a code over a significant period of time. For example,
Peter Eisentraut is almost ready for a pin. We would normally wait for
his feature patches to be released, and then wait a few months to see if
he is still around. We look for people who we feel are in this for the
long haul.

--
Bruce Momjian                        |  http://www.op.net/~candle
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 01:18:22 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA28007
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 01:17:38 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA00351;
Tue, 8 Feb 2000 01:17:29 -0500 (EST)
To: chris@bitmead.com
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Is this it?
In-reply-to: <389F9A6E.CD58046B@nimrod.itg.telecom.com.au>
References: <389F91D7.E52113F9@nimrod.itg.telecom.com.au>
<389F979B.51A62C09@nimrod.itg.telecom.com.au>
<389F9A6E.CD58046B@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Tue, 08 Feb 2000 15:24:14 +1100"
Date: Tue, 08 Feb 2000 01:17:28 -0500
Message-ID: <348.949990648@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

In ExecInitAppend it has a loop...
foreach(rtentryP, rtable)
{
resultList = lcons(rri, resultList);
}
appendstate->as_result_relation_info_list = resultList;

If I'm not mistaken this will generate the as_result_relation_info_list
in the reverse order to the rtentry list,

Check ...

which is wrong... right?

Maybe. Is there code elsewhere that assumes these lists are ordered
alike?

You could change the lcons call to "lappend(resultList, rri)" if
you just want to try the experiment.

regards, tom lane

From bouncefilter Tue Feb 8 01:34:22 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA31699
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 01:33:48 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id GAA04350;
Tue, 8 Feb 2000 06:41:41 GMT
Sender: lockhart@hub.org
Message-ID: <389FBAA5.79B73A86@alumni.caltech.edu>
Date: Tue, 08 Feb 2000 06:41:41 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: chris@bitmead.com
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Regression tests...
References: <389FA3AA.81A961B3@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is there a step-by-step guide somewhere that tells me how to add a new
regression test? I've had a bit of a hunt around, and exactly what to do
to add a test isn't clear.

Hmm. Not sure. Here is the procedure, and if you want to plop it into
the Developer's Guide sgml sources that would be great:

1) Generate a file containing the test, and place it into
test/regress/sql/. Should be named appropriately, in a style similar
to other files in that directory.

1a) If the test needs new test data, decide if the tables should stay
for the rest of the regression tests or if they should be removed on
completion of the individual test. If they stay, you will need to
update the results of one or two other tests which look at the current
table list.

2) Add the name of the file to sql/run_check.tests, and perhaps for
completeness to sql/tests (the non-parallel version of the test).

2a) If your test gets data from an external file, you will need to put
the templated source file into input/ rather than sql/, and modify the
Makefiles to generate a runable version for sql/

3) Run the regression tests. Your new test will fail (or succeed,
can't remember which) because the "expected" output file does not
exist.

4) Copy results/<your test>.out to expected/<your test>.out

4a) If your test got data from an external file, you will need to put
the templated output file into output/ rather than expected/, and
modify the Makefiles to generate a non-tempated version for expected/

5) Rerun the regression test, making sure that all tests pass, or that
you understand *all* the differences. No fair if you don't analyze the
differences in some detail.

5a) The canonical regression machine is currently a Linux RH5.2 i686
machine. Some platforms produce different results, and will need
platform-specific versions of the regression test results.

6) Send the patches.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 8 01:40:22 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA32795
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 01:39:22 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id GAA04365;
Tue, 8 Feb 2000 06:47:22 GMT
Sender: lockhart@hub.org
Message-ID: <389FBBFA.F57E3FCF@alumni.caltech.edu>
Date: Tue, 08 Feb 2000 06:47:22 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: peter_e@gmx.net, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_ctl man page
References: <Pine.LNX.4.21.0002072051550.6572-100000@localhost.localdomain>
<20000208105126W.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas, I have changed -m <opts> style to -smart, -fast... style. I
hope this was what you meant. Also, please note that I still stick
with smart/fast/immediate since I have been waiting for Vadim's
opinion...

Ugh, that's not a compliant option style. What was wrong with -m
<opt>? How about --smart, etc.? But 'single dash, multiple letters' is
evil.

Oh, I'm confused now. Thomas, could you let me know what you think?
Lamar is trying to use pg_ctl for his RPM project, and we need
decision on that.

Sorry, I didn't catch your question earlier. I agree with Peter that
we should choose single character switches with single dashes (e.g. -s
for "smart", -f for "fast", etc.) or --smart, --fast etc (or both
styles).

Hopefully we'll get some feedback from Vadim soon on the naming; istm
that the "smart", "fast", "immediate" is just too obscure or too
related to the developer's view of the implementation to be the right
choice for the user interface.

The switches and options should describe what they *do*, not what the
developer thought of them ;)

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 8 01:48:22 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA34671
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 01:47:40 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA00446;
Tue, 8 Feb 2000 01:47:31 -0500 (EST)
To: chris@bitmead.com
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
In-reply-to: <389FB286.4669AC35@nimrod.itg.telecom.com.au>
References: <200002072348.SAA27846@candle.pha.pa.us>
<389FB286.4669AC35@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Tue, 08 Feb 2000 17:07:02 +1100"
Date: Tue, 08 Feb 2000 01:47:31 -0500
Message-ID: <441.949992451@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Yep those pop-up pictures on the globe are cool.

My initial reaction - I'm glad I've got a beard, because it looks to
be a pre-requisite for hacking on postgresql!!!

I was getting razzed on IRC the other day for being the only core
member without a beard ...

regards, tom lane

From bouncefilter Tue Feb 8 01:46:22 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA34355
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 01:46:15 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id GAA04381;
Tue, 8 Feb 2000 06:54:11 GMT
Sender: lockhart@hub.org
Message-ID: <389FBD93.BB136891@alumni.caltech.edu>
Date: Tue, 08 Feb 2000 06:54:11 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Duplicate table names
References: <389DAF82.A8F8B561@alumni.caltech.edu>
<3.0.1.32.20000207122612.0109c7f0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Date takes over six pages of fairly terse prose with few examples to
define the scope of range variables in and out of JOIN expressions.
A bit over one page of that is devoted to scoping issues unique
to JOINs, which I don't feel like reading at the moment!

Right. We're not likely to meet all of the scoping rules in the first
implementation; they are *really* tough :(

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 8 02:02:22 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA37924
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 02:01:58 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA09031;
Tue, 8 Feb 2000 01:54:20 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080654.BAA09031@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <27676.949980379@sss.pgh.pa.us> from Tom Lane at "Feb 7,
2000 10:26:19 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 01:54:20 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The problem comes in when *some other* backend has written out a
shared buffer that contained a change that our backend made as part
of the transaction that it now wants to commit. Without immediate-
fsync-on-write (the current solution), there is no guarantee that the
other backend will do an fsync any time soon; it might be busy in
a very long-running transaction. Our backend must fsync that file,
and it must do so after the other backend flushed the buffer. But
there is no existing data structure that our backend can use to
discover that it must do this. The shared buffer cannot record it;
it might belong to some other file entirely by now (and in any case,
the shared buffer is noplace to record per-transaction status info).
Our backend cannot use either FD or VFD to record it, since it might
never have opened the relation file at all, and certainly might have
closed it again (and recycled the FD or VFD) before the other backend
flushed the shared buffer. The relcache might possibly work as a
place to record the need for fsync --- but I am concerned about the
relcache's willingness to drop entries if they are not currently
heap_open'd; also, md/fd don't currently use the relcache at all.

OK, I will admit I must be wrong, but I would like to understand why.

I am suggesting opening and marking a file descriptor as needing fsync
even if I only dirty the buffer and not write it. I understand another
backend may write my buffer and remove it before I commit my
transaction. However, I will be the one to fsync it. I am also
suggesting that such file descriptors never get recycled until
transaction commit.

Is that wrong?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 01:59:22 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA36959
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 01:58:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA09101;
Tue, 8 Feb 2000 01:57:52 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080657.BAA09101@candle.pha.pa.us>
Subject: Re: [HACKERS] Questions on 7.0 for RPM building
In-Reply-To: <00020801315100.00598@lorc.wgcr.org> from Lamar Owen at "Feb 8,
2000 00:58:57 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Tue, 8 Feb 2000 01:57:52 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

First, thanks to Peter Eisentraut for putting back pqbool -- I now can build
Pg...

Now, I have a few questions:
1.) What's the deal with the man pages now? In 6.5.x, src/man contained
the man pages. (Then, in the 6.5.2 RPM's and later, an extra tarball of updated
man pages was added on top of the existing ones). In 7.0, they are in
doc/man.tar.gz -- however, there are many that are no longer there, unless I
have overlooked them. Furthermore, while the command names destroy* have been
changed to drop*, the man pages haven't changed. Also, the man3 section has
disappeared. (I realize Thomas is busy with outer joins et al -- this is just
a listing of what I've found -- I'm not by any means fussing...).

Thomas Lockhart generates man pages from SGML, but that usually happens
before final, not beta.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 02:04:22 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA38400
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 02:03:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
CAA09380;
Tue, 8 Feb 2000 02:00:39 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080700.CAA09380@candle.pha.pa.us>
Subject: Re: [HACKERS] New Globe
In-Reply-To: <441.949992451@sss.pgh.pa.us> from Tom Lane at "Feb 8,
2000 01:47:31 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 02:00:39 -0500 (EST)
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Yep those pop-up pictures on the globe are cool.

My initial reaction - I'm glad I've got a beard, because it looks to
be a pre-requisite for hacking on postgresql!!!

I was getting razzed on IRC the other day for being the only core
member without a beard ...

But we are going to take care of that, right Tom? ;-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 01:56:22 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA36249
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 01:55:42 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA04435;
Tue, 8 Feb 2000 07:03:41 GMT
Sender: lockhart@hub.org
Message-ID: <389FBFCD.271062C0@alumni.caltech.edu>
Date: Tue, 08 Feb 2000 07:03:41 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Lamar Owen <lamar.owen@wgcr.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Questions on 7.0 for RPM building
References: <00020801315100.00598@lorc.wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

1.) What's the deal with the man pages now? In 6.5.x, src/man contained
the man pages. (Then, in the 6.5.2 RPM's and later, an extra tarball of
updated man pages was added on top of the existing ones). In 7.0, they are
in doc/man.tar.gz -- however, there are many that are no longer there,
unless I have overlooked them.

*All* information in the old man pages appears somewhere in the new
html/ps docs. And the reference pages for the new docs are translated
into the new man tarball. We can try to track down specific cases (I
*might* have missed a file or two) but in general if you see something
missing it probably means we don't have a reference page for it.

Furthermore, while the command names destroy* have been
changed to drop*, the man pages haven't changed.

Right. They will need to be regenerated for the 7.0 release, and
haven't been done so far. You *should* get at least a few days to play
with a beta tarball that has these updated.

Also, the man3 section has disappeared.

afaik those pages were not really appropriate for reference pages, or
they do not yet appear in reference pages (library API docs, right?).
They have their own chapter(s) in the docs, but may not be reference
pages yet.

2.) Missing man pages that I have found (lost??) thus far:
pg_ctl (being worked on, AFAIK)
ecpg.1
pg_passwd.1
pg_encoding.1
pg_hba.conf.5

Probably so. If they don't make sense as a "reference page" style of
doc in the main docs, then imho they don't make sense as man pages.
But each should be handled on a case by case basis.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 8 02:07:22 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA39282
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 02:06:48 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA04473;
Tue, 8 Feb 2000 07:14:39 GMT
Sender: lockhart@hub.org
Message-ID: <389FC25F.6D774FB9@alumni.caltech.edu>
Date: Tue, 08 Feb 2000 07:14:39 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
References: <200002072348.SAA27846@candle.pha.pa.us>
<389FB286.4669AC35@nimrod.itg.telecom.com.au>
<441.949992451@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I was getting razzed on IRC the other day for being the only core
member without a beard ...

It's only a matter of time...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 8 02:44:23 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA46346
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 02:43:55 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA00734;
Tue, 8 Feb 2000 02:43:40 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
In-reply-to: <200002080700.CAA09380@candle.pha.pa.us>
References: <200002080700.CAA09380@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 08 Feb 2000 02:00:39 -0500"
Date: Tue, 08 Feb 2000 02:43:40 -0500
Message-ID: <731.949995820@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I was getting razzed on IRC the other day for being the only core
member without a beard ...

But we are going to take care of that, right Tom? ;-)

Er ... will long hair do?

regards, tom lane

From bouncefilter Tue Feb 8 03:31:23 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA58779
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 03:31:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
DAA11931;
Tue, 8 Feb 2000 03:09:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080809.DAA11931@candle.pha.pa.us>
Subject: Re: [HACKERS] New Globe
In-Reply-To: <731.949995820@sss.pgh.pa.us> from Tom Lane at "Feb 8,
2000 02:43:40 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 03:09:06 -0500 (EST)
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I was getting razzed on IRC the other day for being the only core
member without a beard ...

But we are going to take care of that, right Tom? ;-)

Er ... will long hair do?

Can you wrap it up around your chin? :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 03:26:23 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA57556
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 03:25:36 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id DAA00792;
Tue, 8 Feb 2000 03:24:10 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-reply-to: <200002080654.BAA09031@candle.pha.pa.us>
References: <200002080654.BAA09031@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 08 Feb 2000 01:54:20 -0500"
Date: Tue, 08 Feb 2000 03:24:10 -0500
Message-ID: <789.949998250@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am suggesting opening and marking a file descriptor as needing fsync
even if I only dirty the buffer and not write it. I understand another
backend may write my buffer and remove it before I commit my
transaction. However, I will be the one to fsync it. I am also
suggesting that such file descriptors never get recycled until
transaction commit.

Is that wrong?

I see where you're going, and you could possibly make it work, but
there are a bunch of problems. One objection is that kernel FDs
are a very finite resource on a lot of platforms --- you don't really
want to tie up one FD for every dirty buffer, and you *certainly*
don't want to get into a situation where you can't release kernel
FDs until end of xact. You might be able to get around that by
associating the fsync-needed bit with VFDs instead of FDs.

What may turn out to be a nastier problem is the circular dependency
this creates between shared-buffer management and md.c/fd.c. Right now
(IIRC at 3am) md/fd are clearly at a lower level than bufmgr, but that
would stop being true if you make FDs be proxies for dirtied buffers.
Here is one off-the-top-of-the-head trouble scenario: bufmgr wants to
dump a buffer that was dirtied by another backend -> needs to open FD ->
fd.c has no free FDs, needs to close one -> needs to dump and fsync a
buffer so it can forget the FD -> bufmgr needs to get I/O lock on two
different buffers at once -> potential deadlock against another backend
doing the reverse. (Assuming you even get that far, and don't hang up
at the recursive entry to bufmgr trying to get a spinlock you already
hold...)

Possibly with close study you can prove that no such problem can happen.
My point is just that this isn't a trivial change. Is it worth
investing substantial effort on what will ultimately be a dead end?

regards, tom lane

From bouncefilter Tue Feb 8 03:39:23 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA60370
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 03:38:44 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id RAA00204; Tue, 08 Feb 2000 17:38:33 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: <chris@bitmead.com>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Bug in cursors??
Date: Tue, 8 Feb 2000 17:44:32 +0900
Message-ID: <000301bf7210$b84f2120$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <389FAFF6.44B7F6ED@nimrod.itg.telecom.com.au>

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Chris Bitmead

Hi all,

I came across this comment in exec_append_initialize_next....

/* ----------------
* initialize the scan
* (and update the range table appropriately)
* (doesn't this leave the range table hosed for
anybody upstream
* of the Append node??? - jolly )
* ----------------
*/

I took a stab at guessing what this might mean, and ran the following
test.
It looks like a bug. Can anybody shed any light on whether the above
comment is likely to relate to this bug, and is there anybody who is
so intimate with this code that they are willing to fix it?

I've forgotten to apply the following patch.
Without the patch,backward sequential scan is impossible
after reaching EOF.
It may be one of the cause.

Regards.

*** access/heap/heapam.c.orig	Mon Aug  2 14:56:36 1999
--- access/heap/heapam.c	Tue Nov  9 12:59:48 1999
***************
*** 775,782 ****
  		if (scan->rs_ptup.t_data == scan->rs_ctup.t_data &&
  			BufferIsInvalid(scan->rs_pbuf))
  		{
- 			if (BufferIsValid(scan->rs_nbuf))
- 				ReleaseBuffer(scan->rs_nbuf);
  			return NULL;
  		}

--- 775,780 ----
***************
*** 833,842 ****
  				ReleaseBuffer(scan->rs_pbuf);
  			scan->rs_ptup.t_data = NULL;
  			scan->rs_pbuf = InvalidBuffer;
- 			if (BufferIsValid(scan->rs_nbuf))
- 				ReleaseBuffer(scan->rs_nbuf);
- 			scan->rs_ntup.t_data = NULL;
- 			scan->rs_nbuf = InvalidBuffer;
  			return NULL;
  		}

--- 831,836 ----
***************
*** 855,862 ****
  		if (scan->rs_ctup.t_data == scan->rs_ntup.t_data &&
  			BufferIsInvalid(scan->rs_nbuf))
  		{
- 			if (BufferIsValid(scan->rs_pbuf))
- 				ReleaseBuffer(scan->rs_pbuf);
  			HEAPDEBUG_3;		/* heap_getnext returns NULL at end */
  			return NULL;
  		}
--- 849,854 ----
***************
*** 915,924 ****
  				ReleaseBuffer(scan->rs_nbuf);
  			scan->rs_ntup.t_data = NULL;
  			scan->rs_nbuf = InvalidBuffer;
- 			if (BufferIsValid(scan->rs_pbuf))
- 				ReleaseBuffer(scan->rs_pbuf);
- 			scan->rs_ptup.t_data = NULL;
- 			scan->rs_pbuf = InvalidBuffer;
  			HEAPDEBUG_6;		/* heap_getnext returning EOS */
  			return NULL;
  		}
--- 907,912 ----

From bouncefilter Tue Feb 8 03:59:24 2000
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net
[194.217.242.39]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA64419
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 03:58:56 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
id 12I6U3-000HR6-0B
for pgsql-hackers@postgreSQL.org; Tue, 8 Feb 2000 08:58:55 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id IAA06048
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 08:58:55 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <129FQSYK>; Tue, 8 Feb 2000 08:57:59 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C181@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "Pgsql-Hackers (E-mail)" <pgsql-hackers@postgresql.org>
Subject: Inserting large objects
Date: Tue, 8 Feb 2000 08:57:56 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

Just a quick question, but has anyone inserted a large object with a
specific OID, rather than getting a new oid?

What I'm thinking of, is backing up the large objects in a database into
a zip file, then restoring them (if required).

This is for a new JDBC example. The backup is easy, but it's the
restoring that I can't see how it can be done with the current lo_
functions.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

From bouncefilter Tue Feb 8 04:11:26 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA67191
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 04:11:03 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id UAA24490
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 20:10:55 +1100
Sender: chris@tech.com.au
Message-ID: <389FDD9F.260E50DD@bitmead.com>
Date: Tue, 08 Feb 2000 20:10:55 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: How to make a patch?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

How do I make a patch that includes new files?

Previously I was doing a cvs diff -R -N -c
to make a patch, but this doesn't work for
new files. I can't do cvs add, and using
plain diff is near-impossible on a CVS directory.

From bouncefilter Tue Feb 8 04:34:24 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA72256
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 04:33:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
EAA12806;
Tue, 8 Feb 2000 04:12:45 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080912.EAA12806@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <789.949998250@sss.pgh.pa.us> from Tom Lane at "Feb 8,
2000 03:24:10 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 04:12:44 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am suggesting opening and marking a file descriptor as needing fsync
even if I only dirty the buffer and not write it. I understand another
backend may write my buffer and remove it before I commit my
transaction. However, I will be the one to fsync it. I am also
suggesting that such file descriptors never get recycled until
transaction commit.

Is that wrong?

I see where you're going, and you could possibly make it work, but
there are a bunch of problems. One objection is that kernel FDs
are a very finite resource on a lot of platforms --- you don't really
want to tie up one FD for every dirty buffer, and you *certainly*
don't want to get into a situation where you can't release kernel
FDs until end of xact. You might be able to get around that by
associating the fsync-needed bit with VFDs instead of FDs.

OK, at least I was thinking correctly. Yes, there are serious drawbacks
that make this pretty hard to implement. Unless Vadim revives this, we
can drop it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 04:31:24 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA71755
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 04:31:11 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
EAA12880;
Tue, 8 Feb 2000 04:16:03 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002080916.EAA12880@candle.pha.pa.us>
Subject: Re: [HACKERS] Bug in cursors??
In-Reply-To: <000301bf7210$b84f2120$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Feb 8, 2000 05:44:32 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 8 Feb 2000 04:16:02 -0500 (EST)
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hiroshi, do you need this applied?

I've forgotten to apply the following patch.
Without the patch,backward sequential scan is impossible
after reaching EOF.
It may be one of the cause.

Regards.

*** access/heap/heapam.c.orig	Mon Aug  2 14:56:36 1999
--- access/heap/heapam.c	Tue Nov  9 12:59:48 1999
***************
*** 775,782 ****
if (scan->rs_ptup.t_data == scan->rs_ctup.t_data &&
BufferIsInvalid(scan->rs_pbuf))
{
- 			if (BufferIsValid(scan->rs_nbuf))
- 				ReleaseBuffer(scan->rs_nbuf);
return NULL;
}

--- 775,780 ----
***************
*** 833,842 ****
ReleaseBuffer(scan->rs_pbuf);
scan->rs_ptup.t_data = NULL;
scan->rs_pbuf = InvalidBuffer;
- 			if (BufferIsValid(scan->rs_nbuf))
- 				ReleaseBuffer(scan->rs_nbuf);
- 			scan->rs_ntup.t_data = NULL;
- 			scan->rs_nbuf = InvalidBuffer;
return NULL;
}

--- 831,836 ----
***************
*** 855,862 ****
if (scan->rs_ctup.t_data == scan->rs_ntup.t_data &&
BufferIsInvalid(scan->rs_nbuf))
{
- 			if (BufferIsValid(scan->rs_pbuf))
- 				ReleaseBuffer(scan->rs_pbuf);
HEAPDEBUG_3;		/* heap_getnext returns NULL at end */
return NULL;
}
--- 849,854 ----
***************
*** 915,924 ****
ReleaseBuffer(scan->rs_nbuf);
scan->rs_ntup.t_data = NULL;
scan->rs_nbuf = InvalidBuffer;
- 			if (BufferIsValid(scan->rs_pbuf))
- 				ReleaseBuffer(scan->rs_pbuf);
- 			scan->rs_ptup.t_data = NULL;
- 			scan->rs_pbuf = InvalidBuffer;
HEAPDEBUG_6;		/* heap_getnext returning EOS */
return NULL;
}
--- 907,912 ----

************

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 05:08:24 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA84789
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 05:07:51 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id TAA00266; Tue, 08 Feb 2000 19:06:54 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: <chris@bitmead.com>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Bug in cursors??
Date: Tue, 8 Feb 2000 19:12:52 +0900
Message-ID: <000401bf721d$0f85aca0$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <200002080916.EAA12880@candle.pha.pa.us>

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Tuesday, February 08, 2000 6:16 PM

Hiroshi, do you need this applied?

Oops,this patch is old,sorry.
Another patch may be needed.

DO you think this patch should also be applied to REL tree ?
If so,could you please apply it to both trees ?
Otherwise I would commit it only to current tree myself.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Feb 8 05:55:26 2000
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA94506
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 05:55:17 -0500 (EST)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id NAA19104;
Tue, 8 Feb 2000 13:42:57 +0300 (GMT)
Date: Tue, 8 Feb 2000 13:42:57 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, hackers@postgreSQL.org
Subject: Re: [HACKERS] network_ops in 7.0 and pg_dump question
In-Reply-To: <200002080003.TAA28228@candle.pha.pa.us>
Message-ID: <Pine.GSO.3.96.SK.1000208133713.18898A-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Thanks,
creation of index works now. But what about pg_dump ?
I still have to edit manually dump file.
look to excerption from dump file:
CREATE TABLE "applicant" (
"candx" int2 DEFAULT next_applicant() NOT NULL,
"candidate" text,
"candt" int2,
"img" text
);

This fails because function next_applicant dumps later !

Here is a psql output:
You are now connected as new user megera.
ERROR: Relation 'applicant' does not exist
invalid command \N
invalid command \N
invalid command \N
invalid command \N
invalid command \.
ERROR: parser: parse error at or near "2"
invalid command \.
ERROR: parser: parse error at or near "1"
invalid command \.
ERROR: parser: parse error at or near "1"
invalid command \.
ERROR: parser: parse error at or near "1"
invalid command \.
ERROR: parser: parse error at or near "24"
invalid command \.
ERROR: parser: parse error at or near "24"
CREATE
CREATE

Hmm, error diagnostics still not very informative :-)

Regards,

Oleg

On Mon, 7 Feb 2000, Bruce Momjian wrote:

Date: Mon, 7 Feb 2000 19:03:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
Subject: Re: [HACKERS] network_ops in 7.0 and pg_dump question

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Now, how to convert these? Not supplying the ops works fine, but
pg_dump supplies the ops. Maybe in gram.y, if they supply network_ops,
we should just remove that from being passed to the backend for a few
releases. Comments?

Ugly, but probably the best stopgap for backwards compatibility ...
at least I can't think of a better answer, since we have no way to
change what 6.5 pg_dump will dump.

You're only going to suppress "network_ops" if it appears in the
ops position of a CREATE INDEX, right? Don't want to stop people
from using the name for fields and so on.

No, just at that part in the grammar.

-- 
Bruce Momjian                        |  http://www.op.net/~candle
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

************

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Tue Feb 8 06:11:25 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id GAA97951
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 06:11:10 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12I8NB-0003kGC; Tue, 8 Feb 100 11:59 MET
Message-Id: <m12I8NB-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Regression tests...
In-Reply-To: <262.949989974@sss.pgh.pa.us> from Tom Lane at "Feb 8,
2000 01:06:14 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 11:59:57 +0100 (CET)
CC: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

BTW, am I right in thinking that sql/tests is now dead code? If so,
we should flush it, or more likely rename run_check.tests to just tests.
Jan?

Yepp, dead.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 8 06:10:25 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id GAA97679
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 06:09:43 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 3851 invoked by uid 1001); 8 Feb 2000 11:09:44 -0000
Date: Tue, 8 Feb 2000 06:09:44 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
In-Reply-To: <441.949992451@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.10002080608300.3799-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 8 Feb 2000, Tom Lane wrote:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Yep those pop-up pictures on the globe are cool.

My initial reaction - I'm glad I've got a beard, because it looks to
be a pre-requisite for hacking on postgresql!!!

I was getting razzed on IRC the other day for being the only core
member without a beard ...

regards, tom lane

So where's the photo?

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Tue Feb 8 06:33:37 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA02787
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 06:32:31 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA20880;
Tue, 8 Feb 2000 12:32:25 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA12791; Tue, 8 Feb 2000 12:32:24 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 8 Feb 2000 12:32:23 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PostgreSQL 7 RPMs coming soon
In-Reply-To: <389F520F.C114611E@wgcr.org>
Message-ID: <Pine.GSO.4.02A.10002081230560.12742-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Yes, this seems very much like the stuff I've been thinking about. I'll
bring it up when the next devel cycle has started.

On Mon, 7 Feb 2000, Lamar Owen wrote:

Peter Eisentraut wrote:

database, in an FHS-compliant manner (the current regression tests AND
upgrade scripts are not in compliance with the FHS in terms of their

[snip]

What exactly is FHS and what do they say? I am vaguely phantasizing about
doing a little work on the build process for the next release; is that
something that could be addressed?

FHS 2.0 is the Filesystem Hierarchy Standard, successor to the Linux
FileSystem Standard (FSSTND). You may find the full document at
http://www.pathname.com/fhs/

Currently, in order to get PostgreSQL into RPM form requires a number of
mungifications -- the current prefix parameter is set to /usr, which
puts binaries and shared libs in the right place -- but everything else
is moved into place manually. It is a rather kludgy build script (ask
Thomas, he knows). To look at the build script (in RPM parlance, a
'spec file'), load up
http://www.ramifordistat.net/postgres/unpacked/non-beta/postgresql-6.5.3-3.spec
(one line; it'll probably wrap on your e-mail client).

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 8 06:35:25 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA03295
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 06:35:06 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA21055;
Tue, 8 Feb 2000 12:35:00 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA12795; Tue, 8 Feb 2000 12:34:59 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 8 Feb 2000 12:34:58 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and libpq fixes
In-Reply-To: <22504.949970790@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10002081233550.12742-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 7 Feb 2000, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

While we're at it, there's a setting that causes psql to stop execution of
a script on an error (since usually the later commands will be depending
on the successful completion of earlier ones). I was wondering if that
should be the default if you use the -f option.

Sounds useful, but you can't make it the default without breaking existing
scripts. Trivial example is this common idiom:
DROP TABLE t1; -- in case it already exists
CREATE TABLE t1;
COPY ...

Oh yes, good point.

In general, an existing script is not going to be written with the idea
that psql will cut it off at the knees for provoking an error. If the
author *does* want all the rest of the commands to be skipped on error,
he'll just have written BEGIN and END around the whole script.

Last time I checked you couldn't roll back a create table. ;)

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 8 06:33:25 2000
Received: from hu.tm.ee (ppp929.tele2.ee [212.107.37.229])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA02816
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 06:32:54 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 00301399B; Tue, 8 Feb 2000 13:40:13 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38A0009D.BA64DFE4@tm.ee>
Date: Tue, 08 Feb 2000 13:40:13 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: chris@bitmead.com, Vince Vielhaber <vev@michvhf.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
References: <200002072348.SAA27846@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

How much code do I have to contribute to get a marker on Sydney? :)

That's a good question. We normally give "pins" out to people who have
contributed a code over a significant period of time. For example,
Peter Eisentraut is almost ready for a pin. We would normally wait for
his feature patches to be released, and then wait a few months to see if
he is still around.

Vadim seens to have disappeared from earth, I hope you are not going to
remove his pin yet ;)

Hopefully he won't be away from postgres for the full 6 year he'll spend in
America.

We look for people who we feel are in this for the
long haul.

-------------
Hannu

From bouncefilter Tue Feb 8 06:51:25 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA07111
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 06:50:37 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA22594;
Tue, 8 Feb 2000 12:50:31 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA12852; Tue, 8 Feb 2000 12:50:29 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 8 Feb 2000 12:50:29 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Chris <chris@bitmead.com>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] How to make a patch?
In-Reply-To: <389FDD9F.260E50DD@bitmead.com>
Message-ID: <Pine.GSO.4.02A.10002081243340.12742-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 8 Feb 2000, Chris wrote:

How do I make a patch that includes new files?

Previously I was doing a cvs diff -R -N -c
to make a patch, but this doesn't work for
new files. I can't do cvs add, and using
plain diff is near-impossible on a CVS directory.

Here is something that was recommended to me by Jan, and it seems a number
of other people follow a similar road.

When you checked out or updated your cvs copy and you want to start
working on something, make one copy like
$ cp -r pgsql pgsql.orig

Then run configure on that copy. Then copy this one like
$ cp -r pgsql.orig pgsql.work

Then work on this one. I find it occasionally useful to be able to do a
make install on the .orig tree as well do "see how it used to behave".
(You don't want to mess up your cvs tree for that.)

When you're done you create a patch between pgsql.orig and pgsql.work
using diff -c -r whatnot and send that in. Then you do cvs update again an
the game begins anew. This also has the advantage that if someone mangles
your patch slightly (such as running indent on it) you won't get funny
merge conflicts when you cvs update over your self-patched cvs tree.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 8 07:12:26 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id HAA11964
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 07:12:09 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12I9Kj-0003kGC; Tue, 8 Feb 100 13:01 MET
Message-Id: <m12I9Kj-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] TODO item
To: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Date: Tue, 8 Feb 2000 13:01:29 +0100 (CET)
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I see where you're going, and you could possibly make it work, but
there are a bunch of problems. One objection is that kernel FDs
are a very finite resource on a lot of platforms --- you don't really
want to tie up one FD for every dirty buffer, and you *certainly*
don't want to get into a situation where you can't release kernel
FDs until end of xact. You might be able to get around that by
associating the fsync-needed bit with VFDs instead of FDs.

Reminds me to the usefulness of some kind of tablespace
storage manager. It might not buy us a single saved byte on
disk, or maybe cost us some extra. But it would save file
descriptors.

And if this storage manager would work with some amount of
preallocated blocks, it would be totally happy with a
fdatasync() instead of a fsync(). Some per tablespace
configurable options like initial number of blocks, next
extent size and percentage increase would be fine.

Before someone asks, the difference between a fdatasync() and
a fsync() is, that the first only forces modified data blocks
to be flushed to disk. A fsync() causes the inode to be
flushed too, because at least it has a new modtime. In our
case, where writes to files can cause block allocations, it
is a requirement to flush the inode on modifications. But if
dealing with a file where blocks are already allocated (no
null faking or write behind the EOF), it is not that
important. Any difference you might see after a crash can be
a slightly different last modification time, and this really
doesn't count.

The result of that difference is, that a write()+fsync()
nearly allways causes head seeks on the disk (except the
inode and dirty blocks are on the same cylinder). In contrast
a series of write()+fdatasync() calls for one and the same
file, all blocks close together, wouldn't. And isn't that
what our backends usually do?

Having immediate SCSI error reporting enabled on the disks,
such a burst of write()+fdatasync() calls wouln't have such a
big performance impact any more. In that case, the
fdatasync() call will return already at the time, the flushed
blocks reached the on-disk cache. Not waiting until they are
burned into the surface.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 8 07:10:26 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA11402
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 07:09:31 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id XAA26930
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 23:09:07 +1100
Sender: chris@tech.com.au
Message-ID: <38A00763.F3BC711A@bitmead.com>
Date: Tue, 08 Feb 2000 23:09:07 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: New Patch
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

At the URL below is a preview patch (I guess for
future 7.1) that I'm putting up for review. I've
incorporated fixes in response to previous
comments.

It now has working SELECT, UPDATE and DELETE for
inherited tables and supporting the ONLY syntax.

ftp://ftp.tech.com.au/pub/patch.only

--
Chris Bitmead
mailto:chris@bitmead.com

From bouncefilter Tue Feb 8 07:47:26 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA19913
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 07:46:54 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-28.r18.ncbrvr.infoave.net [206.74.232.158]
(may be forged))
by www.wgcr.org (8.9.3/8.9.3/WGCR) with SMTP id HAA02837;
Tue, 8 Feb 2000 07:46:44 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Tatsuo Ishii <t-ishii@sra.co.jp>
Subject: Re: [HACKERS] pg_ctl man page
Date: Tue, 8 Feb 2000 07:51:49 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: peter_e@gmx.net, pgsql-hackers@postgresql.org
References: <Pine.LNX.4.21.0002072051550.6572-100000@localhost.localdomain>
<20000208105126W.t-ishii@sra.co.jp>
<389FBBFA.F57E3FCF@alumni.caltech.edu>
In-Reply-To: <389FBBFA.F57E3FCF@alumni.caltech.edu>
MIME-Version: 1.0
Message-Id: <00020807531500.00616@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Tue, 08 Feb 2000, Thomas Lockhart wrote:

Oh, I'm confused now. Thomas, could you let me know what you think?
Lamar is trying to use pg_ctl for his RPM project, and we need
decision on that.

Sorry, I didn't catch your question earlier. I agree with Peter that
we should choose single character switches with single dashes (e.g. -s
for "smart", -f for "fast", etc.) or --smart, --fast etc (or both
styles).

As for the RPM stuff, I can wait until it's ready easily enough -- if that's
early or late in the beta cycle is immaterial -- I'm just trying to get a feel
for the order I need to do things in.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Feb 8 07:56:26 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA21927
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 07:55:56 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-28.r18.ncbrvr.infoave.net [206.74.232.158]
(may be forged))
by www.wgcr.org (8.9.3/8.9.3/WGCR) with SMTP id HAA02852;
Tue, 8 Feb 2000 07:55:54 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] Questions on 7.0 for RPM building
Date: Tue, 8 Feb 2000 07:53:23 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: pgsql-hackers@postgreSQL.org
References: <00020801315100.00598@lorc.wgcr.org>
<389FBFCD.271062C0@alumni.caltech.edu>
In-Reply-To: <389FBFCD.271062C0@alumni.caltech.edu>
MIME-Version: 1.0
Message-Id: <00020808022501.00616@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Tue, 08 Feb 2000, Thomas Lockhart wrote:

1.) What's the deal with the man pages now? In 6.5.x, src/man contained

*All* information in the old man pages appears somewhere in the new
html/ps docs.

Ok. I can package the man pages that we're going to ship, and leave the rest
alone -- that's easy enough. I was just curious as to what happened to them --
and you've answered my question.

Furthermore, while the command names destroy* have been
changed to drop*, the man pages haven't changed.

Right. They will need to be regenerated for the 7.0 release, and
haven't been done so far. You *should* get at least a few days to play
with a beta tarball that has these updated.

That's fine -- even if it is a 'late' beta, so long as I know when I'm fine.

Also, the man3 section has disappeared.

afaik those pages were not really appropriate for reference pages, or
they do not yet appear in reference pages (library API docs, right?).

Well, they _were_ in the 6.5.x tarball. But, hey, if they're removed, that's
fine. I can put a note in the README.rpm file that the preferred documentation
is the sgml source and its derivatives. I was just curious as to what
happened, as I don't recall seeing a message about that.

2.) Missing man pages that I have found (lost??) thus far:
pg_ctl (being worked on, AFAIK)
ecpg.1
pg_passwd.1
pg_encoding.1
pg_hba.conf.5

Probably so. If they don't make sense as a "reference page" style of
doc in the main docs, then imho they don't make sense as man pages.
But each should be handled on a case by case basis.

Again, these are man pages (except for pg_encoding and pg_ctl) that existed in
6.5.x.

I realize that these man pages are not the highest priority -- as I was doing a
trial build last night, I had finally gotten everything to build properly
(except plperl), and started working on the %file lists for the packages.,
since there are more executables in 7.0 than in 6.5.x. That's when I noticed
these.

If it'll be the final release before they're there, I can easily wait until
then (this is admittedly my first major release cycle -- I came on board after
the final 6.5 release).

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Feb 8 07:57:26 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA22255
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 07:57:21 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA27566;
Tue, 8 Feb 2000 13:57:18 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA12978; Tue, 8 Feb 2000 13:57:16 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 8 Feb 2000 13:57:15 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Jan Wieck <wieck@debis.com>
cc: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <m12I9Kj-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.GSO.4.02A.10002081348140.12742-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 8 Feb 2000, Jan Wieck wrote:

And if this storage manager would work with some amount of
preallocated blocks, it would be totally happy with a
fdatasync() instead of a fsync(). Some per tablespace
configurable options like initial number of blocks, next
extent size and percentage increase would be fine.

On Linux, fdatasync() does exactly the same as fsync(). On FreeBSD (3.4),
fdatasync() isn't even documented and I can't find it in any of the
include files either. What I'm saying is that for the vast majority of our
users this would most likely buy exactly nothing. I just wanted to point
that out, not dismiss the idea.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 8 08:00:26 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA23155
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 08:00:26 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-28.r18.ncbrvr.infoave.net [206.74.232.158]
(may be forged))
by www.wgcr.org (8.9.3/8.9.3/WGCR) with SMTP id HAA02858;
Tue, 8 Feb 2000 07:57:16 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [HACKERS] Questions on 7.0 for RPM building
Date: Tue, 8 Feb 2000 08:02:36 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: pgsql-hackers@postgreSQL.org
References: <200002080657.BAA09101@candle.pha.pa.us>
In-Reply-To: <200002080657.BAA09101@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <00020808034702.00616@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Tue, 08 Feb 2000, Bruce Momjian wrote:

Thomas Lockhart generates man pages from SGML, but that usually happens
before final, not beta.

Then I'll wait until before final to worry about the man pages.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Feb 8 08:38:27 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA31683
for <hackers@postgresql.org>; Tue, 8 Feb 2000 08:38:19 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-45.r15.ncbrvr.InfoAve.Net [207.144.84.245])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with SMTP id IAA02918;
Tue, 8 Feb 2000 08:37:56 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Peter Eisentraut <peter_e@gmx.net>, Peter Eisentraut <e99re41@DoCS.UU.SE>,
Chris <chris@bitmead.com>
Subject: Re: [HACKERS] How to make a patch?
Date: Tue, 8 Feb 2000 08:35:58 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Postgres Hackers List <hackers@postgresql.org>
References: <Pine.GSO.4.02A.10002081243340.12742-100000@Krokodil.DoCS.UU.SE>
In-Reply-To: <Pine.GSO.4.02A.10002081243340.12742-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Message-Id: <00020808442604.00616@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Tue, 08 Feb 2000, Peter Eisentraut wrote:

On Tue, 8 Feb 2000, Chris wrote:

How do I make a patch that includes new files?

Here is something that was recommended to me by Jan, and it seems a number
of other people follow a similar road.

[snip]

When you're done you create a patch between pgsql.orig and pgsql.work
using diff -c -r whatnot and send that in. Then you do cvs update again an
the game begins anew. This also has the advantage that if someone mangles
your patch slightly (such as running indent on it) you won't get funny
merge conflicts when you cvs update over your self-patched cvs tree.

This is also SOP for patching for RPM building. The RPM philosophy is to
always build from pristine released sources -- if changes are required in order
to shoehorn the package into the RedHat FHS confines, then those changes are
distributed as a set of patches against the pristine sources. The build
process then applies those patches at build time. The idea is to allow RPM
users to easily rebuild packages by simply pulling off the latest pristine
tarball, then, after editing the patches appropriately, a simple 'rpm -ba'
command completely rebuilds the packages, which you can then install.

For the RPM's, I have a pristine tree in postgresql-x.x.x.orig, and the work
tree in postgresql-x.x.x, then issue a 'diff -uNr ' between the two trees.
Then, I rename the work tree to postgresql-x.x.x.patched, then issue the 'rpm
-ba' (or variants, depending on how far I want the build to proceed), which
applies those patches to a new pristine build tree.

I have found that the patchset for PostgreSQL doesn't usually vary much --
until now, as there's a whole new regression test suite, and the majority of
the RPM-ifying patches were in the regression suite (so that it could be
prebuilt and run without using make, and without having a source tree around at
run time).

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Feb 8 09:31:28 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA47525
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 09:30:47 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
JAA24861;
Tue, 8 Feb 2000 09:14:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002081414.JAA24861@candle.pha.pa.us>
Subject: Re: [HACKERS] New Globe
In-Reply-To: <Pine.BSF.4.05.10002080608300.3799-100000@paprika.michvhf.com>
from Vince Vielhaber at "Feb 8, 2000 06:09:44 am"
To: Vince Vielhaber <vev@michvhf.com>
Date: Tue, 8 Feb 2000 09:14:25 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 8 Feb 2000, Tom Lane wrote:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Yep those pop-up pictures on the globe are cool.

My initial reaction - I'm glad I've got a beard, because it looks to
be a pre-requisite for hacking on postgresql!!!

I was getting razzed on IRC the other day for being the only core
member without a beard ...

regards, tom lane

So where's the photo?

If anyone wants to postal mail me a photo, I will scan it in and send it
to Vince. Postal address is in my signature.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 09:31:27 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA47557
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 09:31:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
JAA24958;
Tue, 8 Feb 2000 09:16:07 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002081416.JAA24958@candle.pha.pa.us>
Subject: Re: [HACKERS] Bug in cursors??
In-Reply-To: <000401bf721d$0f85aca0$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Feb 8, 2000 07:12:52 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 8 Feb 2000 09:16:07 -0500 (EST)
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Tuesday, February 08, 2000 6:16 PM

Hiroshi, do you need this applied?

Oops,this patch is old,sorry.
Another patch may be needed.

DO you think this patch should also be applied to REL tree ?
If so,could you please apply it to both trees ?
Otherwise I would commit it only to current tree myself.

I don't think we are doing more 6.5.* releases

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 10:16:28 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA59093
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 10:16:22 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA80201;
Tue, 8 Feb 2000 11:14:37 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 8 Feb 2000 11:14:37 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Hannu Krosing <hannu@tm.ee>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, chris@bitmead.com,
Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] New Globe
In-Reply-To: <38A0009D.BA64DFE4@tm.ee>
Message-ID: <Pine.BSF.4.21.0002081114010.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 8 Feb 2000, Hannu Krosing wrote:

Bruce Momjian wrote:

How much code do I have to contribute to get a marker on Sydney? :)

That's a good question. We normally give "pins" out to people who have
contributed a code over a significant period of time. For example,
Peter Eisentraut is almost ready for a pin. We would normally wait for
his feature patches to be released, and then wait a few months to see if
he is still around.

Vadim seens to have disappeared from earth, I hope you are not going to
remove his pin yet ;)

Hopefully he won't be away from postgres for the full 6 year he'll spend in
America.

He's alive and well ... but has >500 email to scan through before he even
gets to this thread :)

From bouncefilter Tue Feb 8 10:45:28 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA75137
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 10:44:47 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA25986;
Tue, 8 Feb 2000 16:44:37 +0100
Date: Tue, 8 Feb 2000 16:44:37 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Don Baccus <dhogaza@pacifier.com>
cc: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
In-Reply-To: <3.0.1.32.20000207151801.010a6a90@mail.pacifier.com>
Message-ID: <Pine.LNX.3.96.1000208161818.25167A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

the Mariposa db distribution is interesting, but it is very specific. If I
good understand it is not real-time and global synchronized DB replication.
But for a lot of users (and me) is probably interestion on-line DB replication
and synchronization. How much users have 10K servers?

I explore current PG's source and is probably possible create support for
on-line replication. My idea is replicate data on a heap_ layout. The parser,
planer and executor run on local backend and replicate straight-out tuples
to the others servers (nodes). It needs synchronize PG's locks too.
In near future I want start project for PG on-line replication. Or works on
this anyone now? Comments?

Karel

From bouncefilter Tue Feb 8 10:50:28 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA76522
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 10:50:18 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA01780;
Tue, 8 Feb 2000 10:50:14 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and libpq fixes
In-reply-to: <Pine.GSO.4.02A.10002081233550.12742-100000@Krokodil.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10002081233550.12742-100000@Krokodil.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Tue, 08 Feb 2000 12:34:58 +0100"
Date: Tue, 08 Feb 2000 10:50:14 -0500
Message-ID: <1777.950025014@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

In general, an existing script is not going to be written with the idea
that psql will cut it off at the knees for provoking an error. If the
author *does* want all the rest of the commands to be skipped on error,
he'll just have written BEGIN and END around the whole script.

Last time I checked you couldn't roll back a create table. ;)

Au contraire, rolling back a CREATE works fine. It's rolling back
a DROP that gives trouble ;-)

This does bring up a thought --- should psql's kill-the-script-on-error
option perhaps zap the script only for errors committed outside of a
transaction block? I'm not sure how hard it is for psql to keep track
of whether the script is in an xact, so maybe this'd be far harder than
it's worth. Seems like it deserves some consideration though.

regards, tom lane

From bouncefilter Tue Feb 8 10:53:28 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA77226
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 10:53:02 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA01817;
Tue, 8 Feb 2000 10:52:28 -0500 (EST)
To: Hannu Krosing <hannu@tm.ee>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, chris@bitmead.com,
Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
In-reply-to: <38A0009D.BA64DFE4@tm.ee>
References: <200002072348.SAA27846@candle.pha.pa.us> <38A0009D.BA64DFE4@tm.ee>
Comments: In-reply-to Hannu Krosing <hannu@tm.ee>
message dated "Tue, 08 Feb 2000 13:40:13 +0200"
Date: Tue, 08 Feb 2000 10:52:28 -0500
Message-ID: <1814.950025148@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Hannu Krosing <hannu@tm.ee> writes:

Vadim seens to have disappeared from earth, I hope you are not going to
remove his pin yet ;)

Certainly not --- but it needs to be moved to San Francisco ...

Hopefully he won't be away from postgres for the full 6 year he'll
spend in America.

He's pretty busy at the moment with getting settled in, but I'm sure
he'll be participating again soon.

regards, tom lane

From bouncefilter Tue Feb 8 11:05:29 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id LAA80870
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:05:10 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12ICyF-0003kGC; Tue, 8 Feb 100 16:54 MET
Message-Id: <m12ICyF-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Deferred trigger queue
To: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Date: Tue, 8 Feb 2000 16:54:31 +0100 (CET)
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

looking at all the complications about dealing with segmented
files etc., I wonder if it's really worth the efford to add
file buffering to the trigger queue.

The memory footprint left by modifying a row where triggers
have to be run is about 40 + 8 * num_triggers bytes. So for
one PK/FP relationship, it will be 48 bytes per FK
inserted/updated or 48 bytes per PK updated/deleted. If one
PK table has multiple references to it, this will only add
another 8 bytes to the footprint. Same if one table has
multiple foreign keys defined.

The question now is, who ever attempts to act on millions of
rows in one transaction, if referential integrity constraints
are set up?

Of course, if someone updates millions of rows in an RI
scenario during one transaction, it could blow away the
backend. But I'd prefer to leave this as a well known problem
for 7.1 and better start on creating a good regression test
and some documentation for it.

Thomas, where should the documentation for FOREIGN KEY go?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 8 10:56:29 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA78157
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 10:56:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA27077;
Tue, 8 Feb 2000 10:54:59 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002081554.KAA27077@candle.pha.pa.us>
Subject: Re: [HACKERS] New Globe
In-Reply-To: <1814.950025148@sss.pgh.pa.us> from Tom Lane at "Feb 8,
2000 10:52:28 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 10:54:59 -0500 (EST)
CC: Hannu Krosing <hannu@tm.ee>, chris@bitmead.com,
Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hannu Krosing <hannu@tm.ee> writes:

Vadim seens to have disappeared from earth, I hope you are not going to
remove his pin yet ;)

Certainly not --- but it needs to be moved to San Francisco ...

Hopefully he won't be away from postgres for the full 6 year he'll
spend in America.

He's pretty busy at the moment with getting settled in, but I'm sure
he'll be participating again soon.

I hear he will be here for 3 years.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 10:57:29 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id KAA78498
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 10:57:16 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 4438 invoked by uid 1001); 8 Feb 2000 15:57:18 -0000
Date: Tue, 8 Feb 2000 10:57:18 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: The Hermit Hacker <scrappy@hub.org>
cc: Hannu Krosing <hannu@tm.ee>, Bruce Momjian <pgman@candle.pha.pa.us>,
chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
In-Reply-To: <Pine.BSF.4.21.0002081114010.74045-100000@thelab.hub.org>
Message-ID: <Pine.BSF.4.05.10002081056150.4432-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 8 Feb 2000, The Hermit Hacker wrote:

On Tue, 8 Feb 2000, Hannu Krosing wrote:

Bruce Momjian wrote:

How much code do I have to contribute to get a marker on Sydney? :)

That's a good question. We normally give "pins" out to people who have
contributed a code over a significant period of time. For example,
Peter Eisentraut is almost ready for a pin. We would normally wait for
his feature patches to be released, and then wait a few months to see if
he is still around.

Vadim seens to have disappeared from earth, I hope you are not going to
remove his pin yet ;)

Hopefully he won't be away from postgres for the full 6 year he'll spend in
America.

He's alive and well ... but has >500 email to scan through before he even
gets to this thread :)

Shouldn't take long, that's less than a days worth of mail for me! But
it's no fun after a long weekend outa town :)

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Tue Feb 8 11:16:29 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA83935
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:15:32 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id LAA20103
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:00:35 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA01892;
Tue, 8 Feb 2000 11:00:34 -0500 (EST)
To: Mark Hollomon <mhh@mindspring.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] docs and createlang patch for plperl
In-reply-to: <20000203205112.A12565@mindspring.com>
References: <20000203205112.A12565@mindspring.com>
Comments: In-reply-to Mark Hollomon <mhh@mindspring.com>
message dated "Thu, 03 Feb 2000 20:51:12 -0500"
Date: Tue, 08 Feb 2000 11:00:34 -0500
Message-ID: <1889.950025634@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Mark Hollomon <mhh@mindspring.com> writes:

createlang.sh.diff - a patch to add plperl
to the repertoire of createlang.sh

Good, but dare I mention that droplang needs to know about it too?

I'm sure you see no possible reason for someone to want to drop
plperl ;-) ... but it should be there.

regards, tom lane

From bouncefilter Tue Feb 8 11:03:29 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA80122
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:02:28 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA27899;
Tue, 8 Feb 2000 11:02:01 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002081602.LAA27899@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and libpq fixes
In-Reply-To: <1777.950025014@sss.pgh.pa.us> from Tom Lane at "Feb 8,
2000 10:50:14 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 11:02:01 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

In general, an existing script is not going to be written with the idea
that psql will cut it off at the knees for provoking an error. If the
author *does* want all the rest of the commands to be skipped on error,
he'll just have written BEGIN and END around the whole script.

Last time I checked you couldn't roll back a create table. ;)

Au contraire, rolling back a CREATE works fine. It's rolling back
a DROP that gives trouble ;-)

This does bring up a thought --- should psql's kill-the-script-on-error
option perhaps zap the script only for errors committed outside of a
transaction block? I'm not sure how hard it is for psql to keep track
of whether the script is in an xact, so maybe this'd be far harder than
it's worth. Seems like it deserves some consideration though.

Why is being in a transaction block important?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 11:15:41 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA83856
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:15:12 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA02016;
Tue, 8 Feb 2000 11:14:46 -0500 (EST)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: hackers@postgreSQL.org
Subject: Ordering of pg_dump output
In-reply-to: <Pine.GSO.3.96.SK.1000208133713.18898A-100000@ra>
References: <Pine.GSO.3.96.SK.1000208133713.18898A-100000@ra>
Comments: In-reply-to Oleg Bartunov <oleg@sai.msu.su>
message dated "Tue, 08 Feb 2000 13:42:57 +0300"
Date: Tue, 08 Feb 2000 11:14:46 -0500
Message-ID: <2013.950026486@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Oleg Bartunov <oleg@sai.msu.su> writes:

creation of index works now. But what about pg_dump ?
I still have to edit manually dump file.
look to excerption from dump file:
CREATE TABLE "applicant" (
"candx" int2 DEFAULT next_applicant() NOT NULL,
"candidate" text,
"candt" int2,
"img" text
);
This fails because function next_applicant dumps later !

Yeah, it's a known bug. We can't just dump the functions first,
though, can we? I'm not sure how carefully function definitions
get examined by CREATE FUNCTION.

The simplest real solution I've heard so far is to dump database objects
in order by OID rather than doing it strictly by type.

Is anyone working on this, or does anyone want to? I haven't looked at
pg_dump in a while, but I know some other folks have been hacking it
recently.

regards, tom lane

From bouncefilter Tue Feb 8 11:23:29 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id LAA86407
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:22:48 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 4562 invoked by uid 1001); 8 Feb 2000 16:22:43 -0000
Date: Tue, 8 Feb 2000 11:22:43 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Hannu Krosing <hannu@tm.ee>, Bruce Momjian <pgman@candle.pha.pa.us>,
chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Globe
In-Reply-To: <1814.950025148@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.10002081121390.4432-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 8 Feb 2000, Tom Lane wrote:

Hannu Krosing <hannu@tm.ee> writes:

Vadim seens to have disappeared from earth, I hope you are not going to
remove his pin yet ;)

Certainly not --- but it needs to be moved to San Francisco ...

Did Vadim indicate that he wanted his pin moved?

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Tue Feb 8 11:30:29 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA88587
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:29:48 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA02134;
Tue, 8 Feb 2000 11:29:36 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and libpq fixes
In-reply-to: <200002081602.LAA27899@candle.pha.pa.us>
References: <200002081602.LAA27899@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 08 Feb 2000 11:02:01 -0500"
Date: Tue, 08 Feb 2000 11:29:36 -0500
Message-ID: <2131.950027376@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

This does bring up a thought --- should psql's kill-the-script-on-error
option perhaps zap the script only for errors committed outside of a
transaction block?

Why is being in a transaction block important?

I was thinking that the script might be expecting an error, and have
established a begin-block to limit the effects of the error.

But on third thought, probably the thing that would be really useful
for "expected errors" is if there is a backslash-command that turns on
or off the kill-on-error behavior. (The command line switch would
merely set the initial state of this flag.) This way, a script could
use the option in an intelligent fashion:

\kill-on-error off
DROP TABLE t1;
\kill-on-error on
CREATE TABLE t1;
...

It'd still have to default to 'off' for backwards compatibility,
unfortunately, but something like this would be really useful.

regards, tom lane

From bouncefilter Tue Feb 8 11:41:29 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA92694
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:40:36 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA29037;
Tue, 8 Feb 2000 11:38:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002081638.LAA29037@candle.pha.pa.us>
Subject: Re: [HACKERS] Ordering of pg_dump output
In-Reply-To: <2013.950026486@sss.pgh.pa.us> from Tom Lane at "Feb 8,
2000 11:14:46 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 11:38:02 -0500 (EST)
CC: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yeah, it's a known bug. We can't just dump the functions first,
though, can we? I'm not sure how carefully function definitions
get examined by CREATE FUNCTION.

The simplest real solution I've heard so far is to dump database objects
in order by OID rather than doing it strictly by type.

Is anyone working on this, or does anyone want to? I haven't looked at
pg_dump in a while, but I know some other folks have been hacking it
recently.

I thought Peter E. was thinking about it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 11:54:29 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA96653
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:53:35 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA29046;
Tue, 8 Feb 2000 11:38:53 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002081638.LAA29046@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and libpq fixes
In-Reply-To: <2131.950027376@sss.pgh.pa.us> from Tom Lane at "Feb 8,
2000 11:29:36 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 11:38:53 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

But on third thought, probably the thing that would be really useful
for "expected errors" is if there is a backslash-command that turns on
or off the kill-on-error behavior. (The command line switch would
merely set the initial state of this flag.) This way, a script could
use the option in an intelligent fashion:

\kill-on-error off
DROP TABLE t1;
\kill-on-error on
CREATE TABLE t1;
...

It'd still have to default to 'off' for backwards compatibility,
unfortunately, but something like this would be really useful.

In Informix 4GL, it is ON ERROR STOP and ON ERROR CONTINUE.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Feb 8 11:42:29 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA93201
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:42:14 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA02252;
Tue, 8 Feb 2000 11:41:59 -0500 (EST)
To: Jan Wieck <wieck@debis.com>
cc: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Deferred trigger queue
In-reply-to: <m12ICyF-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <m12ICyF-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Comments: In-reply-to wieck@debis.com (Jan Wieck)
message dated "Tue, 08 Feb 2000 16:54:31 +0100"
Date: Tue, 08 Feb 2000 11:41:58 -0500
Message-ID: <2249.950028118@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

looking at all the complications about dealing with segmented
files etc., I wonder if it's really worth the efford to add
file buffering to the trigger queue.

You shouldn't be thinking about that. Use a BufFile (see
src/include/storage/buffile.h), and you have temp file creation,
file segmentation and auto cleanup at xact abort with no more work
than fopen/fwrite would be. See nodeHash.c/nodeHashjoin.c for an
example of use.

Of course, if someone updates millions of rows in an RI
scenario during one transaction, it could blow away the
backend. But I'd prefer to leave this as a well known problem
for 7.1 and better start on creating a good regression test
and some documentation for it.

However, if you think that there are other tasks that are higher
priority than this one, I won't argue.

regards, tom lane

From bouncefilter Tue Feb 8 11:50:29 2000
Received: from gandalf.telecom.at (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA95693
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 11:50:07 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id RAA13760;
Tue, 8 Feb 2000 17:49:11 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALQYP2>; Tue, 8 Feb 2000 17:49:11 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC240@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>,
"'chris@bitmead.com'" <chris@bitmead.com>
Cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Another nasty cache problem
Date: Tue, 8 Feb 2000 17:49:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

What about portals? Doesn't psql use portals?

No ... portals are a backend concept ...

I think the previous frontend "monitor" did use a portal for the
selects. The so called "blank portal".

I don't really see any advantage, that psql does not do a fetch loop
with a portal.
Is it possible in psql do do any "fetch" stuff, after doing a
select * from table ?

The result is fed to a pager anyway.

Andreas

From bouncefilter Tue Feb 8 12:29:30 2000
Received: from icebox.org (IDENT:qmailr@icebox.org [205.198.11.50])
by hub.org (8.9.3/8.9.3) with SMTP id MAA05093
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 12:29:20 -0500 (EST)
(envelope-from gjerde@icebox.org)
Received: (qmail 30342 invoked by uid 500); 8 Feb 2000 17:23:35 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 8 Feb 2000 17:23:35 -0000
Date: Tue, 8 Feb 2000 11:23:35 -0600 (CST)
From: Ole Gjerde <gjerde@icebox.org>
To: hackers@postgreSQL.org
Subject: COPY from file
Message-ID: <Pine.LNX.4.10.10002081031510.29757-100000@snowman.icebox.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hey,
I have found what looks to be a bug in the COPY command.

This is current CVS as of monday at 7pm CST.

I have a tab delimited file(It's actually just a dump) that includes
some non-normal ascii characters, the one in question being y with 2 dots.
If the data has ANY of those in a char(or vchar) field the COPY finishes
successfully with no errors, but the table is empty. If I edit
the data file and remove that y(there was only one), it works just fine.
So basically, COPY silently dropped that line on the floor and didn't say
anything about it.

Postgres was compiled like this:
./configure --prefix=/home/postgres --with-maxbackends=128 ; make
and ran like this: postmaster -d 9 -o '-F'
on Linux 2.2.14 (Mandrake 7.0)

The above scenario happens when I just try to run on a one line data
file(which I can provide if necessary). If I try the big macdaddy file
with around 350 MB of data(and about 12 out of the 3-4 million rows has
that pesky y in it), more interesting things happen.

The backend log with -d 9 says:
FATAL 1: Socket command type (y with 2 dots goes here) unknown
NOTICE: AbortTransaction and not in in-progress state

And psql says this:
psql:parts.dump:42: Backend message type 0x45 arrived while idle
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
PQsendQuery() -- There is no connection to the backend.
PQsendQuery() -- There is no connection to the backend.
PQsendQuery() -- There is no connection to the backend.
PQsendQuery() -- There is no connection to the backend.
PQsendQuery() -- There is no connection to the backend.
PQsendQuery() -- There is no connection to the backend.
PQsendQuery() -- There is no connection to the backend.
PQsendQuery() -- There is no connection to the backend.
PQsendQuery() -- There is no connection to the backend.

2 weird things here. psql takes a good 30-40 seconds to notice that the
backend has died and I had another session(idle) of psql going, and that
backend died as well, but the postmaster was still running.

All of the data above will import just fine into 6.5.3(on the same
machine/os).

Thanks,
Ole Gjerde

From bouncefilter Tue Feb 8 12:48:30 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA08922
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 12:47:37 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA07450;
Tue, 8 Feb 2000 17:55:31 GMT
Sender: lockhart@hub.org
Message-ID: <38A05893.69CF0708@alumni.caltech.edu>
Date: Tue, 08 Feb 2000 17:55:31 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Deferred trigger queue
References: <m12ICyF-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas, where should the documentation for FOREIGN KEY go?

Depends on what the docs look like. There should be some mention of
foreign keys in the CREATE TABLE reference page
(doc/sgml/ref/create_table.sgml) and there should be some mention of
it in the User's Guide. Eventually, we will probably have a full
chapter on it (and if you want just make a file doc/sgml/foreign.sgml
and we will start). If you don't want to do that yet, plop something
in syntax.sgml.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 8 13:01:30 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA11652
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 13:00:36 -0500 (EST)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id VAA29698;
Tue, 8 Feb 2000 21:01:29 +0300 (MSK)
X-Real-To: pgsql-hackers@postgresql.org
Received: (from dms@localhost)
by woland.wplus.net (8.9.3/8.9.1/wplus.2) id VAA00438;
Tue, 8 Feb 2000 21:00:30 +0300 (MSK)
Message-ID: <XFMail.20000208210030.dms@wplus.net>
X-Mailer: XFMail 1.4.4 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.4.21.0002072312340.6572-100000@localhost.localdomain>
Date: Tue, 08 Feb 2000 21:00:30 +0300 (MSK)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Peter Eisentraut <peter_e@gmx.net>
Subject: RE: [HACKERS] psql and libpq fixes
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>

On 07-Feb-2000 Peter Eisentraut wrote:

libpq should be back to normal (printing and all). Sorry once again for
the mess.

The psql quoting issue should be fixed as well. As is usual for
hand-crafted parsers, there's probably something I overlooked, so feel
free to bring that to my attention. I haven't done anything about the
echo options yet, although I'm leaning towards "-a".

While we're at it, there's a setting that causes psql to stop execution of
a script on an error (since usually the later commands will be depending
on the successful completion of earlier ones). I was wondering if that
should be the default if you use the -f option.

No!!!
I have lots script like
drop function ....
create function
end so on

May be better going to file like
~/.pgdefaults

--
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

From bouncefilter Tue Feb 8 13:10:30 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA13769
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 13:09:43 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id SAA07509;
Tue, 8 Feb 2000 18:17:41 GMT
Sender: lockhart@hub.org
Message-ID: <38A05DC5.1F8DB63@alumni.caltech.edu>
Date: Tue, 08 Feb 2000 18:17:41 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Deferred trigger queue
References: <m12ICyF-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

And btw, I've got most of the regression tests passing with a first
cut at outer join syntax, but the rules system has breakage. Should be
OK after another pass through to clean up code, which is likely to
touch many files since a bit of the RTE structure changes.

I'd have gone ahead and committed, but figured that breaking foreign
keys would not be a step ahead for Jan ;)

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 8 13:17:30 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA15356
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 13:16:43 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id SAA07523;
Tue, 8 Feb 2000 18:24:44 GMT
Sender: lockhart@hub.org
Message-ID: <38A05F6C.B2C42E8B@alumni.caltech.edu>
Date: Tue, 08 Feb 2000 18:24:44 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Need confirmation of "Posix time standard" on FreeBSD
References: <E12Hppg-0004z6-00@sable.ox.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for the info. How do they define "the standard time zone"? Is
it *any* time zone, or "GMT", or some other set of choices?

It's "standard" in the sense of not-summer/not-daylight-savings rather
than in the "POSIX compliance" sense. In other words, std can be any
three bytes you like subject to the not-leading-colon, not-digits etc.
constraints above. Later in the section it says that summer time is
assumed to be one hour ahead of standard time if no offset follows
dst. Also,
If [an offset is] preceded by a "-"; the time zone shall be east of
the Prime Meridian; otherwise it shall be west (which may be
indicated by an optional preceding "+").
That's the bit which shows that the "+" is OK. Aha, but I've just
looked back at your original message and it refers to "GMT+0800"
whereas POSIX requires a ":" between the hours and minutes. So in
fact, "GMT+0800" is *not* legal and it should be "GMT+08:00" or
"GMT+08" or "GMT+8" (single digit hours are allowed).

OK. I'll need to generalize the current code, which looks specifically
for "gmt". Possibly, we'll have just the "GMT+/-####" case handled for
7.0, but if I get time.

And we'll allow a superset of the Posix standard, so "GMT+0800" will
be legal (otherwise, it would disallow the ISO8601 standard which imho
should take precedence).

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 8 13:58:31 2000
Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA25315
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 13:58:28 -0500 (EST)
(envelope-from mhh@nortelnetworks.com)
Received: from zrchb213.us.nortel.com (actually zrchb213)
by smtprich.nortel.com; Tue, 8 Feb 2000 12:58:17 -0600
Received: from zrtpd003.us.nortel.com ([47.140.224.137])
by zrchb213.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version
5.5.2650.21) id 1QNDP1NV; Tue, 8 Feb 2000 12:57:31 -0600
Received: from americasm01.nt.com (hrtpp28d.us.nortel.com [47.190.110.250])
by zrtpd003.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id DJLA212C; Tue, 8 Feb 2000 13:57:31 -0500
Message-ID: <38A06797.E9615CDB@americasm01.nt.com>
Date: Tue, 08 Feb 2000 13:59:35 -0500
From: "Mark Hollomon" <mhh@nortelnetworks.com>
Reply-To: "Mark Hollomon" <mhh@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Mark Hollomon <mhh@mindspring.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] docs and createlang patch for plperl
References: <20000203205112.A12565@mindspring.com>
<1889.950025634@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <mhh@americasm01.nt.com>

Tom Lane wrote:

Mark Hollomon <mhh@mindspring.com> writes:

createlang.sh.diff - a patch to add plperl
to the repertoire of createlang.sh

Good, but dare I mention that droplang needs to know about it too?

I'm sure you see no possible reason for someone to want to drop
plperl ;-) ... but it should be there.

Doooh! of course. I'll post a patch tonight.

I guess the docs for droplang and createlang need updating as well.
Unless Thomas has beat me to it.

--

Mark Hollomon
mhh@nortelnetworks.com

From bouncefilter Tue Feb 8 14:00:31 2000
Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net
[137.118.22.15]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA25815
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 14:00:15 -0500 (EST)
(envelope-from mhh@nortelnetworks.com)
Received: from zrtpd004.us.nortel.com (actually zrtpd004)
by smtprtp.ntcom.nortel.net; Tue, 8 Feb 2000 13:59:23 -0500
Received: from zrtpd003.us.nortel.com ([47.140.224.137])
by zrtpd004.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version
5.5.2650.21) id 1NWN6M24; Tue, 8 Feb 2000 13:59:23 -0500
Received: from americasm01.nt.com (hrtpp28d.us.nortel.com [47.190.110.250])
by zrtpd003.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id DJLA212G; Tue, 8 Feb 2000 13:59:22 -0500
Message-ID: <38A06805.5ED790F1@americasm01.nt.com>
Date: Tue, 08 Feb 2000 14:01:26 -0500
From: "Mark Hollomon" <mhh@nortelnetworks.com>
Reply-To: "Mark Hollomon" <mhh@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] Ordering of pg_dump output
References: <Pine.GSO.3.96.SK.1000208133713.18898A-100000@ra>
<2013.950026486@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

The simplest real solution I've heard so far is to dump database objects
in order by OID rather than doing it strictly by type.

Is anyone working on this, or does anyone want to? I haven't looked at
pg_dump in a while, but I know some other folks have been hacking it
recently.

I'll take a stab at it, if Peter E. isn't already doing it.

--

Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008

From bouncefilter Tue Feb 8 14:35:31 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id OAA34513
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 14:35:03 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m12IGFJ-0003kMC; Tue, 8 Feb 100 20:24 MET
Message-Id: <m12IGFJ-0003kMC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Ordering of pg_dump output
In-Reply-To: <2013.950026486@sss.pgh.pa.us> from Tom Lane at "Feb 8,
2000 11:14:46 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 20:24:21 +0100 (CET)
CC: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The simplest real solution I've heard so far is to dump database objects
in order by OID rather than doing it strictly by type.

Is anyone working on this, or does anyone want to? I haven't looked at
pg_dump in a while, but I know some other folks have been hacking it
recently.

Dumping by Oid or building up a framework of dependencies,
these where the options. Don't forget, SQL language functions
are (in contrast to procedural ones) parsed at CREATE time.
So any operator, aggregate or table you use inside must
exist. And they can be used in turn in many places, so it
isn't simple at all.

I think finally pg_dump must scan the entire schema two
times, first to get all the Oid's, second to dump all the
objects.

AFAIK, nobody is working on it. And starting on it right now
seems a little late to make it until BETA.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 8 14:30:31 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA33053
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 14:30:11 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA22973;
Tue, 8 Feb 2000 11:28:23 -0800 (PST)
Message-Id: <3.0.1.32.20000208112616.010bc930@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 08 Feb 2000 11:26:16 -0800
To: "Mark Hollomon" <mhh@nortelnetworks.com>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Ordering of pg_dump output
Cc: hackers@postgreSQL.org
In-Reply-To: <38A06805.5ED790F1@americasm01.nt.com>
References: <Pine.GSO.3.96.SK.1000208133713.18898A-100000@ra>
<2013.950026486@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:01 PM 2/8/00 -0500, Mark Hollomon wrote:

Tom Lane wrote:

The simplest real solution I've heard so far is to dump database objects
in order by OID rather than doing it strictly by type.

Is anyone working on this, or does anyone want to? I haven't looked at
pg_dump in a while, but I know some other folks have been hacking it
recently.

I'll take a stab at it, if Peter E. isn't already doing it.

You might want to e-mail Jan and/or Steve Szabo, who've been working
on dumping referential integrity stuff. Because tables can mutally
refer to each other, constraint dumping won't be done until data is
dumped, so the data will be loaded first when someone recreates the
database from the dump.

I was busy over the weekend working the MATCH <unspecified> and the
semantics of referential integrity actions so mostly ignored the
e-mails they traded on the subject - you'll need to get details
from them.

You need to make sure whatever you do doesn't break whatever they've
done or are doing...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Tue Feb 8 14:44:31 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id OAA36702
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 14:44:09 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12IGNw-0003kdC; Tue, 8 Feb 100 20:33 MET
Message-Id: <m12IGNw-0003kdC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Deferred trigger queue
In-Reply-To: <38A05DC5.1F8DB63@alumni.caltech.edu> from Thomas Lockhart at
"Feb
8, 2000 06:17:41 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 8 Feb 2000 20:33:16 +0100 (CET)
CC: Jan Wieck <wieck@debis.com>,
PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

And btw, I've got most of the regression tests passing with a first
cut at outer join syntax, but the rules system has breakage. Should be
OK after another pass through to clean up code, which is likely to
touch many files since a bit of the RTE structure changes.

I'd have gone ahead and committed, but figured that breaking foreign
keys would not be a step ahead for Jan ;)

FOREIGN KEYs aren't related to rules in any way. They are
implemented as triggers. So break the rule system for a while
if you feel the need.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 8 14:46:31 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id OAA37413
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 14:46:25 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12IGQ6-0003kdC; Tue, 8 Feb 100 20:35 MET
Message-Id: <m12IGQ6-0003kdC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] docs and createlang patch for plperl
In-Reply-To: <38A06797.E9615CDB@americasm01.nt.com> from Mark Hollomon at "Feb
8, 2000 01:59:35 pm"
To: Mark Hollomon <mhh@nortelnetworks.com>
Date: Tue, 8 Feb 2000 20:35:30 +0100 (CET)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Mark Hollomon <mhh@mindspring.com>,
pgsql-hackers@postgreSQL.org
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Mark Hollomon <mhh@mindspring.com> writes:

createlang.sh.diff - a patch to add plperl
to the repertoire of createlang.sh

Good, but dare I mention that droplang needs to know about it too?

I'm sure you see no possible reason for someone to want to drop
plperl ;-) ... but it should be there.

Doooh! of course. I'll post a patch tonight.

.PS
Yes, make it a NOOP. We spent so much time building these
languages, that noone should ever have the right to drop 'em again.
.PE

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 8 14:56:31 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id OAA39997
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 14:56:21 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12IGZt-0003kMC; Tue, 8 Feb 100 20:45 MET
Message-Id: <m12IGZt-0003kMC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Deferred trigger queue
In-Reply-To: <2249.950028118@sss.pgh.pa.us> from Tom Lane at "Feb 8,
2000 11:41:58 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 8 Feb 2000 20:45:37 +0100 (CET)
CC: Jan Wieck <wieck@debis.com>,
PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

wieck@debis.com (Jan Wieck) writes:

looking at all the complications about dealing with segmented
files etc., I wonder if it's really worth the efford to add
file buffering to the trigger queue.

You shouldn't be thinking about that. Use a BufFile (see
src/include/storage/buffile.h), and you have temp file creation,
file segmentation and auto cleanup at xact abort with no more work
than fopen/fwrite would be. See nodeHash.c/nodeHashjoin.c for an
example of use.

You already pointed me to that long ago. Surely, something
the like would be what to use in this case.

However, if you think that there are other tasks that are higher
priority than this one, I won't argue.

It's not that I totally want to forget about it. It's just
that I think with 7 days left until BETA I better start on
stressing the code and providing some docs instead of taking
care for possible abuse.

There are details that MUST be documented IMHO. For example
FOREIGN KEY needs that there is a UNIQUE constraint defined
on the set of referenced columns. Actually this requirement
is not checked in any way, so it MUST be mentioned in the
docs.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 8 17:45:34 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA86432
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 17:45:04 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA20153; Wed, 9 Feb 2000 09:44:27 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0tE0Ds;
Wed Feb 9 09:43:50 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA20289; Wed, 9 Feb 2000 09:43:48 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdj745R_; Wed Feb 9 09:42:50 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA17766;
Wed, 9 Feb 2000 09:42:49 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
JAA20686; Wed, 9 Feb 2000 09:42:13 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A09B8D.C8AA7C7B@nimrod.itg.telecom.com.au>
Date: Wed, 09 Feb 2000 09:41:17 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
CC: "'Tom Lane'" <tgl@sss.pgh.pa.us>,
"'chris@bitmead.com'" <chris@bitmead.com>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] Another nasty cache problem
References:
<219F68D65015D011A8E000006F8590C603FDC240@sdexcsrv1.f000.d0188.sd.spardat.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Zeugswetter Andreas SB wrote:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

What about portals? Doesn't psql use portals?

No ... portals are a backend concept ...

I think the previous frontend "monitor" did use a portal for the
selects. The so called "blank portal".

I don't really see any advantage, that psql does not do a fetch loop
with a portal.
Is it possible in psql do do any "fetch" stuff, after doing a
select * from table ?

Yes it is if you set up a cursor. I think Tom was right that psql
shouldn't use a portal just as a matter of course, because things
work differently in that case (locks?). I'm sure it could be a
useful option though.

The result is fed to a pager anyway.

Andreas

From bouncefilter Tue Feb 8 17:53:33 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA88472
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 17:53:09 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA28034 for <hackers@postgreSQL.org>;
Wed, 9 Feb 2000 09:52:36 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdZTJV2_;
Wed Feb 9 09:52:18 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA02088 for <hackers@postgreSQL.org>;
Wed, 9 Feb 2000 09:52:17 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdPLvNx_; Wed Feb 9 09:51:35 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA25219
for <hackers@postgreSQL.org>; Wed, 9 Feb 2000 09:51:34 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
JAA20866
for <hackers@postgreSQL.org>; Wed, 9 Feb 2000 09:51:00 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A09D9B.F7833335@nimrod.itg.telecom.com.au>
Date: Wed, 09 Feb 2000 09:50:03 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgreSQL.org
Subject: Re: [HACKERS] Ordering of pg_dump output
References: <Pine.GSO.3.96.SK.1000208133713.18898A-100000@ra>
<2013.950026486@sss.pgh.pa.us>
<38A06805.5ED790F1@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

The simplest real solution I've heard so far is to dump database objects
in order by OID rather than doing it strictly by type.

Hmm. Now if my OO stuff was working I guess pg_dump could be implemented
as...

List<PGObject*> dblist = pgselect("SELECT ** from object order by oid");
while (dblist.begin(); !dblist.atEnd(); dblist++) {
dblist.obj().dump();

From bouncefilter Tue Feb 8 19:08:35 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA06186
for <hackers@postgresql.org>; Tue, 8 Feb 2000 19:08:33 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62575 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S268351AbQBIAHp>;
Wed, 9 Feb 2000 01:07:45 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12IKhe-0002Pl-00; Wed, 09 Feb 2000 01:09:54 +0100
Date: Wed, 9 Feb 2000 01:09:53 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgresql.org
Subject: Re: [HACKERS] Ordering of pg_dump output
In-Reply-To: <2013.950026486@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002082356440.350-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-08, Tom Lane mentioned:

The simplest real solution I've heard so far is to dump database objects
in order by OID rather than doing it strictly by type.

AFAIR, it was your idea ... ;)

Is anyone working on this, or does anyone want to? I haven't looked at
pg_dump in a while, but I know some other folks have been hacking it
recently.

I might have been putting out remarks to that end once in a while, and I'm
still interested in it, but it would be a more extensive project, like the
psql revision, because pg_dump needs a lot of love as it stands. (I think
there are some parts still in it that allow you to dump PostQUEL.)

The problem with a pure oid-based ordering concept is that (as you
yourself pointed out) it won't work if you alter some object in question
after creation. The obvious case would be an alter function (to be
implemented), but another case is (probably) alter column set default (is
implemented).

What I'd like to do first is to draw up some (semi-)formal
(dependency-based) concept on paper and either verify it or come to the
conclusion that it will never work and then give up in disgust. ;) No,
seriously, I suppose I'll bring this up again in a couple of months when
we're ready for it.

Any collaborators are welcome of course.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 8 19:12:34 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA06983
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 19:11:36 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA03934;
Tue, 8 Feb 2000 19:11:31 -0500 (EST)
To: Ole Gjerde <gjerde@icebox.org>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] COPY from file
In-reply-to: <Pine.LNX.4.10.10002081031510.29757-100000@snowman.icebox.org>
References: <Pine.LNX.4.10.10002081031510.29757-100000@snowman.icebox.org>
Comments: In-reply-to Ole Gjerde <gjerde@icebox.org>
message dated "Tue, 08 Feb 2000 11:23:35 -0600"
Date: Tue, 08 Feb 2000 19:11:31 -0500
Message-ID: <3931.950055091@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ole Gjerde <gjerde@icebox.org> writes:

I have found what looks to be a bug in the COPY command.

Ooops. Fixed. ('char c' -> 'int c' ... EOF doesn't fit in a char ...)

regards, tom lane

From bouncefilter Tue Feb 8 19:11:34 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA06945
for <hackers@postgresql.org>; Tue, 8 Feb 2000 19:11:31 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61969 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S88118AbQBIAKw>;
Wed, 9 Feb 2000 01:10:52 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12IKkU-0002Ps-00; Wed, 09 Feb 2000 01:12:50 +0100
Date: Wed, 9 Feb 2000 01:12:50 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Ole Gjerde <gjerde@icebox.org>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] COPY from file
In-Reply-To: <Pine.LNX.4.10.10002081031510.29757-100000@snowman.icebox.org>
Message-ID: <Pine.LNX.4.21.0002090041360.350-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-08, Ole Gjerde mentioned:

I have a tab delimited file(It's actually just a dump) that includes
some non-normal ascii characters, the one in question being y with 2 dots.
If the data has ANY of those in a char(or vchar) field the COPY finishes
successfully with no errors, but the table is empty. If I edit
the data file and remove that y(there was only one), it works just fine.

Fixed it. Thanks for the report, we'd never have found that one.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 8 19:21:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA09269
for <hackers@postgreSQL.org>; Tue, 8 Feb 2000 19:21:31 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA03989;
Tue, 8 Feb 2000 19:21:09 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
Subject: Re: [HACKERS] Ordering of pg_dump output
In-reply-to: <Pine.LNX.4.21.0002082356440.350-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002082356440.350-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Wed, 09 Feb 2000 01:09:53 +0100"
Date: Tue, 08 Feb 2000 19:21:08 -0500
Message-ID: <3986.950055668@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

The problem with a pure oid-based ordering concept is that (as you
yourself pointed out) it won't work if you alter some object in question
after creation. The obvious case would be an alter function (to be
implemented), but another case is (probably) alter column set default (is
implemented).

Right; a genuine dependency analysis would be better. Also a lot more
painful to implement.

As you say, pg_dump could do with a wholesale rewrite, and maybe that
would be a good time to look at the dependency-based approach. In the
meantime, I think dumping in OID order would fix 90% of the problem for
10% of the work...

regards, tom lane

From bouncefilter Tue Feb 8 19:22:36 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA09280
for <hackers@postgresql.org>; Tue, 8 Feb 2000 19:21:35 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62559 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S245823AbQBIAUq>;
Wed, 9 Feb 2000 01:20:46 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12IKuH-0002QQ-00; Wed, 09 Feb 2000 01:22:57 +0100
Date: Wed, 9 Feb 2000 01:22:57 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Ole Gjerde <gjerde@icebox.org>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] COPY from file
In-Reply-To: <Pine.LNX.4.21.0002090041360.350-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0002090122170.350-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

Okay, somebody beat me to it. Seems we can't fix these bugs fast enough.
;)

On 2000-02-09, Peter Eisentraut mentioned:

On 2000-02-08, Ole Gjerde mentioned:

I have a tab delimited file(It's actually just a dump) that includes
some non-normal ascii characters, the one in question being y with 2 dots.
If the data has ANY of those in a char(or vchar) field the COPY finishes
successfully with no errors, but the table is empty. If I edit
the data file and remove that y(there was only one), it works just fine.

Fixed it. Thanks for the report, we'd never have found that one.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 8 20:00:37 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA19818;
Tue, 8 Feb 2000 20:00:18 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id TAA54872;
Tue, 8 Feb 2000 19:42:29 -0500 (EST) (envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "Javi Pi���ol" <enfris@wanadoo.es>
X-Newsgroups: 3b.misc, comp.databases.postgresql.hackers,
comp.databases.postgresql.interfaces,
comp.databases.postgresql.patches,
comp.databases.postgresql.ports,
comp.databases.postgresql.questions,
comp.databases.postgresql.sql, comp.databases.progress,
comp.dcom.la
Subject: POR FIN DINERO REAL SIN TRAMPAS
Lines: 321
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <QH2o4.2582$3U5.29987@m2newsread.uni2.es>
Date: Wed, 09 Feb 2000 00:40:16 GMT
X-Complaints-To: abuse@uni2.es
X-Trace: m2newsread.uni2.es 950056816 62.36.128.120 (Wed,
09 Feb 2000 01:40:16 MET)
Organization: Wanadoo WebNews - Visita http://www.wanadoo.es
To:
pgsql-hackers@postgresql.org.pgsql-interfaces@postgresql.org.pgsql-patches@postgresql.org.pgsql-ports@postgresql.org.pgsql-sql@postgresql.org.pgsql-questions@postgresql.org

!!!IMPRIME ESTA HOJA ...YAAAAAAAAAAA!!!

Perm���teme empezar diciendo que FINALMENTE LO ENCONTRE !!!. En serio!, lo
encontr���!. Y eso que odio todos esos
ESQUEMAS DE HACERTE RICO RAPIDO!!!. Odio esos esquemas de marketing con
varios niveles, o de hacer ���rdenes
por correo, o poniendo propaganda en sobre de correo, etc., la lista es
interminable.
Prob��� todos esos malditos esquemas de hacerte rico r���pido durante 5 a���os y
hasta quede "enganchado" en una lista de est���pidos que quieren hacer
dinero r���pido probando cualquier cosa. Pero bueno, son cosas de esa edad, y
esa
frase diciendo que podr���a ser rico r���pido me sonaba irresistible!.Estaba
desesperado por dinero!! Les di a cada uno de ellos un chance y todos y
cada uno de ellos fallaron!. Tal vez son buenos esquemas para algunos, pero
seguro no lo fue para m���. Eventualmente, tiraba todo eso a la basura
cuando recib��� este documento. Pude reconocerlo enseguida. Puedo "oler"
dinero a
un kil���metro de distancia estos d���as, sab���a que iba a ser relativamente
f���cil
y no estuve equivocado .... AMO EL INTERNET ... Estaba chequeando el
NEWSGROUP cuando vi un art���culo que dec���a de CONSEGUIR DINERO RAPIDO!!.
Pense ...
"EN EL INTERNET??. Bueno, tengo que ver que tipo de esquema pueden presentar
en
el Internet". Este art���culo describ���a la manera de mandar POR CORREO UN
BILLETE DE US$ 1.00 A SOLO SEIS PERSONAS Y GANAR US$ 50.000.00 EN EFECTIVO
EN 4>
SEMANAS!!!. Bueno, cuanto m���s pens��� acerca de esto m���s curioso me pon���a,?
por qu���?, por la manera en que esto trabajaba y PORQUE SOLO IBA A
COSTARME US$ 6.00 (Y SEIS ESTAMPILLAS), Y ESO ERA TODO LO QUE TENIA QUE
PAGAR ... Y
NADA MAS!!!. O.K., los US$ 50.000.00 en efectivo pod���a ser una punto alto
de alcanzar, pero era posible. Me figur��� que tal vez pod���a tener un alcance
de $1.000.00 mas o menos as��� que lo hice!!!. Como
dec���an las instrucciones en el art���culo, mand��� por correo un billete de un
d���lar a cada uno de las seis personas en la lista que conten���a el
articulo.
Inclu��� una peque���a nota que dec���a "POR FAVOR INCLUYAME EN SU LISTA" junto
con el d���lar. Luego rehice la lista en donde saque al primero, mov��� una
posici���n arriba a cada uno de los restantes e inclu��� mi nombre al final de
ella. Esta fue la forma de lograr que el dinero comenzara a llegarme!!.
Luego tom��� esta lista que acababa de modificar y la RE- PUBLIQUE EN TODOS
LOS NEWSGROUPS Y BBS LOCALES QUE CONOCIA y espere que el dinero empezara a
llegarme,preparada para recibir entre $1.000 y $1.500 en efectivo. Pero
que agradable sorpresa cuando todos esos sobres empezaron a llegarme !!!.
Supe
enseguida de que se trataban cuando vi que las direcciones de retorno
provenian de todas partes del mundo, la mayor���a de Estados Unidos, Canada
y Australia!. En mi primera semana hice unos 20.00 a 30.00 d���lares. Para el
final de la segunda semana ten���a hecho un total de m���s de US$ 1000.00!!!!!
En la tercera semana recib��� m���s de U$S 10,000.00 y todav���a segu���a llegando
m���s. Esta es mi cuarta semana y ya recib��� un total de US$ 23.343.00
!!!!!!FUE EXCITANTE!!! !!!No lo pod���a creer!!!
Tienes que seguirlo y re-publicarlo donde te sea posible, cuanto m���s se
publique y m���s gente lo vea, habr��� m���s posibilidades para todos de ganar
m���s dinero, esto determinar��� cu���nto te llegar��� por correo!!!. Es realmente
f���cil de pasarlo...
Revisemos las razones de por que hacerlo: los unicos gastos son 6
estampillas, 6 sobres y 6 d���lares (un billete de UN d���lar para cada uno en
la lista), luego re-publicar el artculo con tu nombre incluido en���todos
los NEWSGROUPS o BBS que se te ocurran (esto es gratis) y luego esperar por
los sobre que te lleguen. Todos tenemos 6 d���lares para gastar en una
inversi���n
f���cil y que no envuelve ning���n tipo de esfuerzo con UNA ESPECTACULAR
RECOMPENZA DE ENTRE US$ 15.000.00 Y US$ 120.000.00 en solo 3 a 5 semanas!.
As��� que private de jugar a la loteria hoy, o mejor come en casa en vez de
ir afuera e invierte esos 6 d���lares en esto que puede darte una grata
sorpresa!!!. No hay forma de perder !!! Como funciona esto exactamente???,
cuidadosamente proveo la m���s detalladas y simples instrucciones de como
vas a conseguir que te llegue dinero f���cil. Prep���rate para lograrlo, esta es
la forma...
************************************************************
LISTA DE NOMBRES -- LISTA DE NOMBRES -- LISTA DE NOMBRES
*********************************************************************
1. Nicolas Arancibia Roman
Lidice 749-B
Poblacion Esperanza
Rancagua
CHILE

2. Rodrigo G���mez Zamorano
Duble Almeyda # 3074 Departamento 201
���u���oa - Santiago
CHILE

3. Sergio Rodr���guez Asensio
C/Dr Mara������n 11 2A
03610 Petrer (Alicante)
ESPA���A

4. Nacho Escudero Fernandez
c/ Islas Cies 55 6��� G
28035 Madrid
ESPA���A

5. Rosa Company Valverde
c/ Perez Dolz n���7 6��� D
12003 Castell���n
ESPA���A

6. Javier Pi���ol Rey
Apartado de Correos 1148
25080 Lleida
ESPA���A

O.K. lee esto cuidadosamente. No es que sea necesario, pero es una buena
idea de imprimirlo como referencia en el caso de que tengas dudas.
INSTRUCCIONES
1. En una pagina en blanco escribe lo siguiente:
"POR FAVOR INCLUYA MI NOMBRE EN SU LISTA" ("PLASE ADD MY NAME TO YOUR
LIST"). Esto autom���ticamente genera un servicio y como tal, lo hace
COMPLETAMENTE
LEGAL.
A partir de ahora no estas mandandole UN DOLAR a alguna persona sin ning���n
motivo, estas pagando UN>
DOLAR por un legi���timo servicio.
Asegurate de incluir tu nombre y direcci���n. Te aseguro, de nuevo, que esto
es completamente legal!. Como un lindo detalle pon tambi���n en que posici���n
cada nombre figuraba cuando mandastes tu dolar: ("Estabas en la posici���n
3") o ("You were in slot 3") como para hacerlo mas completo!!!.De eso se
trata, de hacer dinero y pasarla bien al mismo tiempo.
2.Ahora dobla esta p���gina escrita alrededor del billete de UN DOLAR (no
mandes cheques ni otro tipo de pago, SOLO BILLETES DE UN DOLAR AMERICANO),
ponlo todo dentro de un sobre y mandalo a cada uno de las 6 personas
listadas. La idea de doblar el papel alrededor del billete es para
asegurar que va a llegar a destino y ESTO ES IMPORTANTE!!!. (De otra manera
la
gente que trabaja en el correo podr���a detectar que se trata de dinero y
quedarse
con los miles de sobre que van llegando!!!). para m���s seguridad, usa
tambi���n una hoja de papel carb���n para envolver el billete, de ese modo sera
mucho
mas dificil ver lo que va dentro.
3.Escucha con cuidado, esta es la forma de como vas a recibir dinero por
correo. Mira la lista de las seis personas, borra el primer nombre y
agrega el tuyo al final de ella, asi que el que era numero 2 pasa a ser
numero 1,
el que era 3 pasa a ser 2, el que era 4 pasa a ser 3, el que era 5 pasa a
ser 4 etc. y t��� eres ahora el numero seis. Incluye tu nombre, direcci���n,
c���digo postal y pa���s.
4. Ahora publica este articulo en por lo menos 200 "newsgroups" (existen
mas de 24,000 grupos). S���lo necesitas 200, pero cuanto m���s cantidad ponga,
m���s
dinero te llegar���!!!, si conoces BBS (Bulletin Board Systems) locales con
���reas de mensajes, etc., en donde se te ocurra (recuerda que es
LEGAL).Cuando publiques la descripci���n de este articulo, trata de darle un
nombre que "atrape", como: "NECESITA DINERO RAPIDO?, LEA ESTE ARTICULO",
"NECESITA DINERO PARA PAGAR SUS DEUDAS???", etc. Y cuanto m���s se publique
m���s posibilidades de recibir mas dinero vas a tener, adem���s les das la
oportunidad a otras personas que est���n interesadas de hacer dinero.
!!!HAGAMOS EL COMPROMISO DE SER HONESTOS Y CUMPLIR CON LO LEGAL,PONIENDO
UN 120 POR CIENTO DE NOSOTROS PARA QUE ESTE SISTEMA FUNCIONE !!!. Te
sorprender���s de
los beneficios, cr���eme!!!.
5. Si tienes problemas para publicarlo en tu BBS local simplemente
preg���ntale al SYSOP (Operador del Sistema) como publicar en ese NEWSGROUP,
lo mismo en el caso de publicarlo en el Internet. Si tratara de explicarlo
en este articulo seria para problemas, por hay demasiados programas
distintos y al detallar uno o dos de ellos, podr���a crearle problemas al
que tiene otro distinto. La descripci���n del articulo cuando se lo publique
deber���a decir algo as��� como:
"BAJE ESTE ARCHIVO Y LEA COMO PUEDE RECIBIR DINERO POR CORREO". No as���:
"GANE MILLONES DE DOLARES EN DOS DIAS POR CORREO" porque nadie te va a
responder ...
Aqu��� van a algunas indicaciones de c���mo introducirse en los "newsgroups":
COMO MANEJAR LOS "NEWSGROUPS"
No.1> Ud. no necesita redactar de nuevo toda esta carta para hacer la suya
propia. Solamente ponga su cursor al comienzo
de esta carta, haga click, lo deja presionado y b���jelo hasta el final de
la carta y l���rguelo. Toda la carta deber��� estar "sombreada". Entonces haga
click en "Edit"(Editar) arriba de su pantalla, aqu��� seleccione
"Copy"(Copiar). Esto har��� que toda la carta quede en la memoria de su
computador.
No.2> Abra una nueva p���gina en blanco y lleve el cursor al inicio.
Presione "Edit" y del men��� seleccione "Paste"(Pegar). Ahora tendr��� esta
carta en el
"notepad" y podr��� agregar su nombre y direcci���n en el lugar #6 siguiendo
las instrucciones de m���s arriba.
No.3> Grabe esta carta en su nuevo archivo del notepad como un .txt
file.(Archivo de Texto). Ycada vez que quiera cambiar algo lo podr��� hacer.
PARA LOS QUE MANEJAN NETSCAPE
No.4> Dentro del programa Netscape, vaya a "Communicator" y seleccione
"Grupo de noticias", luego vaya a "Archivo" y seleccionar "Suscribir". En
segundos una lista de todos los "Newsgroups" de su "server" aparecer���.
Haga click en cualquier newsgroup. De este newsgroup haga click debajo de
"TO
NEWS", el cual deberia estar arriba, en el extremo izquierdo de la p���gina
newsgroups. Esto le llevar��� a la caja de mensajes.
No.5> Llene este espacio. Este ser��� el t���tulo que ver���n todos cuando
recorran por la lista de un grupo en particular.
No.6> Marque el contenido completo del archivo y copie usando la misma
NEWS" y Ud. est��� creando y empastando esta carta dentro de su programa o
"posting".
No.7> Presione "send" que est��� en la parte superior izquierda. Y UD. HA
FINALIZADO CON SU PRIMERO!...FELICITACIONES!!! .
LOS QUE USAN INTERNET EXPLORER
PASO No. 4: Vaya al Newsgroups y seleccione "Post an Article". O en
Clasificados seleccione "poner un Anuncio". O en los
Foros de Discusion, etc.
PASO No. 5: Copie el art���culo del notepad y peguelo en el lugar del texto
que va a enviar o anunciar. Utilice la misma tecnica
anterior.
PASO No. 7: Presione el bot���n "Post", "Enviar" o "Poner", etc..
--------------------------------------------------------
ES TODO!. Todo lo que tiene que hacer es meterse en diferentes
"Newsgroups" y empastarlos, cuando ya tenga pr���ctica,
solo le tomar��� unos 30 segundos por cada newsgroup! **RECUERDE, CUANTOS
MAS NEWSGROUPS CONSIGA,
MAS RESPUESTAS (Y DINERO) RECIBIRA!! PERO DEBE DE ENTRAR EN POR LO MENOS
200** YA ESTA!!!.... Ud. estar��� recibiendo dinero de todo el mundo, de
lugares que
ni conoce y en unos pocos d���as!. Eventualmente
querr��� arrendar una casilla de correo por la cantidad de sobres que ir���
recibiendo.
**ASEGURESE DE QUE TODAS LAS DIRECCIONES ESTEN CORRECTAS**
Ahora el POR QUE de todo esto: De 200 enviados, digamos que recibo s���lo 5
respuestas (baj���simo ejemplo).Entonces hice US$ 5.00 con mi nombre en la
posici���n #6 de esta carta.
Ahora,cada uno de las 5 personas que ya me enviaron US$ 1.00 tambi���n hacen
un
m���nimo 200 newsgroups, cada uno con mi nombre en el #5 de la lista y s���lo
responden 5 personas a cada uno de los 5 originales, esto hace US$ 25.00 m���s
que yo
recibo, ahora estas 25 personas pone un m���nimo de
200 Newsgroups con mi nombre en el #4 y s���lo se recibe 5 respuesta de cada
uno. Estar���a haciendo otros US$ 125.00 adicionales. Ahora esta 125 personas
ponen sus m���nimo de 200 grupos con mi
nombre en el #3 y s���lo reciben 5 respuestas cada una, yo recibo un
adicional de US$ 625.00!. OK, aqu��� esta la parte m���s divertida, cada una de
estas
625 personas ponen sus cartas en otros 200 grupos con mi nombre en el #2 y
cada una recibe s���lo 5 respuestas, esto hace que yo reciba US$ 3,125.00!!!.
Estas 3,125 personas enviar���n este mensaje a un m���nimo de 200 Newsgroup nomb
re en
el #1 y si solo 5 personas reResponden de los 200 grupos, estar��� recibiendo
US$ 15,625.00!!. De una inversion original de US$6.00!! mas estampillas.
FABULOSO! Y como dije antes, que solo 5 personas respondan muy poca, el
promedio real seria 20 o 30 personas!. Asi que pongamos un n���mero m���s
grande
para calcular. Si solo 15 personas responden, esto hace:
En la #6---------US$ 15.00
En la #5---------US$ 225.00
En la #4---------US$ 3,375.00
En la #3---------US$ 50,625.00
En la #2---------US$ 759,375.00
En la #1---------US$ 11,390,625.00 s���, m���s de ONCE MILLONES DE D���LARES!!!.
Una vez que su nombre ya no est��� en la lista, saque el ultimo anuncio del
Newsgroup y envie otros US$ 6.00 a los nombres en
esa lista, poniendo su nombre en el #6 y repetir todo el proceso. Yempezar
a ponerlos en los Newsgroups otra vez. Lo que
debe recordar es que miles de personas mas, en todo el mundo, se conectanal
Internet cada d���a y leer���n estos art���culos todos
los d���as como USTED Y YO LO HACEMOS!!!. As��� que creo nadie tendria
problemas en invertir US$ 6 .00 y ver si realmente esto funciona. Algunas
personas
llegan a pensar..."y si nadie decide contestarme?" Que!! Cu���l es la
probabilidad de que esto pas��� cuando hay miles y miles de personas (como
nosotros) que buscan una manera de tener independencia financiera y pagar
sus deudas!!!., y est���n dispuestas a tratar, pues "No hay peor lucha de la
que no se hace". Se estima que existen de 20,000 a 50.000 nuevos usuarios
en Internet TODOS LOS DIAS!
*******OTRO SISTEMA PARA COMUNICARSE ES CONSIGUIENDO E-MAIL DE PERSONAS
PARTICULARES, DEBE SER POR LO MENOS 200 DIRECCIONES, PERO ESTO TIENE UNA
EFECTIVIDAD DE MINIMO 5% AL 15%.
SI SOLO BUSCAN PERSONAS QUE HABLAN EN ESPA���OL, VAYAN A UN PROVEEDOR DE
E-MAILS E IMPRIMAN UN APELLIDO LATINO Y YA!!!
Recuerde de hacerlo esto en forma CORRECTA , LIMPIA Y HONESTAMENTE y
funcionar��� con toda seguridad. Solamente tiene que ser honesto. Asegurese
de imprimir este art���culo AHORA, trate de mantener la lista de todos
los que les envian dinero y siempre f���jese en los Newsgroups y vea si
todos est���n participando limpiamente
Recuerde, HONESTIDAD ES EL MEJOR METODO..
No necesitas hacer trucos con la idea b���sica de hacer dinero en esto!
BENDICIONES PARA TODOS y suerte, juguemos limpio y aprovechar esta hermosa
oportunidad de hacer toneladas de dinero en Internet
.**Dicho sea de paso, si Ud. defrauda a las personas poniendo mensajes con
su nombre y no envia ning���n dinero a los dem���s
en esa lista, Ud. recibir��� casi NADA!.
"LOS FRUTOS DE LA HONESTIDAD SE RECOGEN EN MUY POCO TIEMPO Y DURAN PARA
SIEMPRE" PROVERVIO CHINO.
He conversado con personas que conocieron personas que hicieron eso y
llegaron a recibir US$ 15.00 en unas 7 semanas!!!
Algunos decidieron probar otra vez, haciendolo correctamente, y en 4 a 5
semanas recibieron m���s de $10.000. Esto es la mas
limpia y honesta manera de compartir fortuna que yo jam���s haya visto, sin
costarnos mucho excepto un poco de tiempo. El
TIEMPO ES IMPORTANTE!, no dejar pasar mas de 7 d���as del momento que vea
este art���culo!. Tambi���n puede conseguir
lista de E-MAIL para extra d���lares. Sigamos todos las reglas del negocio!
Recuerde mencionar esta ganancias extras en sus
declaraciones de impuestos.
6. Y este es el paso que mas me gusta. SIMPLEMENTE SI���NTATE Y DISFRUTA,
PORQUE EL EFECTIVO VIENE EN CAMINO!!!. Espera ver un poquito de dinero
durante la segunda semana, pero a partir de la tercera semana TORMENTA DE
SOBRES EN TU CORREO. Todo lo que tienes que hacer es recibirlo y trata de
no gritar muy fuerte cuando te des cuenta de que esta vez lo lograstes !!
7. Es tiempo de pagar lo que deb���as y comprar algo especial para t��� o para
esa persona especial en tu vida, un regalo que nunca olvidaras.Disfruta de
la vida !!!
8. Cuando te empieces a quedar corto de dinero, reactiva este archivo y
re-publicalo en los mismos lugares en que lo vas a hacer ahora y nuevos
lugares que conocer���s en el futuro. Siempre mantiene a mano una copia de
este art���culo, react���valo cada vez que necesites dinero. ES UNA
HERRAMIENTA INCREIBLE QUE PUEDES VOLVER A USAR CUANTAS VECES NECESITES
DINERO EN
EFECTIVO.

HONESTIDAD ES LO QUE HACE TRIUNFAR A ESTE PROGRAMA ...NO LO OLVIDES

!!!BUENA SUERTE!!!

From bouncefilter Tue Feb 8 21:09:36 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA44505
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 21:08:50 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
NAA27860 for <pgsql-hackers@postgreSQL.org>;
Wed, 9 Feb 2000 13:07:05 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd69l9z_;
Wed Feb 9 13:06:33 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
NAA29931 for <pgsql-hackers@postgreSQL.org>;
Wed, 9 Feb 2000 13:06:31 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd05_7sh; Wed Feb 9 13:05:28 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA21239
for <pgsql-hackers@postgreSQL.org>;
Wed, 9 Feb 2000 13:05:27 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
NAA25034
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 13:04:51 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A0CB0B.73985430@nimrod.itg.telecom.com.au>
Date: Wed, 09 Feb 2000 13:03:55 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Regression tests
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Let's say I want to write regression tests to ensure that everything
related to inheritance works. One test I would want would be to make
sure pg_dump works for inheritance. What is the preferred way to make
regression tests which aren't sql?

From bouncefilter Tue Feb 8 21:50:36 2000
Received: from fb01.eng00.mindspring.net (fb01.eng00.mindspring.net
[207.69.229.19]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA56052
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 21:50:01 -0500 (EST)
(envelope-from mhh@mindspring.com)
Received: from mars (user-2inilpd.dialup.mindspring.com [165.121.87.45])
by fb01.eng00.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA32163
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 21:49:48 -0500 (EST)
Received: from mhh by mars with local (Exim 3.12 #1 (Debian))
id 12IMW4-0007B3-00
for <pgsql-hackers@postgresql.org>; Tue, 08 Feb 2000 21:06:04 -0500
Date: Tue, 8 Feb 2000 21:06:03 -0500
To: pgsql-hackers@postgresql.org
Subject: plperl droplang patch
Message-ID: <20000208210603.A27586@mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
From: Mark Hollomon <mhh@mindspring.com>

Here is the patch to add plperl to droplang.

*** droplang.old	Tue Feb  8 21:00:34 2000
--- droplang	Tue Feb  8 21:02:27 2000
***************
*** 159,167 ****
  		lancomp="PL/Tcl"
  		handler="pltcl_call_handler"
                  ;;
  	*)
  		echo "$CMDNAME: unsupported language '$langname'"
! 		echo "Supported languages are 'plpgsql' and 'pltcl'."
  		exit 1
                  ;;
  esac
--- 159,171 ----
  		lancomp="PL/Tcl"
  		handler="pltcl_call_handler"
                  ;;
+ 	plperl)
+ 		lancomp="PL/Perl"
+ 		handler="plperl_call_handler"
+                 ;;
  	*)
  		echo "$CMDNAME: unsupported language '$langname'"
! 		echo "Supported languages are 'plpgsql', 'pltcl', and 'plperl'."
  		exit 1
                  ;;
  esac

--
Mark Hollomon
mhh@mindspring.com

From bouncefilter Tue Feb 8 21:34:36 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA52843
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 21:34:28 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA01126
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 18:33:16 -0800 (PST)
Message-Id: <3.0.1.32.20000208183105.0108bd60@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 08 Feb 2000 18:31:05 -0800
To: pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: minor bug...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

create table foo(b boolean);
create index foo_index on foo(b);

You get a "no default operator for type 16." error...

This ecommerce datamodel I'm porting over uses such indices
frequently, apparently to grab small subsets of large tables which
have few rows with the predicate set to one state. Even if such
an index might be of dubious usefulness in situations where
the table's population is more evenly split, there's no real
reason not to support indexes on booleans, is there?

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Tue Feb 8 21:37:36 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA53223
for <pgsql-hackers@postgresql.org>; Tue, 8 Feb 2000 21:36:41 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA12382
for <pgsql-hackers@postgresql.org>; Wed, 9 Feb 2000 11:36:39 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id LAA02692
for <pgsql-hackers@postgresql.org>; Wed, 9 Feb 2000 11:36:38 +0900
To: pgsql-hackers@postgresql.org
Subject: VxWorks ports?
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000209113638B.t-ishii@sra.co.jp>
Date: Wed, 09 Feb 2000 11:36:38 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 6

Has anybody heard of porting PostgreSQL on VxWorks (a realtime OS)? I
know that someone ported libpq on it, but am interested in the
backend. VxWorks has socket, file io and signal but not fork etc.
Moreover, it has no VM. That make me pessimistic.
--
Tatsuo Ishii

From bouncefilter Tue Feb 8 21:55:36 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA59839
for <pgsql-hackers@postgreSQL.org>; Tue, 8 Feb 2000 21:55:05 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA09510;
Wed, 9 Feb 2000 03:02:40 GMT
Sender: lockhart@hub.org
Message-ID: <38A0D8D0.CED12079@alumni.caltech.edu>
Date: Wed, 09 Feb 2000 03:02:40 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: chris@bitmead.com
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Regression tests
References: <38A0CB0B.73985430@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Let's say I want to write regression tests to ensure that everything
related to inheritance works. One test I would want would be to make
sure pg_dump works for inheritance. What is the preferred way to make
regression tests which aren't sql?

This has come up just recently, and afaik we don't have a precedence
for it in the current regression tests.

I would advocate having another test fired by the Makefile, to
minimize the number of components which need to be running for the
fundamental tests using psql to work.

"make all" currently *builds* the tests
"make runtest" currently runs the basic tests
"make bigtest" runs the large numeric tests
"make runcheck" runs the parallel tests
...

The basic inheritance tests should be in the basic regression test.
But how about something like "make dumptest"...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Wed Feb 9 00:25:38 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA90610
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 00:24:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA04553;
Wed, 9 Feb 2000 00:23:51 -0500 (EST)
To: chris@bitmead.com
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Regression tests
In-reply-to: <38A0D8D0.CED12079@alumni.caltech.edu>
References: <38A0CB0B.73985430@nimrod.itg.telecom.com.au>
<38A0D8D0.CED12079@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Wed, 09 Feb 2000 03:02:40 +0000"
Date: Wed, 09 Feb 2000 00:23:50 -0500
Message-ID: <4550.950073830@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Let's say I want to write regression tests to ensure that everything
related to inheritance works. One test I would want would be to make
sure pg_dump works for inheritance. What is the preferred way to make
regression tests which aren't sql?

This has come up just recently, and afaik we don't have a precedence
for it in the current regression tests.

No, there are no formalized tests at all that exercise pg_dump.

The informal test that's been around for a while is to pg_dump
the regression database, load into a fresh DB, pg_dump again,
and compare the second dump's output to the first's. But there's
no automation for this, and I'm not sure you can really expect
the resulting scripts to be bit-for-bit the same anyway (there
might be ordering differences).

If you feel like developing a more believable testing strategy
for pg_dump, ain't nobody gonna get in your way.

regards, tom lane

From bouncefilter Wed Feb 9 01:20:39 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA08056
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 01:19:44 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id PAA00213; Wed, 09 Feb 2000 15:18:40 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: <chris@bitmead.com>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Bug in cursors??
Date: Wed, 9 Feb 2000 15:24:41 +0900
Message-ID: <001c01bf72c6$59413540$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <200002081416.JAA24958@candle.pha.pa.us>

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]

[Charset iso-8859-1 unsupported, filtering to ASCII...]

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Tuesday, February 08, 2000 6:16 PM

Hiroshi, do you need this applied?

Oops,this patch is old,sorry.
Another patch may be needed.

DO you think this patch should also be applied to REL tree ?
If so,could you please apply it to both trees ?
Otherwise I would commit it only to current tree myself.

I don't think we are doing more 6.5.* releases

OK,I have committed the patch to current tree.

BTW I found the following TODO item.
* update pg_class.relhasindex during vacuum when all indexes are dropped

Seems vacuum has done so from the first.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Feb 9 01:53:39 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA44665
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 01:53:37 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA26428 for <pgsql-hackers@postgreSQL.org>;
Wed, 9 Feb 2000 17:52:56 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdAQl3r_;
Wed Feb 9 17:52:48 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA20822 for <pgsql-hackers@postgreSQL.org>;
Wed, 9 Feb 2000 17:52:47 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd03cAHB; Wed Feb 9 17:51:45 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA16908
for <pgsql-hackers@postgreSQL.org>;
Wed, 9 Feb 2000 17:51:44 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
RAA01501
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 17:51:10 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A10E24.3A52DFF8@nimrod.itg.telecom.com.au>
Date: Wed, 09 Feb 2000 17:50:13 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: backend startup
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is there any particular reason why a backend has to be started by the
postmaster unless it is the only backend running (in debug mode) ?

I'm thinking here that

(a) It would be more convenient to debug if you didn't have to shut down
the postmaster to run gdb postgres and...

(b) If that were the case you be part-way to implementing a
single-process database option like some databases have.

What are the issues? Finding the shared memory etc perhaps?

From bouncefilter Wed Feb 9 02:52:40 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA38839
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 02:52:19 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA04860;
Wed, 9 Feb 2000 02:51:38 -0500 (EST)
To: chris@bitmead.com
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] backend startup
In-reply-to: <38A10E24.3A52DFF8@nimrod.itg.telecom.com.au>
References: <38A10E24.3A52DFF8@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Wed, 09 Feb 2000 17:50:13 +1100"
Date: Wed, 09 Feb 2000 02:51:38 -0500
Message-ID: <4857.950082698@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Is there any particular reason why a backend has to be started by the
postmaster unless it is the only backend running (in debug mode) ?

If you don't have a postmaster then the backend is running standalone,
which is not really the same environment as running in a live
installation. It's OK for some kinds of debugging but I wouldn't
trust it an inch for locking or resource-related issues.

(a) It would be more convenient to debug if you didn't have to shut down
the postmaster to run gdb postgres and...

Say what? I've never yet shut down the postmaster to gdb anything;
I tell gdb to "attach" to a running backend started by the postmaster.
(See thread a couple weeks ago on exactly this point.) The major
advantage of that way of working is you can use a reasonable client
(psql or whatever floats your boat) instead of having to type queries
directly at a backend that has no input-editing or command history
support. There's also no question about whether you're running in
a realistic environment or not. Finally, you can fire up an additional
client+backend to examine the database even when you've got the backend
under test stopped somewhere (so long as it's not stopped holding a
spinlock or anything like that). If it weren't for the needs of initdb,
I think standalone-backend mode would've gone the way of the dodo
some time ago...

regards, tom lane

From bouncefilter Wed Feb 9 03:18:40 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA82697
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 03:17:58 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id RAA04895;
Wed, 9 Feb 2000 17:17:56 +0900 (JST)
Received: from localhost (IDENT:t-ishii@srapc968-yotsuya [133.137.36.133])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id RAA07289;
Wed, 9 Feb 2000 17:17:53 +0900
To: t-ishii@sra.co.jp
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-Reply-To: <20000207212856U.t-ishii@sra.co.jp>
References: <20000206230412X.t-ishii@sra.co.jp>
<24481.949852063@sss.pgh.pa.us>
<20000207212856U.t-ishii@sra.co.jp>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000209172202B.t-ishii@sra.co.jp>
Date: Wed, 09 Feb 2000 17:22:02 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 102

BTW, Hiroshi has noticed me an excellent point #3:

Session-1
begin;
update A ...;

Session-2
begin;
select * fromB ..;
There's no PostgreSQL shared buffer available.
This backend has to force the flush of a free buffer
page. Unfortunately the page was dirtied by the
above operation of Session-1 and calls pg_fsync()
for the table A. However fsync() is postponed until
commit of this backend.

Session-1
commit;
There's no dirty buffer page for the table A.
So pg_fsync() isn't called for the table A.

Seems there's no easy solution for this. Maybe now is the time to give
up my idea...

Thinking about a little bit more, I have come across yet another
possible solution. It is actually *very* simple. Details as follows.

In xact.c:RecordTransactionCommit() there are two FlushBufferPool
calls. One is for relation files and the other is for pg_log. I add
sync() right after these FlushBufferPool. It will force any pending
kernel buffers physically be written onto disk, thus should guarantee
the ACID of the transaction (see attached code fragment).

There are two things that we should worry about sync, however.

1. Does sync really wait for the completion of data be written on to
disk?

I looked into the man page of sync(2) on Linux 2.0.36:

According to the standard specification (e.g., SVID),
sync() schedules the writes, but may return before the
actual writing is done. However, since version 1.3.20
Linux does actually wait. (This still does not guarantee
data integrity: modern disks have large caches.)

It seems that sync(2) blocks until data is written. So it would be ok
at least with Linux. I'm not sure about other platforms, though.

2. Are we suffered any performance penalty from sync?

Since sync forces *all* dirty buffers on the system be written onto
disk, it might be slower than fsync. So I did some testings using
contrib/pgbench. Starting postmaster with -F on (and with sync
modification), I ran 32 concurrent clients with performing 10
transactions each. In total 320 transactions are performed. Each
transaction contains an UPDATE and a SELECT to a table that has 1000k
tuples and an INSERT to another small table. The result showed that -F
+ sync was actually faster than the default mode (no -F, no
modifications). The system is a Red Hat 5.2, with 128MB RAM.

-F + sync normal mode
--------------------------------------------------------
transactions/sec 3.46 2.93

Of course if there are disk activities other than PostgreSQL, sync
would be suffered by it. However, in most cases the system is
dedicated for only PostgreSQL, and I don't think this is a big problem
in the real world.

Note that for large COPY or INSERT was much faster than the normal
mode due to no per-page-fsync.

Thinking about all these, I would like to propose we add a new switch
to postgres to run with -F + sync.

------------------------------------------------------------------------
/*
* If no one shared buffer was changed by this transaction then
* we don't flush shared buffers and don't record commit status.
*/
if (SharedBufferChanged)
{
FlushBufferPool();
sync();
if (leak)
ResetBufferPool();

/*
* have the transaction access methods record the status
* of this transaction id in the pg_log relation.
*/
TransactionIdCommit(xid);

/*
* Now write the log info to the disk too.
*/
leak = BufferPoolCheckLeak();
FlushBufferPool();
sync();
}

From bouncefilter Wed Feb 9 04:13:41 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA91143
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 04:13:02 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id UAA05354
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 20:12:57 +1100
Sender: chris@tech.com.au
Message-ID: <38A12F98.1322BE51@bitmead.com>
Date: Wed, 09 Feb 2000 20:12:56 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] backend startup
References: <38A10E24.3A52DFF8@nimrod.itg.telecom.com.au>
<4857.950082698@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

If you don't have a postmaster then the backend is running standalone,
which is not really the same environment as running in a live
installation. It's OK for some kinds of debugging but I wouldn't
trust it an inch for locking or resource-related issues.

Yeh, but for some databases, starting a backend/frontend manually IS
possible for a live installation, and improves performance because you
can run in the one process.

Say what? I've never yet shut down the postmaster to gdb anything;
I tell gdb to "attach" to a running backend started by the postmaster.

I guess I'm just too lazy to run ps.

The major
advantage of that way of working is you can use a reasonable
client
(psql or whatever floats your boat) instead of having to type
queries
directly at a backend that has no input-editing or command history
support.

Sure. But if you could run postgres in one-process mode, the backend
would appear to support history because you could build a backend with
psql built in.

There's also no question about whether you're running in

a realistic environment or not. Finally, you can fire up an additional
client+backend to examine the database even when you've got the backend
under test stopped somewhere (so long as it's not stopped holding a
spinlock or anything like that). If it weren't for the needs of initdb,
I think standalone-backend mode would've gone the way of the dodo
some time ago...

regards, tom lane

************

--
Chris Bitmead
mailto:chris@bitmead.com

From bouncefilter Wed Feb 9 05:02:42 2000
Received: from FreeBSD.xlinux.com ([203.79.167.135])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA02349
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 05:02:07 -0500 (EST)
(envelope-from kevlo@hello.com.tw)
Received: from hello.com.tw (FreeBSD.xlinux.com [203.79.167.135])
by FreeBSD.xlinux.com (8.9.3/8.9.3) with ESMTP id SAA12349;
Wed, 9 Feb 2000 18:01:55 +0800 (CST)
(envelope-from kevlo@hello.com.tw)
Sender: kevlo@FreeBSD.xlinux.com
Message-ID: <38A13B13.69E785F6@hello.com.tw>
Date: Wed, 09 Feb 2000 18:01:55 +0800
From: Kevin Lo <kevlo@hello.com.tw>
X-Mailer: Mozilla 4.7 [zh_TW] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff MacDonald <jeff@pgsql.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] WinNT compiling: ongoing
References: <Pine.BSF.4.10.10002020958270.10395-100000@rage.hub.org>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit

"Jeff MacDonald " wrote:

Ok, i've managed to get all the files i need, dandy.

* side note, i am aware that there is a pre-compiled
binary on hub. i'm doing this to see how well kevins
instructions work for every one. (from scratch)

lets start here , first 3 steps
1.Download ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/latest/full.exe

done.

2. Run full.exe and install in c:\Unix\Root directory.

afaik this means i should have a c:\Unix\Root\Cygwin
dir ?

Nope. You can install it in any directory :)

3.Run Cygwin, and then run "mount c:/Unix/Root /"
this command will not work. it gives the error
"Device Busy" , which makes perfect sense, since cygwin
is self is running out of a sub-dir of this dir.

any thoughts as to what kevin might have meant ?

Try umount /.

======================================================
Jeff MacDonald
jeff@pgsql.com irc: bignose on EFnet
======================================================

- Kevin

From bouncefilter Wed Feb 9 04:38:41 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA95684
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 04:38:10 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id CAA21765;
Wed, 9 Feb 2000 02:04:48 -0800 (PST)
Date: Wed, 9 Feb 2000 02:04:48 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
Message-ID: <20000209020448.P17536@fw.wintelcom.net>
References: <20000206230412X.t-ishii@sra.co.jp>
<24481.949852063@sss.pgh.pa.us>
<20000207212856U.t-ishii@sra.co.jp>
<20000209172202B.t-ishii@sra.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000209172202B.t-ishii@sra.co.jp>;
from t-ishii@sra.co.jp on Wed, Feb 09, 2000 at 05:22:02PM +0900

* Tatsuo Ishii <t-ishii@sra.co.jp> [000209 00:51] wrote:

BTW, Hiroshi has noticed me an excellent point #3:

Session-1
begin;
update A ...;

Session-2
begin;
select * fromB ..;
There's no PostgreSQL shared buffer available.
This backend has to force the flush of a free buffer
page. Unfortunately the page was dirtied by the
above operation of Session-1 and calls pg_fsync()
for the table A. However fsync() is postponed until
commit of this backend.

Session-1
commit;
There's no dirty buffer page for the table A.
So pg_fsync() isn't called for the table A.

Seems there's no easy solution for this. Maybe now is the time to give
up my idea...

Thinking about a little bit more, I have come across yet another
possible solution. It is actually *very* simple. Details as follows.

In xact.c:RecordTransactionCommit() there are two FlushBufferPool
calls. One is for relation files and the other is for pg_log. I add
sync() right after these FlushBufferPool. It will force any pending
kernel buffers physically be written onto disk, thus should guarantee
the ACID of the transaction (see attached code fragment).

There are two things that we should worry about sync, however.

1. Does sync really wait for the completion of data be written on to
disk?

I looked into the man page of sync(2) on Linux 2.0.36:

According to the standard specification (e.g., SVID),
sync() schedules the writes, but may return before the
actual writing is done. However, since version 1.3.20
Linux does actually wait. (This still does not guarantee
data integrity: modern disks have large caches.)

It seems that sync(2) blocks until data is written. So it would be ok
at least with Linux. I'm not sure about other platforms, though.

It is incorrect to assume that sync() wait until all buffers are
flushed on any other platform than Linux, I didn't think
that Linux even did so but the kernel sources say yes.

Solaris doesn't do this and niether does FreeBSD/NetBSD.

I guess if you wanted to implement this for linux only then it would
work, you ought to then also warn people that a non-dedicated db server
could experiance different performance using this code.

-Alfred

From bouncefilter Wed Feb 9 05:28:42 2000
Received: from FreeBSD.xlinux.com ([203.79.167.135])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA06959
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 05:28:02 -0500 (EST)
(envelope-from kevlo@hello.com.tw)
Received: from hello.com.tw (FreeBSD.xlinux.com [203.79.167.135])
by FreeBSD.xlinux.com (8.9.3/8.9.3) with ESMTP id SAA19980
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 18:28:08 +0800 (CST)
(envelope-from kevlo@hello.com.tw)
Sender: kevlo@FreeBSD.xlinux.com
Message-ID: <38A14138.4DC80066@hello.com.tw>
Date: Wed, 09 Feb 2000 18:28:08 +0800
From: Kevin Lo <kevlo@hello.com.tw>
X-Mailer: Mozilla 4.7 [zh_TW] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] WinNT compiling: ongoing
References: <Pine.BSF.4.10.10002020958270.10395
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit

"Jeff MacDonald " wrote:

Ok, i've managed to get all the files i need, dandy.

* side note, i am aware that there is a pre-compiled
binary on hub. i'm doing this to see how well kevins
instructions work for every one. (from scratch)

lets start here , first 3 steps
1.Download

ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/latest/full.exe

done.

2. Run full.exe and install in c:\Unix\Root directory.

afaik this means i should have a c:\Unix\Root\Cygwin
dir ?

Nope. You can install it in any directory :)

3.Run Cygwin, and then run "mount c:/Unix/Root /"
this command will not work. it gives the error
"Device Busy" , which makes perfect sense, since cygwin
is self is running out of a sub-dir of this dir.

any thoughts as to what kevin might have meant ?

Try umount /.

======================================================
Jeff MacDonald
jeff@pgsql.com irc: bignose on EFnet
======================================================

- Kevin

From bouncefilter Wed Feb 9 05:31:42 2000
Received: from gate.plzen-city.cz (gate.plzen-city.cz [194.212.191.10])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA07806
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 05:31:06 -0500 (EST)
(envelope-from horak@sit.plzen-city.cz)
Received: (from mail@localhost) by gate.plzen-city.cz (8.9.3/8.9.1) id
LAA19476
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 11:31:01 +0100
Received: from EXCHANGE.mmp.plzen-city.cz(s5srvr2.mmp.plzen-city.cz
192.168.4.22) by gate.plzen-city.cz via smap (v1.3-ps12tp)
id sma019465; Wed Feb 9 11:30:35 2000
Received: by exchange.mmp.plzen-city.cz with Internet Mail Service
(5.5.2650.21) id <1JG9TVNF>; Wed, 9 Feb 2000 11:30:35 +0100
Message-ID:
<F4A9A276019AD311B08C00A024B2517005885B@exchange.mmp.plzen-city.cz>
From: =?iso-8859-2?Q?Hor=E1k_Daniel?= <horak@sit.plzen-city.cz>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
Subject: Small update for WinNT port
Date: Wed, 9 Feb 2000 11:30:33 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01BF72E8.B26E06BC"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF72E8.B26E06BC
Content-Type: text/plain;
charset="iso-8859-2"

Hi,

I checked the WinNT port yesterday (a few days old snapshot from CVS) and I
am including a patch to get it compile.

changes to psql:
- added less as default pager when compiling on Cygwin
- need to declare "filename_completion_function" because it is not exported
from readline -> added to include/port/win.h

changes to pg_id:
- include of <getopt.h>
- add .exe when installing

I think there is a problem with calling the regress tests on WinNT - it
should be called with PORTNAME not HOST as the parameter to regress.sh or
the check when to add "-h localhost" to psql has to be changed. Now it is
checked against the PORTNAME.

The results of the regress tests were OK with expected failures ;-)

Dan

----------------------------------------------
Daniel Horak
network and system administrator
e-mail: horak@sit.plzen-city.cz
privat e-mail: dan.horak@email.cz ICQ:36448176
----------------------------------------------

------_=_NextPart_000_01BF72E8.B26E06BC
Content-Type: application/octet-stream;
name="winpgsql.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="winpgsql.diff"

--- src/bin/psql/print.c.orig	Tue Feb 08 22:21:36 2000=0A=
+++ src/bin/psql/print.c	Tue Feb 08 22:24:36 2000=0A=
@@ -24,7 +24,11 @@=0A=
 #include <libpq-fe.h>=0A=
 #include <postgres_ext.h>		/* for Oid type */=0A=
 =0A=
+#ifndef __CYGWIN__=0A=
 #define DEFAULT_PAGER "more"=0A=
+#else=0A=
+#define DEFAULT_PAGER "less"=0A=
+#endif=0A=
 =0A=
 =0A=
 =0A=
--- src/bin/pg_id/pg_id.c.orig	Tue Feb 08 21:33:45 2000=0A=
+++ src/bin/pg_id/pg_id.c	Tue Feb 08 21:34:16 2000=0A=
@@ -10,6 +10,9 @@=0A=
  */=0A=
 #include <c.h>=0A=
 =0A=
+#ifdef HAVE_GETOPT_H=0A=
+#include <getopt.h>=0A=
+#endif=0A=
 #include <pwd.h>=0A=
 #include <stdio.h>=0A=
 #include <stdlib.h>=0A=
--- src/bin/pg_id/Makefile.orig	Tue Feb 08 21:50:15 2000=0A=
+++ src/bin/pg_id/Makefile	Tue Feb 08 21:50:25 2000=0A=
@@ -20,7 +20,7 @@=0A=
 	$(CC) -o pg_id $(OBJS) $(LDFLAGS)=0A=
 =0A=
 install: pg_id=0A=
-	$(INSTALL) $(INSTL_EXE_OPTS) pg_id$(X) $(BINDIR)/pg_id=0A=
+	$(INSTALL) $(INSTL_EXE_OPTS) pg_id$(X) $(BINDIR)/pg_id$(X)=0A=
 =0A=
 depend dep:=0A=
 	$(CC) -MM $(CFLAGS) *.c >depend=0A=
--- src/include/port/win.h.orig	Tue Feb 08 21:46:13 2000=0A=
+++ src/include/port/win.h	Tue Feb 08 21:45:59 2000=0A=
@@ -14,3 +14,6 @@=0A=
 #if (CYGWIN_VERSION_API_MAJOR >=3D 0) && (CYGWIN_VERSION_API_MINOR =

=3D 8)=0A=

 #define sys_nerr _sys_nerr=0A=
 #endif=0A=
+=0A=
+/* not exported in readline.h */=0A=
+char * filename_completion_function();=0A=

------_=_NextPart_000_01BF72E8.B26E06BC--

From bouncefilter Wed Feb 9 08:36:31 2000
Received: from gandalf.telecom.at (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA82930
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 08:36:14 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id OAA150896;
Wed, 9 Feb 2000 14:34:01 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <1TL25J81>; Wed, 9 Feb 2000 14:33:54 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC243@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'chris@bitmead.com'" <chris@bitmead.com>
Cc: "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'pgsql-hackers@postgreSQL.org'"
<pgsql-hackers@postgreSQL.org>
Subject: AW: AW: [HACKERS] Another nasty cache problem
Date: Wed, 9 Feb 2000 14:33:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

Zeugswetter Andreas SB wrote:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

What about portals? Doesn't psql use portals?

No ... portals are a backend concept ...

I think the previous frontend "monitor" did use a portal for the
selects. The so called "blank portal".

I don't really see any advantage, that psql does not do a fetch loop
with a portal.
Is it possible in psql do do any "fetch" stuff, after doing a
select * from table ?

Yes it is if you set up a cursor.

My question implied, that a cursor was not set up. That is
type: select * from tab; in psql.

I think Tom was right that psql
shouldn't use a portal just as a matter of course, because things
work differently in that case (locks?).

There is no difference in locking behavior.
So the question remains, why don't we always use a cursor in psql.
It seems the current behavior wastes resources without an obvious
advantage.

Andreas

From bouncefilter Wed Feb 9 14:11:32 2000
Received: from imo-d09.mx.aol.com (imo-d09.mx.aol.com [205.188.157.41])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA75029
for <hackers@postgresql.org>; Wed, 9 Feb 2000 14:11:01 -0500 (EST)
(envelope-from FixerRM@aol.com)
From: FixerRM@aol.com
Received: from FixerRM@aol.com
by imo-d09.mx.aol.com (mail_out_v25.3.) id k.4d.14ad047 (9492)
for <hackers@postgresql.org>; Wed, 9 Feb 2000 14:10:21 -0500 (EST)
Message-ID: <4d.14ad047.25d3159d@aol.com>
Date: Wed, 9 Feb 2000 14:10:21 EST
Subject: jdbc and sequences --RM
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 39

I am trying to write to and access an array field in java can you give some
pointers?

Ex:
I've created a loop of 2K entries to benchmark the db using preparedstatement
in java. When i try to pass info to an array field (lvendorid int4[]) i get
an error message telling me i must cast an int4 to an _int4. How do i do this
from java?

If possible, please show code example.

R.Mann
Fixerrm@aol.com

From bouncefilter Wed Feb 9 09:30:28 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA94897
for <pgsql-hackers@postgresql.org>; Wed, 9 Feb 2000 09:29:56 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id JAA10898
for pgsql-hackers@postgresql.org; Wed, 9 Feb 2000 09:12:51 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
Message-ID: <38A1755B.4712F999@fleetanalyzer.com>
From: Vince Daniels <vdaniels@fleetanalyzer.com>
Reply-To: vdaniels@fleetanalyzer.com
Organization: FleetAnalyzer, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Re: Postgresql Perl Problem
References: <pRPd4.14389$G55.169885@news1.rdc1.ab.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 13
X-Trace: tw12.nn.bcandid.com 950105569 207.106.194.249 (Wed,
09 Feb 2000 07:12:49 MST)
Date: Wed, 09 Feb 2000 14:12:50 GMT
To: pgsql-hackers@postgresql.org

If you installed postgres as recommended as an unpriveleged user then
when you ran make install, the perl install would fail since your perl
lib directory is undoubtably owned by root. The perl module does come
with the postgres distribution and can be found in the distribution
directory:
src/interfaces/perl5. If you made postgres with the include perl option
then pg.pm is in that directory. su to root and run make install from
that directory and you should be set.

--
Vince Daniels

From bouncefilter Wed Feb 9 10:08:29 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA03926
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 10:08:00 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA05403;
Wed, 9 Feb 2000 10:07:45 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-reply-to: <20000209172202B.t-ishii@sra.co.jp>
References: <20000206230412X.t-ishii@sra.co.jp>
<24481.949852063@sss.pgh.pa.us>
<20000207212856U.t-ishii@sra.co.jp>
<20000209172202B.t-ishii@sra.co.jp>
Comments: In-reply-to Tatsuo Ishii <t-ishii@sra.co.jp>
message dated "Wed, 09 Feb 2000 17:22:02 +0900"
Date: Wed, 09 Feb 2000 10:07:45 -0500
Message-ID: <5400.950108865@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

[ use a global sync instead of fsync ]

1. Does sync really wait for the completion of data be written on to
disk?

Linux is *alone* among Unix platforms in waiting; every other
implementation of sync() returns as soon as the last dirty buffer
is scheduled to be written.

2. Are we suffered any performance penalty from sync?

A global sync at the completion of every xact would be disastrous for
the performance of anything else on the system.

However, in most cases the system is dedicated for only PostgreSQL,

"Most cases"? Do you have any evidence for that?

regards, tom lane

From bouncefilter Wed Feb 9 10:05:29 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA03357
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 10:05:21 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id AAA25934;
Thu, 10 Feb 2000 00:05:19 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-2 [133.137.84.2])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id AAA10707;
Thu, 10 Feb 2000 00:05:16 +0900
To: bright@wintelcom.net
Cc: t-ishii@sra.co.jp, tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-Reply-To: <20000209020448.P17536@fw.wintelcom.net>
References: <20000207212856U.t-ishii@sra.co.jp>
<20000209172202B.t-ishii@sra.co.jp>
<20000209020448.P17536@fw.wintelcom.net>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000210000925F.t-ishii@sra.co.jp>
Date: Thu, 10 Feb 2000 00:09:25 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 28

It seems that sync(2) blocks until data is written. So it would be ok
at least with Linux. I'm not sure about other platforms, though.

It is incorrect to assume that sync() wait until all buffers are
flushed on any other platform than Linux, I didn't think
that Linux even did so but the kernel sources say yes.

Right. I have looked at Linux kernel sources and confirmed it.

Solaris doesn't do this and niether does FreeBSD/NetBSD.

I'm not sure about Solaris since I don't have an access to its source
codes. Will look at FreeBSD kernel sources.

I guess if you wanted to implement this for linux only then it would
work, you ought to then also warn people that a non-dedicated db server
could experiance different performance using this code.

I just want to have more choices other than with/without -F. With -F
looses ACID, without it implies per-page-fsync. Both choices are
painful. But switching to expensive commercial DBMSs is much more
painful at least for me.

Even if it would be usefull on Linux only and in a certain situation,
it would better than nothing IMHO (until WAL comes up).
--
Tatsuo Ishii

From bouncefilter Wed Feb 9 10:51:33 2000
Received: from gandalf.telecom.at (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA14448
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 10:51:12 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id QAA112594;
Wed, 9 Feb 2000 16:50:30 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <1TSZDLD5>; Wed, 9 Feb 2000 16:50:31 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC245@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Tatsuo Ishii'" <t-ishii@sra.co.jp>
Cc: "'tgl@sss.pgh.pa.us'" <tgl@sss.pgh.pa.us>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] TODO item
Date: Wed, 9 Feb 2000 16:50:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

/*
* If no one shared buffer was changed by this transaction then
* we don't flush shared buffers and don't record commit status.
*/
if (SharedBufferChanged)
{
FlushBufferPool();
sync();
if (leak)
ResetBufferPool();

/*
* have the transaction access methods
record the status
* of this transaction id in the pg_log relation.
*/
TransactionIdCommit(xid);

/*
* Now write the log info to the disk too.
*/
leak = BufferPoolCheckLeak();
FlushBufferPool();

Would it be a win if this second call to FlushBufferPool would only fsync
pg_log ?
Since if I read correctly, this call will also flush IO from other sessions.

If I remember correctly I did a test by commenting the second
FlushBufferPool call,
but that resulted in some regression failures.
This call would actually not be needed for DB consistency issues (ACID).
It is only needed for Client/Server consistency
(client got commit ok, but server does rollback on crash).

sync();
}

From bouncefilter Wed Feb 9 11:13:30 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA20366
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 11:12:43 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA22969;
Wed, 9 Feb 2000 08:12:06 -0800 (PST)
Message-Id: <3.0.1.32.20000209075427.0109c140@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 09 Feb 2000 07:54:27 -0800
To: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] backend startup
In-Reply-To: <38A10E24.3A52DFF8@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 05:50 PM 2/9/00 +1100, Chris Bitmead wrote:

Is there any particular reason why a backend has to be started by the
postmaster unless it is the only backend running (in debug mode) ?

I'm thinking here that

(a) It would be more convenient to debug if you didn't have to shut down
the postmaster to run gdb postgres and...

(b) If that were the case you be part-way to implementing a
single-process database option like some databases have.

I can see where (a) is true, but who really cares about (b) any
more? NT, BSD, or Linux on a several hundred dollar PC has no problem
with dozens of processes...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Wed Feb 9 11:06:30 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA18479
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 11:05:34 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA05774;
Wed, 9 Feb 2000 11:05:27 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] minor bug...
In-reply-to: <3.0.1.32.20000208183105.0108bd60@mail.pacifier.com>
References: <3.0.1.32.20000208183105.0108bd60@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Tue, 08 Feb 2000 18:31:05 -0800"
Date: Wed, 09 Feb 2000 11:05:26 -0500
Message-ID: <5771.950112326@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Don Baccus <dhogaza@pacifier.com> writes:

... there's no real reason not to support indexes on booleans, is
there?

Not that I can see. Care to whip up the index support? I think the
only actual new code needed is a three-way-compare function (return -1,
0, or +1 according as a < b, a = b, a > b). Then you need to make up
the appropriate rows in pg_amop and related tables. See the "xindex"
chapter of the documentation.

(It occurs to me that performance would probably suck, however, because
btree doesn't handle lots of equal keys very efficiently. Fixing that
is on the TODO list...)

regards, tom lane

From bouncefilter Wed Feb 9 11:23:30 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA23242
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 11:23:12 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA22751;
Wed, 9 Feb 2000 11:17:09 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002091617.LAA22751@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <20000209172202B.t-ishii@sra.co.jp> from Tatsuo Ishii at "Feb 9,
2000 05:22:02 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Wed, 9 Feb 2000 11:17:09 -0500 (EST)
CC: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thinking about a little bit more, I have come across yet another
possible solution. It is actually *very* simple. Details as follows.

In xact.c:RecordTransactionCommit() there are two FlushBufferPool
calls. One is for relation files and the other is for pg_log. I add
sync() right after these FlushBufferPool. It will force any pending
kernel buffers physically be written onto disk, thus should guarantee
the ACID of the transaction (see attached code fragment).

Interesting idea. I had proposed this solution long ago. My idea was
to buffer pg_log writes every 30 seconds. Every 30 seconds, do a sync,
then write/sync pg_log. Seemed like a good solution at the time, but
Vadim didn't like it. I think he prefered to do logging, but honestly,
it was over a year ago, and we could have been benefiting from it all
this time.

Second, I had another idea. What if we fsync()'ed a file descriptor
only when we were writing the _last_ dirty buffer for that file. Seems
in many cases this would be a win. I just don't know how hard that is
to figure out. Seems there is no need to fsync() if we still have dirty
buffers around.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 9 11:20:30 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22567
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 11:20:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA23029;
Wed, 9 Feb 2000 11:19:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002091619.LAA23029@candle.pha.pa.us>
Subject: Re: Small update for WinNT port
In-Reply-To:
<F4A9A276019AD311B08C00A024B2517005885B@exchange.mmp.plzen-city.cz>
from "[Hor_k Daniel]" at "Feb 9, 2000 11:30:33 am"
To: "[Hor_k Daniel]" <horak@sit.plzen-city.cz>
Date: Wed, 9 Feb 2000 11:19:06 -0500 (EST)
CC: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied.

[Charset iso-8859-2 unsupported, filtering to ASCII...]

Hi,

I checked the WinNT port yesterday (a few days old snapshot from CVS) and I
am including a patch to get it compile.

changes to psql:
- added less as default pager when compiling on Cygwin
- need to declare "filename_completion_function" because it is not exported
from readline -> added to include/port/win.h

changes to pg_id:
- include of <getopt.h>
- add .exe when installing

I think there is a problem with calling the regress tests on WinNT - it
should be called with PORTNAME not HOST as the parameter to regress.sh or
the check when to add "-h localhost" to psql has to be changed. Now it is
checked against the PORTNAME.

The results of the regress tests were OK with expected failures ;-)

Dan

----------------------------------------------
Daniel Horak
network and system administrator
e-mail: horak@sit.plzen-city.cz
privat e-mail: dan.horak@email.cz ICQ:36448176
----------------------------------------------

[Attachment, skipping...]

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 9 23:39:39 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA72541
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 23:39:19 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA16404;
Wed, 9 Feb 2000 17:53:07 GMT
Sender: lockhart@hub.org
Message-ID: <38A1A982.AF81E207@alumni.caltech.edu>
Date: Wed, 09 Feb 2000 17:53:06 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] minor bug...
References: <3.0.1.32.20000208183105.0108bd60@mail.pacifier.com>
<5771.950112326@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

... there's no real reason not to support indexes on booleans, is
there?

afaict the only case where this would be a win is if there is a *very*
skewed distribution of boolean values, and you *only* want the
uncommon one. Otherwise, looking up half the rows in a table via index
has got to be worse than just scanning the table.

Not that I can see. Care to whip up the index support? I think the
only actual new code needed is a three-way-compare function (return -1,
0, or +1 according as a < b, a = b, a > b). Then you need to make up
the appropriate rows in pg_amop and related tables. See the "xindex"
chapter of the documentation.
(It occurs to me that performance would probably suck, however, because
btree doesn't handle lots of equal keys very efficiently. Fixing that
is on the TODO list...)

... And performance will suck anyway (see above) :)

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Wed Feb 9 15:11:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA90008
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 15:10:35 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA13430;
Wed, 9 Feb 2000 15:09:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002092009.PAA13430@candle.pha.pa.us>
Subject: Re: [HACKERS] Bug in cursors??
In-Reply-To: <001c01bf72c6$59413540$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Feb 9, 2000 03:24:41 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Wed, 9 Feb 2000 15:09:02 -0500 (EST)
CC: chris@bitmead.com, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

If so,could you please apply it to both trees ?
Otherwise I would commit it only to current tree myself.

I don't think we are doing more 6.5.* releases

OK,I have committed the patch to current tree.

BTW I found the following TODO item.
* update pg_class.relhasindex during vacuum when all indexes are dropped

Seems vacuum has done so from the first.

Yes, I see. TODO updated.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 9 15:16:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA91352
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 15:15:56 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA14139;
Wed, 9 Feb 2000 15:15:08 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002092015.PAA14139@candle.pha.pa.us>
Subject: Re: [HACKERS] plperl droplang patch
In-Reply-To: <20000208210603.A27586@mindspring.com> from Mark Hollomon at "Feb
8, 2000 09:06:03 pm"
To: Mark Hollomon <mhh@mindspring.com>
Date: Wed, 9 Feb 2000 15:15:08 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied.

Here is the patch to add plperl to droplang.

*** droplang.old	Tue Feb  8 21:00:34 2000
--- droplang	Tue Feb  8 21:02:27 2000
***************
*** 159,167 ****
lancomp="PL/Tcl"
handler="pltcl_call_handler"
;;
*)
echo "$CMDNAME: unsupported language '$langname'"
! 		echo "Supported languages are 'plpgsql' and 'pltcl'."
exit 1
;;
esac
--- 159,171 ----
lancomp="PL/Tcl"
handler="pltcl_call_handler"
;;
+ 	plperl)
+ 		lancomp="PL/Perl"
+ 		handler="plperl_call_handler"
+                 ;;
*)
echo "$CMDNAME: unsupported language '$langname'"
! 		echo "Supported languages are 'plpgsql', 'pltcl', and 'plperl'."
exit 1
;;
esac

--
Mark Hollomon
mhh@mindspring.com

************

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 9 16:31:34 2000
Received: from www.arcamax.com (arcamax.com [209.96.210.66])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA36375
for <pgsql-interfaces@postgreSQL.org>;
Wed, 9 Feb 2000 16:31:19 -0500 (EST)
(envelope-from bryan@arcamax.com)
Received: from bryan2 (host45 [209.96.210.45])
by www.arcamax.com (8.9.3/8.9.3) with SMTP id QAA09948
for <pgsql-interfaces@postgreSQL.org>; Wed, 9 Feb 2000 16:31:18 -0500
Message-ID: <00bb01bf7344$fe1dcf00$2dd260d1@arcamax.com>
From: "Bryan White" <bryan@arcamax.com>
To: <pgsql-interfaces@postgreSQL.org>
Subject: The persistance of C functions
Date: Wed, 9 Feb 2000 16:31:14 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

If I use CREATE FUNCTION for a C function in a .so file and then use the
function and then change and recompile the function, what steps are needed
to see the change?

As I see it the options are:
A: do nothing, the function is reloaded on every invocation.
B: Reopen the connection to the backend
C: Restart the postmaster

I suspect B is correct but I would like to hear someone confirm it.

From bouncefilter Wed Feb 9 17:20:34 2000
Received: from epg-gw1.lewis.army.mil (epg-gw1.lewis.army.mil [150.192.56.10])
by hub.org (8.9.3/8.9.3) with SMTP id RAA52311
for <pgsql-interfaces@postgreSQL.org>;
Wed, 9 Feb 2000 17:19:33 -0500 (EST)
(envelope-from craig@epg-gw1.lewis.army.mil)
Received: from delenn.eng by epg-gw1.lewis.army.mil with SMTP
(1.37.109.4/15.6) id AA04303; Wed, 9 Feb 00 14:19:17 -0800
Received: by delenn.eng
(8.7.6/16.2) id RAA28143; Wed, 9 Feb 2000 17:19:19 -0500 (EST)
Message-Id: <XFMail.000209141919.orsingerc@epg-gw1.lewis.army.mil>
X-Mailer: XFMail 1.3 [p0] on HP-UX (unknown)
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0
In-Reply-To: <00bb01bf7344$fe1dcf00$2dd260d1@arcamax.com>
Date: Wed, 09 Feb 2000 14:19:19 -0800 (PST)
Reply-To: Craig Orsinger <orsingerc@epg-gw1.lewis.army.mil>
Organization: EPG Ft. Lewis Field Office
Sender: craig@epg-gw1.lewis.army.mil
From: Craig Orsinger <orsingerc@epg-gw1.lewis.army.mil>
To: pgsql-interfaces@postgreSQL.org
Subject: RE: [INTERFACES] The persistance of C functions

On 09-Feb-00 Bryan White wrote:

If I use CREATE FUNCTION for a C function in a .so file and then use the
function and then change and recompile the function, what steps are needed
to see the change?

As I see it the options are:
A: do nothing, the function is reloaded on every invocation.
B: Reopen the connection to the backend
C: Restart the postmaster

I suspect B is correct but I would like to hear someone confirm it.

I don't know about A or B, but C definitely works :-). If it's
practical, I sometimes use DROP FUNCTION/CREATE FUNCTION, but I don't
think this is practical when you're using this function (or set of
functions) to implement a new data type.

----------------------------------
Date: 09-Feb-00 Time: 14:16:54

Craig Orsinger (email: <orsingerc@epg-gw1.lewis.army.mil>)
Logicon RDA
Bldg. 8B28 "Just another megalomaniac with ideas above his
6th & F Streets station. The Universe is full of them."
Ft. Lewis, WA 98433 - The Doctor
----------------------------------

From bouncefilter Wed Feb 9 17:36:40 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA81072
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 17:35:37 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA05486 for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 09:34:59 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdU53Ln_;
Thu Feb 10 09:34:34 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA13243 for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 09:34:33 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0_sUQC; Thu Feb 10 09:33:33 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA24748
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 09:33:32 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
JAA12170 for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 09:32:56 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A1EAE0.CB043183@nimrod.itg.telecom.com.au>
Date: Thu, 10 Feb 2000 09:32:00 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] backend startup
References: <3.0.1.32.20000209075427.0109c140@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

At 05:50 PM 2/9/00 +1100, Chris Bitmead wrote:

Is there any particular reason why a backend has to be started by the
postmaster unless it is the only backend running (in debug mode) ?

I'm thinking here that

(a) It would be more convenient to debug if you didn't have to shut down
the postmaster to run gdb postgres and...

(b) If that were the case you be part-way to implementing a
single-process database option like some databases have.

I can see where (a) is true, but who really cares about (b) any
more? NT, BSD, or Linux on a several hundred dollar PC has no problem
with dozens of processes...

Well there is socket overhead and extra context-switching time.

From bouncefilter Wed Feb 9 17:55:35 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA88142
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 17:54:38 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id OAA15901;
Wed, 9 Feb 2000 14:54:01 -0800 (PST)
Message-Id: <3.0.1.32.20000209145150.010a5a40@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 09 Feb 2000 14:51:50 -0800
To: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] backend startup
In-Reply-To: <38A1EAE0.CB043183@nimrod.itg.telecom.com.au>
References: <3.0.1.32.20000209075427.0109c140@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:32 AM 2/10/00 +1100, Chris Bitmead wrote:

I can see where (a) is true, but who really cares about (b) any
more? NT, BSD, or Linux on a several hundred dollar PC has no problem
with dozens of processes...

Well there is socket overhead and extra context-switching time.

Given how expensive the basic RDBMS structure is, I imagine this
is a bit like worrying about the fact that the bugs on my windshield
increase drag and decrease my gas mileage.

I mean ... this is undoubtably true, but really pales in comparison
to other factors that impact my gas mileage.

Now, if you got rid of all the baggage associated with sharing buffers,
locking, and all the rest that goes with the multiple process model
used by Postgres you might end up with a single-process/single client
version that is noticably faster.

But just getting rid of the kernel overhead of two processes talking
to each other isn't going to get you much, I don't think. You might
be able to measure it for something like "select 1", but real queries
on real databases? I find it hard to believe.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Wed Feb 9 18:28:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA02574
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 18:28:05 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA07279;
Wed, 9 Feb 2000 18:27:41 -0500 (EST)
To: Alfred Perlstein <bright@wintelcom.net>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
In-reply-to: <20000209154422.L17536@fw.wintelcom.net>
References: <20000207212856U.t-ishii@sra.co.jp>
<20000209172202B.t-ishii@sra.co.jp>
<20000209020448.P17536@fw.wintelcom.net>
<20000210000925F.t-ishii@sra.co.jp>
<20000209154422.L17536@fw.wintelcom.net>
Comments: In-reply-to Alfred Perlstein <bright@wintelcom.net>
message dated "Wed, 09 Feb 2000 15:44:22 -0800"
Date: Wed, 09 Feb 2000 18:27:41 -0500
Message-ID: <7276.950138861@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Alfred Perlstein <bright@wintelcom.net> writes:

postgresql has 3 files open (a, b, c), so will the syncer.

The syncer must have all the files open that are open in any backend?
What happens when it runs into the FDs-per-process limit?

backend 1 completes a request, communicates to the syncer that a flush
is needed.
syncer starts by fsync'ing 'a'
backend 2 completes a request, communicates to the syncer
syncer continues with 'b' then 'c'
syncer responds to backend 1 that it's safe to proceed.
syncer fsyncs 'a' again
syncer responds to backend 2 that it's all completed.
effectively the fsync of 'b' and 'c' have been batched.

And it's safe to update pg_log when?

I'm failing to see where the advantage is compared to the backends
issuing their own fsyncs...

regards, tom lane

From bouncefilter Wed Feb 9 18:29:35 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA02836
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 18:28:40 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA04010;
Wed, 9 Feb 2000 18:28:10 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002092328.SAA04010@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO item
In-Reply-To: <20000209154422.L17536@fw.wintelcom.net> from Alfred Perlstein at
"Feb 9, 2000 03:44:22 pm"
To: Alfred Perlstein <bright@wintelcom.net>
Date: Wed, 9 Feb 2000 18:28:10 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, tgl@sss.pgh.pa.us,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Ok, here's a nifty idea, a slave process called pgsyncer.

At the end of a transaction a backend asks the syncer to fsync all files.

Now here's the cool part, this avoids the non-portability of the Linux
sync() problem and at the same time restricts the syncing to postgresql
and reduces 'cross-fsync' issues.

Imagine:

postgresql has 3 files open (a, b, c), so will the syncer.
backend 1 completes a request, communicates to the syncer that a flush
is needed.
syncer starts by fsync'ing 'a'
backend 2 completes a request, communicates to the syncer
syncer continues with 'b' then 'c'
syncer responds to backend 1 that it's safe to proceed.
syncer fsyncs 'a' again
syncer responds to backend 2 that it's all completed.

effectively the fsync of 'b' and 'c' have been batched.

It's just an elevator algorithm, perhaps this can be done without
a seperate slave process?

If you go to the hackers archive, you will see an implementation under
subject "Bufferd loggins/pg_log" dated November 1997. We have gone over
2 years without this option, and it is going to be even longer before it
is available via WAL.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Feb 9 18:42:35 2000
Received: from www.arcamax.com (arcamax.com [209.96.210.66])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA07484
for <pgsql-interfaces@postgreSQL.org>;
Wed, 9 Feb 2000 18:42:25 -0500 (EST)
(envelope-from bryan@arcamax.com)
Received: from bryan2 (host45 [209.96.210.45])
by www.arcamax.com (8.9.3/8.9.3) with SMTP id SAA23740
for <pgsql-interfaces@postgreSQL.org>; Wed, 9 Feb 2000 18:42:25 -0500
Message-ID: <011d01bf7357$4c52b160$2dd260d1@arcamax.com>
From: "Bryan White" <bryan@arcamax.com>
To: <pgsql-interfaces@postgreSQL.org>
References: <XFMail.000209141919.orsingerc@epg-gw1.lewis.army.mil>
Subject: Re: [INTERFACES] The persistance of C functions
Date: Wed, 9 Feb 2000 18:42:16 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

On 09-Feb-00 Bryan White wrote:

If I use CREATE FUNCTION for a C function in a .so file and then use the
function and then change and recompile the function, what steps are

needed

to see the change?

As I see it the options are:
A: do nothing, the function is reloaded on every invocation.
B: Reopen the connection to the backend
C: Restart the postmaster

I suspect B is correct but I would like to hear someone confirm it.

I don't know about A or B, but C definitely works :-). If it's
practical, I sometimes use DROP FUNCTION/CREATE FUNCTION, but I don't
think this is practical when you're using this function (or set of
functions) to implement a new data type.

Thanks, I have come to the conclusion that B is sufficient based on trial
and error.

From bouncefilter Wed Feb 9 18:18:38 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA97793
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 18:17:36 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id PAA15769;
Wed, 9 Feb 2000 15:44:22 -0800 (PST)
Date: Wed, 9 Feb 2000 15:44:22 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO item
Message-ID: <20000209154422.L17536@fw.wintelcom.net>
References: <20000207212856U.t-ishii@sra.co.jp>
<20000209172202B.t-ishii@sra.co.jp>
<20000209020448.P17536@fw.wintelcom.net>
<20000210000925F.t-ishii@sra.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000210000925F.t-ishii@sra.co.jp>;
from t-ishii@sra.co.jp on Thu, Feb 10, 2000 at 12:09:25AM +0900

* Tatsuo Ishii <t-ishii@sra.co.jp> [000209 07:32] wrote:

It seems that sync(2) blocks until data is written. So it would be ok
at least with Linux. I'm not sure about other platforms, though.

It is incorrect to assume that sync() wait until all buffers are
flushed on any other platform than Linux, I didn't think
that Linux even did so but the kernel sources say yes.

Right. I have looked at Linux kernel sources and confirmed it.

Solaris doesn't do this and niether does FreeBSD/NetBSD.

I'm not sure about Solaris since I don't have an access to its source
codes. Will look at FreeBSD kernel sources.

I guess if you wanted to implement this for linux only then it would
work, you ought to then also warn people that a non-dedicated db server
could experiance different performance using this code.

I just want to have more choices other than with/without -F. With -F
looses ACID, without it implies per-page-fsync. Both choices are
painful. But switching to expensive commercial DBMSs is much more
painful at least for me.

Even if it would be usefull on Linux only and in a certain situation,
it would better than nothing IMHO (until WAL comes up).

Ok, here's a nifty idea, a slave process called pgsyncer.

At the end of a transaction a backend asks the syncer to fsync all files.

Now here's the cool part, this avoids the non-portability of the Linux
sync() problem and at the same time restricts the syncing to postgresql
and reduces 'cross-fsync' issues.

Imagine:

postgresql has 3 files open (a, b, c), so will the syncer.
backend 1 completes a request, communicates to the syncer that a flush
is needed.
syncer starts by fsync'ing 'a'
backend 2 completes a request, communicates to the syncer
syncer continues with 'b' then 'c'
syncer responds to backend 1 that it's safe to proceed.
syncer fsyncs 'a' again
syncer responds to backend 2 that it's all completed.

effectively the fsync of 'b' and 'c' have been batched.

It's just an elevator algorithm, perhaps this can be done without
a seperate slave process?

-Alfred

From bouncefilter Wed Feb 9 19:02:44 2000
Received: from web2903.mail.yahoo.com (web2903.mail.yahoo.com [128.11.68.46])
by hub.org (8.9.3/8.9.3) with SMTP id TAA12492
for <pgsql-hackers@postgresql.org>; Wed, 9 Feb 2000 19:02:11 -0500 (EST)
(envelope-from rinid@rocketmail.com)
Received: (qmail 9925 invoked by uid 60001); 10 Feb 2000 00:02:10 -0000
Message-ID: <20000210000210.9924.qmail@web2903.mail.yahoo.com>
Received: from [206.114.238.111] by web2903.mail.yahoo.com;
Wed, 09 Feb 2000 16:02:10 PST
Date: Wed, 9 Feb 2000 16:02:10 -0800 (PST)
From: Rini Dutta <rinid@rocketmail.com>
Subject: how to make libpq on winnt using the 'win32.mak's
To: pgsql-interfaces@postgresql.org
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi

I'm running postgres v6.5.3. I need to make calls to
the functions in libpq in my code. For this I need the
files - libpq.lib/libpq.lib.dll/libpqdll.lib.

When I run 'nmake /f win32.mak' in the src directory,
it is unable to open/find config.h . If I use the
config.h generated as a result of 'configure' on
cygwin, it complains about other .h files not being
found. (I do not know if there is a way to do the
equivalent on the DOS Shell/Command Prompt )

Could anyone let me know how to build libpq to get
libpq.dll/libpq.lib/libpqdll.lib ?

Thanks,
Rini

ps : The administrators guide has a chapter on this
which I followed. (But it mentions Postgres v6.4 ?!)
Here is an extract :

Chapter 20. Installation on Win32

Table of Contents
Building the libraries
Installing the libraries
Using the libraries

Build and installation instructions for
Postgres v6.4 client libraries on Win32.

Building the libraries

The makefiles included in Postgres are written for
Microsoft Visual C++, and will probably not work with
other systems. It should be
possible to compile the libaries manually in other
cases.

To build the libraries, change directory into the src
directory, and type the command

nmake /f win32.mak

This assumes that you have Visual C++ in your path.

The following files will be built:

interfaces\libpq\Release\libpq.dll - The
dynamically linkable frontend library

interfaces\libpq\Release\libpqdll.lib - Import
library to link your program to libpq.dll

interfaces\libpq\Release\libpq.lib - Static
library version of the frontend library

bin\psql\Release\psql.exe - The Postgresql
interactive SQL monitor

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From bouncefilter Wed Feb 9 19:09:39 2000
Received: from web2903.mail.yahoo.com (web2903.mail.yahoo.com [128.11.68.46])
by hub.org (8.9.3/8.9.3) with SMTP id TAA14715
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 19:09:22 -0500 (EST)
(envelope-from rinid@rocketmail.com)
Received: (qmail 10266 invoked by uid 60001); 10 Feb 2000 00:09:22 -0000
Message-ID: <20000210000922.10265.qmail@web2903.mail.yahoo.com>
Received: from [206.114.238.111] by web2903.mail.yahoo.com;
Wed, 09 Feb 2000 16:09:22 PST
Date: Wed, 9 Feb 2000 16:09:22 -0800 (PST)
From: Rini Dutta <rinid@rocketmail.com>
Subject: how to make libpq on winnt using the 'win32.mak's
To: pgsql-hackers@postgreSQL.org
Cc: pgsql-interfaces@postgreSQL.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi

I'm running postgres v6.5.3. I need to make calls to
the functions in libpq in my code. For this I need
the
files - libpq.lib/libpq.lib.dll/libpqdll.lib.

When I run 'nmake /f win32.mak' in the src
directory,
it is unable to open/find config.h . If I use the
config.h generated as a result of 'configure' on
cygwin, it complains about other .h files not being
found. (I do not know if there is a way to do the
equivalent on the DOS Shell/Command Prompt )

Could anyone let me know how to build libpq to get
libpq.dll/libpq.lib/libpqdll.lib ?

Thanks,
Rini

ps : The administrators guide has a chapter on this
which I followed. (But it mentions Postgres v6.4 ?!)
Here is an extract :

Chapter 20. Installation on Win32

Table of Contents
Building the libraries
Installing the libraries
Using the libraries

Build and installation instructions for
Postgres v6.4 client libraries on Win32.

Building the libraries

The makefiles included in Postgres are written for
Microsoft Visual C++, and will probably not work
with
other systems. It should be
possible to compile the libaries manually in other
cases.

To build the libraries, change directory into the
src
directory, and type the command

nmake /f win32.mak

This assumes that you have Visual C++ in your path.

The following files will be built:

interfaces\libpq\Release\libpq.dll - The
dynamically linkable frontend library

interfaces\libpq\Release\libpqdll.lib -
Import
library to link your program to libpq.dll

interfaces\libpq\Release\libpq.lib - Static
library version of the frontend library

bin\psql\Release\psql.exe - The Postgresql
interactive SQL monitor

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From bouncefilter Wed Feb 9 19:28:36 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA23128
for <pgsql-hackers@postgresql.org>; Wed, 9 Feb 2000 19:27:54 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA00543; Thu, 10 Feb 2000 09:26:22 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgresql.org>, "Tatsuo Ishii" <t-ishii@sra.co.jp>
Subject: RE: [HACKERS] TODO item
Date: Thu, 10 Feb 2000 09:32:22 +0900
Message-ID: <000601bf735e$4bdda440$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <5400.950108865@sss.pgh.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: owner-pgsql-hackers@postgresql.org
[mailto:owner-pgsql-hackers@postgresql.org]On Behalf Of Tom Lane

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

[ use a global sync instead of fsync ]

1. Does sync really wait for the completion of data be written on to
disk?

Linux is *alone* among Unix platforms in waiting; every other
implementation of sync() returns as soon as the last dirty buffer
is scheduled to be written.

2. Are we suffered any performance penalty from sync?

A global sync at the completion of every xact would be disastrous for
the performance of anything else on the system.

However, in most cases the system is dedicated for only PostgreSQL,

"Most cases"? Do you have any evidence for that?

Tatsuo is afraid of the delay of WAL
OTOH,it's not so easy to solve this item in current spec.
Probably he wants a quick and simple solution.

His solution is only for limited OS but is very simple.
Moreover it would make FlushBufferPool() more reliable(
I don't understand why FlushBufferPool() is allowed to not
call fsync() per page.).

The implementation would be in time for 7.0.
Is a temporary option unitl WAL bad ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Feb 9 19:47:37 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA30923
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 19:46:53 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA25880 for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:46:21 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0Z5I2S;
Thu Feb 10 11:46:00 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA24024 for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:46:00 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd3u6Mz_; Thu Feb 10 11:45:41 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA25772
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:45:36 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
LAA15256 for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:44:59 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A209D3.D016D82D@nimrod.itg.telecom.com.au>
Date: Thu, 10 Feb 2000 11:44:03 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] backend startup
References: <3.0.1.32.20000209075427.0109c140@mail.pacifier.com>
<3.0.1.32.20000209145150.010a5a40@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

At 09:32 AM 2/10/00 +1100, Chris Bitmead wrote:

I can see where (a) is true, but who really cares about (b) any
more? NT, BSD, or Linux on a several hundred dollar PC has no problem
with dozens of processes...

Well there is socket overhead and extra context-switching time.

Given how expensive the basic RDBMS structure is, I imagine this
is a bit like worrying about the fact that the bugs on my windshield
increase drag and decrease my gas mileage.

I mean ... this is undoubtably true, but really pales in comparison
to other factors that impact my gas mileage.

Well I don't know, but I know VERSANT for example provides a lib1p.so
and a lib2p.so, and I know they make sure to link against 1p.so for
benchmarks.

Now, if you got rid of all the baggage associated with sharing buffers,
locking, and all the rest that goes with the multiple process model
used by Postgres you might end up with a single-process/single client
version that is noticably faster.

Well, I'm not talking about a single client version. That would be of
dubious value.

But just getting rid of the kernel overhead of two processes talking
to each other isn't going to get you much, I don't think. You might
be able to measure it for something like "select 1", but real queries
on real databases? I find it hard to believe.

From bouncefilter Wed Feb 9 20:13:36 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA36643
for <pgsql-hackers@postgresql.org>; Wed, 9 Feb 2000 20:13:35 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64329 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S430145AbQBJBMq>;
Thu, 10 Feb 2000 02:12:46 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12IiBi-0000NL-00; Thu, 10 Feb 2000 02:14:30 +0100
Date: Thu, 10 Feb 2000 02:14:30 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Malcolm Beattie <mbeattie@sable.ox.ac.uk>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Need confirmation of "Posix time standard" on FreeBSD
In-Reply-To: <38A05F6C.B2C42E8B@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0002090143120.350-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-08, Thomas Lockhart mentioned:

OK. I'll need to generalize the current code, which looks specifically
for "gmt". Possibly, we'll have just the "GMT+/-####" case handled for
7.0, but if I get time.

I believe it should preferrably be called "UTC".

And we'll allow a superset of the Posix standard, so "GMT+0800" will

He mentioned earlier that it has to be GMT+08:00 or GMT+8.

be legal (otherwise, it would disallow the ISO8601 standard which imho
should take precedence).

Oh please, it should. Is it just me or is this notation not making any
sense? If GMT+08:00 means "you need to add 8 hours to your local time zone
to get to GMT", then x = a + b means "you need to add 'b' to 'x' in order
to get 'a'". Darn standards. How about NOON+01:30 to indicate 10:30(am)?

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Feb 9 20:14:36 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA36645
for <pgsql-hackers@postgresql.org>; Wed, 9 Feb 2000 20:13:36 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64324 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S436290AbQBJBMp>;
Thu, 10 Feb 2000 02:12:45 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12IiBw-0000NN-00; Thu, 10 Feb 2000 02:14:44 +0100
Date: Thu, 10 Feb 2000 02:14:44 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: =?ISO-8859-1?Q?Hor=E1k_Daniel?= <horak@sit.plzen-city.cz>
cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgresql.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Small update for WinNT port
In-Reply-To:
<F4A9A276019AD311B08C00A024B2517005885B@exchange.mmp.plzen-city.cz>
Message-ID: <Pine.LNX.4.21.0002092145120.369-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-09, Hor���k Daniel mentioned:

changes to psql:
- added less as default pager when compiling on Cygwin

Is there no "more"?

- need to declare "filename_completion_function" because it is not exported
from readline -> added to include/port/win.h

I would think this is more of a readline problem, or does cygwin come with
its only readline edition? What readline version are you using?

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Feb 9 21:53:37 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA53486
for <pgsql-hackers@postgreSQL.org>; Wed, 9 Feb 2000 21:53:06 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
NAA25141 for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 13:52:33 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdpaGlv_;
Thu Feb 10 13:52:14 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
NAA21949 for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 13:52:13 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0ID3cX; Thu Feb 10 13:51:15 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA26276
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 13:51:09 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
NAA18123 for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 13:50:29 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A2273C.E9847E33@nimrod.itg.telecom.com.au>
Date: Thu, 10 Feb 2000 13:49:32 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: backendid and backendtag
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Can someone give be a brief rundown on what the backendid and backendtag
are for?

From bouncefilter Thu Feb 10 01:44:45 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA93157
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 01:44:21 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id GAA17531;
Thu, 10 Feb 2000 06:52:10 GMT
Sender: lockhart@hub.org
Message-ID: <38A2601A.7E103309@alumni.caltech.edu>
Date: Thu, 10 Feb 2000 06:52:10 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Malcolm Beattie <mbeattie@sable.ox.ac.uk>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Need confirmation of "Posix time standard" on FreeBSD
References: <Pine.LNX.4.21.0002090143120.350-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

OK. I'll need to generalize the current code, which looks specifically
for "gmt". Possibly, we'll have just the "GMT+/-####" case handled for
7.0, but if I get time.

I believe it should preferrably be called "UTC".

The specific case we are solving is an interaction with the zinc
timezone database available on (at least) Linux and FreeBSD. Both
platforms have "GMT+/-n" zones defined, and we'll want to correctly
parse them.

And we'll allow a superset of the Posix standard, so "GMT+0800" will

He mentioned earlier that it has to be GMT+08:00 or GMT+8.

Right. That's why I thought I'd mention that we'll do a superset.

be legal (otherwise, it would disallow the ISO8601 standard which imho
should take precedence).

Oh please, it should. Is it just me or is this notation not making any
sense? If GMT+08:00 means "you need to add 8 hours to your local time zone
to get to GMT", then x = a + b means "you need to add 'b' to 'x' in order
to get 'a'". Darn standards. How about NOON+01:30 to indicate 10:30(am)?

Not in this lifetime. afaict there is a common thread to date/time
representation in these two standards, as they both involve using a
"+/-" notation to represent time zones.

It is certainly annoying that there is a sign flip on the numeric
fields for the two standards (Posix and ISO8601). But only one, Posix,
has the preceding alpha time zone, so I should be able to figure it
out.

The annoying thing is that my token parsing is getting trickier, since
I also allow "January-1 2000" as a date specification, which from a
*token* standpoint is pretty similar to "gmt+8"...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 10 10:48:46 2000
Received: from gate.plzen-city.cz (gate.plzen-city.cz [194.212.191.10])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA16274
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 10:48:27 -0500 (EST)
(envelope-from horak@sit.plzen-city.cz)
Received: (from mail@localhost) by gate.plzen-city.cz (8.9.3/8.9.1) id
KAA06876
for <pgsql-hackers@postgreSQL.org>; Thu, 10 Feb 2000 10:20:14 +0100
Received: from EXCHANGE.mmp.plzen-city.cz(s5srvr2.mmp.plzen-city.cz
192.168.4.22) by gate.plzen-city.cz via smap (v1.3-ps12tp)
id sma006869; Thu Feb 10 10:20:06 2000
Received: by exchange.mmp.plzen-city.cz with Internet Mail Service
(5.5.2650.21) id <1JG9TXS2>; Thu, 10 Feb 2000 10:19:36 +0100
Message-ID:
<F4A9A276019AD311B08C00A024B2517005885E@exchange.mmp.plzen-city.cz>
From: =?iso-8859-1?Q?Hor=E1k_Daniel?= <horak@sit.plzen-city.cz>
To: "'Peter Eisentraut'" <peter_e@gmx.net>
Cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Small update for WinNT port
Date: Thu, 10 Feb 2000 10:19:28 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"

changes to psql:
- added less as default pager when compiling on Cygwin

Is there no "more"?

There is a native version of more in WinNT (like in DOS) but it is not
compatible with Cygwin and less is distributed as a part of Cygwin.

- need to declare "filename_completion_function" because it

is not exported

from readline -> added to include/port/win.h

I would think this is more of a readline problem, or does
cygwin come with
its only readline edition? What readline version are you using?

Yes, it is a problem of readline. I am not able to get the version number
because it is not defined in the readline headers, but from the copyright
notice it is very old (last year is 1992).

Dan

From bouncefilter Thu Feb 10 10:46:46 2000
Received: from ara.zf.jcu.cz (root@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA15646
for <pgsql-interfaces@postgreSQL.org>;
Thu, 10 Feb 2000 10:46:08 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA22069;
Thu, 10 Feb 2000 10:42:29 +0100
Date: Thu, 10 Feb 2000 10:42:29 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Bryan White <bryan@arcamax.com>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] The persistance of C functions
In-Reply-To: <00bb01bf7344$fe1dcf00$2dd260d1@arcamax.com>
Message-ID: <Pine.LNX.3.96.1000210103409.21359B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 9 Feb 2000, Bryan White wrote:

If I use CREATE FUNCTION for a C function in a .so file and then use the
function and then change and recompile the function, what steps are needed
to see the change?

As I see it the options are:
A: do nothing, the function is reloaded on every invocation.
B: Reopen the connection to the backend
C: Restart the postmaster

I suspect B is correct but I would like to hear someone confirm it.

'B' is right - the postgreSQL not has any persisten cache for this, and
if you restart connection a backend reload this information again.

Or you can drop/(re)create a function, it is total safe solution.

Karel

From bouncefilter Thu Feb 10 05:04:42 2000
Received: from hu.tm.ee (ppp64.tele2.ee [212.107.33.64])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA32723
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 05:04:38 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 5C3E43A26; Thu, 10 Feb 2000 12:12:04 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38A28EF4.70E998A9@tm.ee>
Date: Thu, 10 Feb 2000 12:12:04 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
Cc: "'Tom Lane'" <tgl@sss.pgh.pa.us>,
"'chris@bitmead.com'" <chris@bitmead.com>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] Another nasty cache problem
References:
<219F68D65015D011A8E000006F8590C603FDC240@sdexcsrv1.f000.d0188.sd.spardat.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Zeugswetter Andreas SB wrote:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

What about portals? Doesn't psql use portals?

No ... portals are a backend concept ...

I think the previous frontend "monitor" did use a portal for the
selects. The so called "blank portal".

Is'nt the "blank portal" the name of the cursor you get when you just
do a select without creating a cursor ?

I don't really see any advantage, that psql does not do a fetch loop
with a portal.

It only increases traffic, as explicit fetch commands need to be sent
to backend. If one does not declare a cursor, an implicit fetch all from
blank is performed.

Is it possible in psql do do any "fetch" stuff, after doing a
select * from table ?

only if in a declared cursor, and you can only declare cursor if in a
transaction.

---------------
Hannu

From bouncefilter Thu Feb 10 05:46:43 2000
Received: from web1106.mail.yahoo.com (web1106.mail.yahoo.com [128.11.23.126])
by hub.org (8.9.3/8.9.3) with SMTP id FAA39829
for <hackers@postgresql.org>; Thu, 10 Feb 2000 05:45:47 -0500 (EST)
(envelope-from richa_sing@yahoo.com)
Received: (qmail 19234 invoked by uid 60001); 10 Feb 2000 10:45:27 -0000
Message-ID: <20000210104527.19233.qmail@web1106.mail.yahoo.com>
Received: from [202.54.101.14] by web1106.mail.yahoo.com;
Thu, 10 Feb 2000 02:45:27 PST
Date: Thu, 10 Feb 2000 02:45:27 -0800 (PST)
From: Richa Singh <richa_sing@yahoo.com>
Subject: jdbc 1.2 and postgrsSQL-6.5.3 on RedHat 6.1
To: pgsql-ports@postgresql.org
Cc: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hello!
I am having problems in connectiing to java with
PostgreSQL.The statement is
Class.forName("postgresql.Driver");
Also,Iam not able to create postgresql.jar file in
/path/src/interfaces/jdbc directory with make utility
as written in the Readme file in the same
directory.Please help me out.Also wherte thde files
have to be placed and path and Classpath setting has
to be done.Do I need to install some Drivers.I think
theyu come with s/w.
How could I use Odbc over here.In the sense where
DSN has to be created.
Do reply fast as my Project is stopped.
Thanks,
Richa
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From bouncefilter Thu Feb 10 05:50:43 2000
Received: from web1103.mail.yahoo.com (web1103.mail.yahoo.com [128.11.23.123])
by hub.org (8.9.3/8.9.3) with SMTP id FAA40601
for <hackers@postgresql.org>; Thu, 10 Feb 2000 05:50:11 -0500 (EST)
(envelope-from richa_sing@yahoo.com)
Received: (qmail 12713 invoked by uid 60001); 10 Feb 2000 10:50:10 -0000
Message-ID: <20000210105010.12712.qmail@web1103.mail.yahoo.com>
Received: from [202.54.101.14] by web1103.mail.yahoo.com;
Thu, 10 Feb 2000 02:50:09 PST
Date: Thu, 10 Feb 2000 02:50:09 -0800 (PST)
From: Richa Singh <richa_sing@yahoo.com>
Subject: Jdbc and Postfresql-6.5.3 on RedHat 6.1
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hello!
I am having problems in connectiing to java with
PostgreSQL.The statement is
Class.forName("postgresql.Driver");
Also,Iam not able to create postgresql.jar file in
/path/src/interfaces/jdbc directory with make utility
as written in the Readme file in the same
directory.Please help me out.Also wherte thde files
have to be placed and path and Classpath setting has
to be done.Do I need to install some Drivers.I think
theyu come with s/w.
How could I use Odbc over here.In the sense where
DSN has to be created.
Do reply fast as my Project is stopped.
Thanks,
Richa

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From bouncefilter Thu Feb 10 06:33:43 2000
Received: from hu.tm.ee (ppp64.tele2.ee [212.107.33.64])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA50175
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 06:33:36 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 62EFC3A3C; Thu, 10 Feb 2000 13:41:13 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38A2A3D9.96879708@tm.ee>
Date: Thu, 10 Feb 2000 13:41:13 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Don Baccus <dhogaza@pacifier.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] minor bug...
References: <3.0.1.32.20000208183105.0108bd60@mail.pacifier.com>
<5771.950112326@sss.pgh.pa.us>
<38A1A982.AF81E207@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

... there's no real reason not to support indexes on booleans, is
there?

afaict the only case where this would be a win is if there is a *very*
skewed distribution of boolean values, and you *only* want the
uncommon one. Otherwise, looking up half the rows in a table via index
has got to be worse than just scanning the table.

One (maybe only) case I can see use for it is for a multi-field index
containing many booleans (say an index over 16 boolean fields).

------------
Hannu

From bouncefilter Thu Feb 10 07:24:44 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA59928
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 07:24:37 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id XAA20238
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 23:24:32 +1100
Sender: chris@tech.com.au
Message-ID: <38A2AE00.9EB1BE9B@bitmead.com>
Date: Thu, 10 Feb 2000 23:24:32 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: libpq
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've been poking around in the libpq area and I'm thinking of tackling
the streaming interface which was suggested recently.

What I have in mind is that a new API PQexecStream() doesn't retrieve
the results. The tuples are then read back one by one with
PQnextObject(). You can also use PQnextObject with regular PQexec, but
in that case you lose the most of the benefit of streaming because it
would allocate memory for all the result. So the proposal is...

/* like PQexec, but streams the results */
PGresult *PQexecStream(PGconn *conn, const char *query)
/* retrieve the next object from a PGresult */
PGobject *PQnextObject(PGconn *conn)
/* get value from an object/tuple */
char *PQgetObjectValue(const PGobject *res, int field_num)
/* free tuple when done */
void PQclearObject(PGobject *obj)

Oh yeah, can I fix the COPY protocol while I'm at it to conform more to
the other types of messages?

BTW, what is this PQ thing? Does it stand for postquel? Are we ever
going to dump that?

--
Chris Bitmead
mailto:chris@bitmead.com

From bouncefilter Thu Feb 10 07:40:44 2000
Received: from gandalf.telecom.at (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA62907
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 07:39:44 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id NAA137364;
Thu, 10 Feb 2000 13:35:31 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <1TSZDQMR>; Thu, 10 Feb 2000 13:35:24 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC247@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Hannu Krosing'" <hannu@tm.ee>
Cc: "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'chris@bitmead.com'"
<chris@bitmead.com>, "'pgsql-hackers@postgreSQL.org'"
<pgsql-hackers@postgreSQL.org>
Subject: AW: AW: [HACKERS] Another nasty cache problem
Date: Thu, 10 Feb 2000 13:35:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

Is'nt the "blank portal" the name of the cursor you get when you just
do a select without creating a cursor ?

Yes, is that still so ?

I don't really see any advantage, that psql does not do a fetch loop
with a portal.

It only increases traffic, as explicit fetch commands need to be sent
to backend. If one does not declare a cursor, an implicit
fetch all from
blank is performed.

I don't really see how a fetch every x rows (e.g.1000) would add significant
overhead.
The first fetch could still be done implicit, it would only fetch 1000
instead of fetch all.
Thus there would only be overhead for large result sets, where the
wasted memory is of real concern.

Andreas

From bouncefilter Thu Feb 10 08:40:45 2000
Received: from web2906.mail.yahoo.com (web2906.mail.yahoo.com [128.11.68.49])
by hub.org (8.9.3/8.9.3) with SMTP id IAA86962
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 08:40:30 -0500 (EST)
(envelope-from rinid@rocketmail.com)
Received: (qmail 18185 invoked by uid 60001); 10 Feb 2000 13:40:29 -0000
Message-ID: <20000210134029.18184.qmail@web2906.mail.yahoo.com>
Received: from [206.114.238.111] by web2906.mail.yahoo.com;
Thu, 10 Feb 2000 05:40:29 PST
Date: Thu, 10 Feb 2000 05:40:29 -0800 (PST)
From: Rini Dutta <rinid@rocketmail.com>
Subject: how to make libpq on winnt using the
'win32.mak's
To: pgsql-hackers@postgreSQL.org
Cc: pgsql-interfaces@postgreSQL.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi

I'm running postgres v6.5.3. I need to make calls to
the functions in libpq in my code. For this I need the
files - libpq.lib/libpq.lib.dll/libpqdll.lib.

When I run 'nmake /f win32.mak' in the src directory,
it is unable to open/find config.h . If I use the
config.h generated as a result of 'configure' on
cygwin, it complains about other .h files not being
found. (I do not know if there is a way to do the
equivalent on the DOS Shell/Command Prompt )

Could anyone let me know how to build libpq to get
libpq.dll/libpq.lib/libpqdll.lib ? If somebody already
has a version of the same for postgres v6.5.3, even
that would be helpful.

Thanks,
Rini

ps : The administrators guide has a chapter on this
which I followed. (But it mentions Postgres v6.4
?!)
Here is an extract :

Chapter 20. Installation on Win32

Table of Contents
Building the libraries
Installing the libraries
Using the libraries

Build and installation instructions for
Postgres v6.4 client libraries on Win32.

Building the libraries

The makefiles included in Postgres are written for
Microsoft Visual C++, and will probably not work
with
other systems. It should be
possible to compile the libaries manually in other
cases.

To build the libraries, change directory into the
src
directory, and type the command

nmake /f win32.mak

This assumes that you have Visual C++ in your path.

The following files will be built:

interfaces\libpq\Release\libpq.dll - The
dynamically linkable frontend library

interfaces\libpq\Release\libpqdll.lib -
Import
library to link your program to libpq.dll

interfaces\libpq\Release\libpq.lib - Static
library version of the frontend library

bin\psql\Release\psql.exe - The Postgresql
interactive SQL monitor

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From bouncefilter Thu Feb 10 08:49:13 2000
Received: from web2906.mail.yahoo.com (web2906.mail.yahoo.com [128.11.68.49])
by hub.org (8.9.3/8.9.3) with SMTP id IAA88420
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 08:47:49 -0500 (EST)
(envelope-from rinid@rocketmail.com)
Received: (qmail 18405 invoked by uid 60001); 10 Feb 2000 13:47:48 -0000
Message-ID: <20000210134748.18404.qmail@web2906.mail.yahoo.com>
Received: from [206.114.238.111] by web2906.mail.yahoo.com;
Thu, 10 Feb 2000 05:47:48 PST
Date: Thu, 10 Feb 2000 05:47:48 -0800 (PST)
From: Rini Dutta <rinid@rocketmail.com>
Subject: how to make libpq on winnt using the 'win32.mak's
To: pgsql-interfaces@postgreSQL.org
Cc: pgsql-hackers@postgreSQL.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi

I'm running postgres v6.5.3. I need to make calls to
the functions in libpq in my code. For this I need
the
files - libpq.lib/libpq.lib.dll/libpqdll.lib.

When I run 'nmake /f win32.mak' in the src
directory,
it is unable to open/find config.h . If I use the
config.h generated as a result of 'configure' on
cygwin, it complains about other .h files not being
found. (I do not know if there is a way to do the
equivalent on the DOS Shell/Command Prompt )

Could anyone let me know how to build libpq to get
libpq.dll/libpq.lib/libpqdll.lib ? If somebody
already
has a version of the same for postgres v6.5.3, even
that would be helpful.

Thanks,
Rini

ps : The administrators guide has a chapter on this
which I followed. (But it mentions Postgres v6.4
?!)
Here is an extract :

Chapter 20. Installation on Win32

Table of Contents
Building the libraries
Installing the libraries
Using the libraries

Build and installation instructions for
Postgres v6.4 client libraries on Win32.

Building the libraries

The makefiles included in Postgres are written

for

Microsoft Visual C++, and will probably not work
with
other systems. It should be
possible to compile the libaries manually in

other

cases.

To build the libraries, change directory into the
src
directory, and type the command

nmake /f win32.mak

This assumes that you have Visual C++ in your

path.

The following files will be built:

interfaces\libpq\Release\libpq.dll - The
dynamically linkable frontend library

interfaces\libpq\Release\libpqdll.lib -
Import
library to link your program to libpq.dll

interfaces\libpq\Release\libpq.lib -

Static

library version of the frontend library

bin\psql\Release\psql.exe - The Postgresql
interactive SQL monitor

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From bouncefilter Thu Feb 10 09:17:45 2000
Received: from web2901.mail.yahoo.com (web2901.mail.yahoo.com [128.11.68.44])
by hub.org (8.9.3/8.9.3) with SMTP id JAA94622
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 09:16:51 -0500 (EST)
(envelope-from rinid@rocketmail.com)
Received: (qmail 18469 invoked by uid 60001); 10 Feb 2000 14:16:50 -0000
Message-ID: <20000210141650.18468.qmail@web2901.mail.yahoo.com>
Received: from [206.114.238.111] by web2901.mail.yahoo.com;
Thu, 10 Feb 2000 06:16:50 PST
Date: Thu, 10 Feb 2000 06:16:50 -0800 (PST)
From: Rini Dutta <rinid@rocketmail.com>
Subject: how to make libpq on winnt using the 'win32.mak's
To: pgsql-hackers@postgreSQL.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi

I'm running postgres v6.5.3. I need to make calls to
the functions in libpq in my code. For this I need the
files - libpq.lib/libpq.lib.dll/libpqdll.lib.

When I run 'nmake /f win32.mak' in the src directory,
it is unable to open/find config.h . If I use the
config.h generated as a result of 'configure' on
cygwin, it complains about other .h files not being
found. (I do not know if there is a way to do the
equivalent on the DOS Shell/Command Prompt )

Could anyone let me know how to build libpq to get
libpq.dll/libpq.lib/libpqdll.lib ? If somebody already
has a version of the same for postgres v6.5.3, even
that would be helpful.

Thanks,
Rini

ps : The administrators guide has a chapter on this
which I followed. (But it mentions Postgres v6.4
?!)
Here is an extract :

Chapter 20. Installation on Win32

Table of Contents
Building the libraries
Installing the libraries
Using the libraries

Build and installation instructions for

Postgres v6.4 client libraries on Win32.

Building the libraries

The makefiles included in Postgres are written

for

Microsoft Visual C++, and will probably not work
with
other systems. It should be
possible to compile the libaries manually in

other

cases.

To build the libraries, change directory into the
src
directory, and type the command

nmake /f win32.mak

This assumes that you have Visual C++ in your

path.

The following files will be built:

interfaces\libpq\Release\libpq.dll - The
dynamically linkable frontend library

interfaces\libpq\Release\libpqdll.lib -
Import
library to link your program to libpq.dll

interfaces\libpq\Release\libpq.lib -

Static

library version of the frontend library

bin\psql\Release\psql.exe - The Postgresql
interactive SQL monitor

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From bouncefilter Thu Feb 10 09:35:45 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id JAA01237
for <pgsql-hackers@postgresql.org>;
Thu, 10 Feb 2000 09:35:00 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgresql.org
id m12IuWD-0003kgC; Thu, 10 Feb 100 15:24 MET
Message-Id: <m12IuWD-0003kgC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] how to make libpq on winnt using the 'win32.mak's
In-Reply-To: <20000210141650.18468.qmail@web2901.mail.yahoo.com> from Rini
Dutta at "Feb 10, 2000 06:16:50 am"
To: Rini Dutta <rinid@rocketmail.com>
Date: Thu, 10 Feb 2000 15:24:29 +0100 (CET)
CC: pgsql-hackers@postgresql.org
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi

I'm running postgres v6.5.3. I need to make calls to
the functions in libpq in my code. For this I need the
files - libpq.lib/libpq.lib.dll/libpqdll.lib.

You find prepared .dll's under

src/bin/pgaccess/win32/dll

Wasn't there some utility to generate .lib files from .dll's?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Thu Feb 10 10:25:46 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA10619
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 10:25:21 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA15286;
Thu, 10 Feb 2000 10:23:59 -0500 (EST)
To: Chris <chris@bitmead.com>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] libpq
In-reply-to: <38A2AE00.9EB1BE9B@bitmead.com>
References: <38A2AE00.9EB1BE9B@bitmead.com>
Comments: In-reply-to Chris <chris@bitmead.com>
message dated "Thu, 10 Feb 2000 23:24:32 +1100"
Date: Thu, 10 Feb 2000 10:23:59 -0500
Message-ID: <15283.950196239@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris <chris@bitmead.com> writes:

What I have in mind is that a new API PQexecStream() doesn't retrieve
the results. The tuples are then read back one by one with
PQnextObject().

OK, but how does this interact with asynchrononous retrieval? It
should be possible to run it in a nonblocking (select-waiting) mode.

/* like PQexec, but streams the results */
PGresult *PQexecStream(PGconn *conn, const char *query)
/* retrieve the next object from a PGresult */
PGobject *PQnextObject(PGconn *conn)
/* get value from an object/tuple */
char *PQgetObjectValue(const PGobject *res, int field_num)
/* free tuple when done */
void PQclearObject(PGobject *obj)

There are two other big gaps here, which is that you haven't specified
how you represent (a) errors and (b) end of query result. I assume you
intend the initial PQexecStream call to wait for the first tuple to come
back, so *most* sorts of errors will be reported at that point, but
you have to be able to cope with errors reported later on too.

Rather than inventing a new PGobject struct type, I'd suggest returning
the partial results as PGresults. This has a couple of benefits:
* easy representation of an error encountered midway (you just return
an error PGresult).
* it's no big trick to "batch" retrieval, ie, return 10 or 100 tuples
at a time, if that happens to prove useful.
* each tuple batch could carry its own tuple description, which is
something you will need if you want to go anywhere with that
polymorphic-results idea.
* end-of-query could be represented as a PGresult with zero tuples.
(This would leave a null-pointer result open for use in the nonblock
case, to indicate "haven't got a response yet".)
* no need for an entire new set of API functions to query PGobjects.

BTW, an earlier proposal for this same sort of thing didn't see it
as an entirely new operating mode, but just a "limit" option added
to a variant of PQexec: the limit says "return no more than N tuples
per PQresult".

Oh yeah, can I fix the COPY protocol while I'm at it to conform more to
the other types of messages?

I looked at that before, and while COPY is certainly ugly as sin, it's
not clear that it's worth creating cross-version compatibility problems
to fix it. I'm inclined to leave it alone until such time as we
undertake a really massive protocol change (moving to CORBA, say).

BTW, what is this PQ thing? Does it stand for postquel? Are we ever
going to dump that?

Yes, and no. We aren't going to break existing app code by indulging
in cosmetic renaming of API names. Moreover we have to have *some*
prefix to minimize the probability of global-symbol conflicts with apps
and other libraries, so that one's as good as any.

To the extent that there is any system in the names in libpq (which I
admit ain't much), it's
PQfoo --- exported public-API routine
pqfoo --- internal routine not meant for apps to call, but must
be global symbol because it is called cross-module
PGfoo --- type name, enum const, etc
I'd suggest sticking to those conventions in any new code you write.

regards, tom lane

From bouncefilter Thu Feb 10 10:26:46 2000
Received: from sirius.edu.sollentuna.se (sirius.edu.sollentuna.se
[195.67.128.12]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA10769
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 10:25:59 -0500 (EST)
(envelope-from mha@sollentuna.net)
Received: by sirius.edu.sollentuna.se with Internet Mail Service (5.5.2448.0)
id <WJ7X42JW>; Thu, 10 Feb 2000 16:25:57 +0100
Message-ID:
<215896B6B5E1CF11BC5600805FFEA82103045A1C@sirius.edu.sollentuna.se>
From: Magnus Hagander <mha@sollentuna.net>
To: "'Rini Dutta'" <rinid@rocketmail.com>, pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] how to make libpq on winnt using the 'win32.mak's
Date: Thu, 10 Feb 2000 16:25:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

You will need to copy "config.h.win32" to "config.h" in the include
directory.

I think this patch to the docs should be what is needed.

*** install-win32.sgml.orig     Thu Feb 10 16:21:25 2000
--- install-win32.sgml  Thu Feb 10 16:22:49 2000
***************
*** 20,27 ****

  <Para>
  To build the libraries, change directory into the <filename>src</filename>
! directory, and type the command
  <programlisting>
  nmake /f win32.mak
  </programlisting>
  This assumes that you have <ProductName>Visual C++</ProductName> in your
--- 20,28 ----

<Para>
To build the libraries, change directory into the <filename>src</filename>
! directory, and type the commands
<programlisting>
+ copy include\config.h.win32 include\config.h
nmake /f win32.mak
</programlisting>
This assumes that you have <ProductName>Visual C++</ProductName> in your

Hmm. I just realised that that is for the current version, not 6.5.3.
However, you will need something like it - I'm afraid I don't remember
exactly what. Try either with the config.h.win32 from -current, or simply
try with an empty config.h.

//Magnus

-----Original Message-----
From: Rini Dutta [mailto:rinid@rocketmail.com]
Sent: den 10 februari 2000 15:17
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] how to make libpq on winnt using the 'win32.mak's

Hi

I'm running postgres v6.5.3. I need to make calls to
the functions in libpq in my code. For this I need the
files - libpq.lib/libpq.lib.dll/libpqdll.lib.

When I run 'nmake /f win32.mak' in the src directory,
it is unable to open/find config.h . If I use the
config.h generated as a result of 'configure' on
cygwin, it complains about other .h files not being
found. (I do not know if there is a way to do the
equivalent on the DOS Shell/Command Prompt )

Could anyone let me know how to build libpq to get
libpq.dll/libpq.lib/libpqdll.lib ? If somebody already
has a version of the same for postgres v6.5.3, even
that would be helpful.

Thanks,
Rini

ps : The administrators guide has a chapter on this
which I followed. (But it mentions Postgres v6.4
?!)
Here is an extract :

Chapter 20. Installation on Win32

Table of Contents
Building the libraries
Installing the libraries
Using the libraries

Build and installation instructions for

Postgres v6.4 client libraries on Win32.

Building the libraries

The makefiles included in Postgres are written

for

Microsoft Visual C++, and will probably not work
with
other systems. It should be
possible to compile the libaries manually in

other

cases.

To build the libraries, change directory into the
src
directory, and type the command

nmake /f win32.mak

This assumes that you have Visual C++ in your

path.

The following files will be built:

interfaces\libpq\Release\libpq.dll - The
dynamically linkable frontend library

interfaces\libpq\Release\libpqdll.lib -
Import
library to link your program to libpq.dll

interfaces\libpq\Release\libpq.lib -

Static

library version of the frontend library

bin\psql\Release\psql.exe - The Postgresql
interactive SQL monitor

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

************

From bouncefilter Thu Feb 10 10:26:46 2000
Received: from web2905.mail.yahoo.com (web2905.mail.yahoo.com [128.11.68.48])
by hub.org (8.9.3/8.9.3) with SMTP id KAA10894
for <pgsql-hackers@postgresql.org>;
Thu, 10 Feb 2000 10:26:32 -0500 (EST)
(envelope-from rinid@rocketmail.com)
Received: (qmail 7975 invoked by uid 60001); 10 Feb 2000 15:26:31 -0000
Message-ID: <20000210152631.7974.qmail@web2905.mail.yahoo.com>
Received: from [206.114.238.111] by web2905.mail.yahoo.com;
Thu, 10 Feb 2000 07:26:31 PST
Date: Thu, 10 Feb 2000 07:26:31 -0800 (PST)
From: Rini Dutta <rinid@rocketmail.com>
Subject: Re: [HACKERS] how to make libpq on winnt using the 'win32.mak's
To: Jan Wieck <wieck@debis.com>
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

You find prepared .dll's under

src/bin/pgaccess/win32/dll

Wasn't there some utility to generate .lib files
from .dll's?

Jan

I just checked. There is a dll - libpq.dll-6.5.1 (not
6.5.3 - the version of postgres I am using)

I still need the corresponding .lib file . A utility
which generates it would solve this problem, provided
the dll is compatible with postgresql v6.5.3, but I'm
not aware of such a utility.

Thasks,
Rini

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From bouncefilter Thu Feb 10 10:32:46 2000
Received: from sirius.edu.sollentuna.se (sirius.edu.sollentuna.se
[195.67.128.12]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA12384
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 10:32:43 -0500 (EST)
(envelope-from mha@sollentuna.net)
Received: by sirius.edu.sollentuna.se with Internet Mail Service (5.5.2448.0)
id <WJ7X42KC>; Thu, 10 Feb 2000 16:32:41 +0100
Message-ID:
<215896B6B5E1CF11BC5600805FFEA82103045A1D@sirius.edu.sollentuna.se>
From: Magnus Hagander <mha@sollentuna.net>
To: "'Jan Wieck'" <wieck@debis.com>, Rini Dutta <rinid@rocketmail.com>
Cc: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] how to make libpq on winnt using the 'win32.mak's
Date: Thu, 10 Feb 2000 16:32:40 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

Hi

I'm running postgres v6.5.3. I need to make calls to
the functions in libpq in my code. For this I need the
files - libpq.lib/libpq.lib.dll/libpqdll.lib.

You find prepared .dll's under

src/bin/pgaccess/win32/dll

Wasn't there some utility to generate .lib files from .dll's?

I think you can just do:

LIB /DEF:libpqdll.def

Haven't tested it, though.

(If you don't have the def file, you can do "dumpbin /exports <file>" to get
a listing of them.)

//Magnus

From bouncefilter Thu Feb 10 10:34:46 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA12773
for <hackers@postgresql.org>; Thu, 10 Feb 2000 10:34:44 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA19241
for <hackers@postgresql.org>; Thu, 10 Feb 2000 15:42:50 GMT
Sender: lockhart@hub.org
Message-ID: <38A2DC7A.210247A5@alumni.caltech.edu>
Date: Thu, 10 Feb 2000 15:42:50 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: createdb default arguments
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

createdb has lost its ability to supply a default database name, and
now *requires* an argument to run. Did we make this change because it
was difficult or impossible to get the default argument on some of our
supported platforms? Or did we make the change because it is "more
correct" or something?

I'm finding it annoying to retrain my fingers to type more stuff to
get the same functionality as before ;)

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 10 10:46:46 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA15690
for <pgsql-hackers@postgresql.org>;
Thu, 10 Feb 2000 10:46:21 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA27326;
Thu, 10 Feb 2000 10:45:30 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002101545.KAA27326@candle.pha.pa.us>
Subject: Re: [HACKERS] how to make libpq on winnt using the 'win32.mak's
In-Reply-To:
<215896B6B5E1CF11BC5600805FFEA82103045A1C@sirius.edu.sollentuna.se>
from Magnus Hagander at "Feb 10, 2000 04:25:56 pm"
To: Magnus Hagander <mha@sollentuna.net>
Date: Thu, 10 Feb 2000 10:45:30 -0500 (EST)
CC: "'Rini Dutta'" <rinid@rocketmail.com>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied.

[Charset windows-1252 unsupported, skipping...]

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 10 11:03:10 2000
Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22428
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:02:43 -0500 (EST) (envelope-from geek+@cmu.edu)
Received: from export.andrew.cmu.edu (EXPORT.ANDREW.CMU.EDU [128.2.23.2])
by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id LAA18256;
Thu, 10 Feb 2000 11:02:33 -0500 (EST)
Date: Thu, 10 Feb 2000 11:02:32 -0500 (EST)
Message-Id: <200002101602.LAA18256@smtp3.andrew.cmu.edu>
From: Brian E Gallew <geek+@cmu.edu>
X-Mailer: BatIMail version 3.2
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>,
Peter Eisentraut <peter_e@gmx.net>
In-reply-to: <2131.950027376@sss.pgh.pa.us>
Subject: Re: [HACKERS] psql and libpq fixes
References: <200002081602.LAA27899@candle.pha.pa.us>
<2131.950027376@sss.pgh.pa.us>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/signed; protocol="application/pgp-signature";
boundary="pgp-sign-Multipart_Thu_Feb_10_11:02:31_2000-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit

--pgp-sign-Multipart_Thu_Feb_10_11:02:31_2000-1
Content-Type: text/plain; charset=US-ASCII

Then <tgl@sss.pgh.pa.us> spoke up and said:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

This does bring up a thought --- should psql's kill-the-script-on-error
option perhaps zap the script only for errors committed outside of a
transaction block?

But on third thought, probably the thing that would be really useful
for "expected errors" is if there is a backslash-command that turns on
or off the kill-on-error behavior. (The command line switch would
merely set the initial state of this flag.) This way, a script could
use the option in an intelligent fashion:

Urhm, wouldn't a better idea be to have something like Ingres' "ON
ERROR" and "ON WARNING" settings? In Ingres esqlc, you can create
functions and then tell Ingres to execute them in the even of a
warning or error. Also, you can say "ON ERROR CONTINUE" and errors
will then be returned to the application as a status, but otherwise
ignored.

--
=====================================================================
| JAVA must have been developed in the wilds of West Virginia. |
| After all, why else would it support only single inheritance?? |
=====================================================================
| Finger geek@cmu.edu for my public key. |
=====================================================================

--pgp-sign-Multipart_Thu_Feb_10_11:02:31_2000-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface

iQBVAwUBOKLhF4dzVnzma+gdAQGpqgH7Bt/zmnRX6DIa//YBy3DEodhsPzbaHk2K
vkNAu7/6HkyROSmCTHKZ7gFh06ryqC2Wtr0g5FEdBavONK5GjoQBvQ==
=9ifw
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Feb_10_11:02:31_2000-1--

From bouncefilter Thu Feb 10 11:07:47 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA23689
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:06:49 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA05833;
Thu, 10 Feb 2000 11:06:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002101606.LAA05833@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and libpq fixes
In-Reply-To: <200002101602.LAA18256@smtp3.andrew.cmu.edu> from Brian E Gallew
at "Feb 10, 2000 11:02:32 am"
To: Brian E Gallew <geek+@cmu.edu>
Date: Thu, 10 Feb 2000 11:06:22 -0500 (EST)
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>,
Peter Eisentraut <peter_e@gmx.net>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Urhm, wouldn't a better idea be to have something like Ingres' "ON
ERROR" and "ON WARNING" settings? In Ingres esqlc, you can create
functions and then tell Ingres to execute them in the even of a
warning or error. Also, you can say "ON ERROR CONTINUE" and errors
will then be returned to the application as a status, but otherwise
ignored.

Yes, seems like those are the accepted words to use.
-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 10 11:08:47 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA24113
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 11:08:23 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Zebra.DoCS.UU.SE (e99re41@Zebra.DoCS.UU.SE [130.238.9.158])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA21585;
Thu, 10 Feb 2000 17:08:15 +0100 (MET)
Received: from localhost (e99re41@localhost) by Zebra.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id RAA19091;
Thu, 10 Feb 2000 17:08:14 +0100
X-Authentication-Warning: Zebra.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 10 Feb 2000 17:08:14 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] createdb default arguments
In-Reply-To: <38A2DC7A.210247A5@alumni.caltech.edu>
Message-ID: <Pine.GSO.4.02A.10002101706420.19049-100000@Zebra.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 10 Feb 2000, Thomas Lockhart wrote:

createdb has lost its ability to supply a default database name, and
now *requires* an argument to run. Did we make this change because it
was difficult or impossible to get the default argument on some of our
supported platforms? Or did we make the change because it is "more
correct" or something?

What was supposed to be the default argument?

I'm finding it annoying to retrain my fingers to type more stuff to
get the same functionality as before ;)

Can be fixed. Probably something that happened during the massive rewrite
phase.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 10 11:13:47 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA25551
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:13:03 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Zebra.DoCS.UU.SE (e99re41@Zebra.DoCS.UU.SE [130.238.9.158])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA22044;
Thu, 10 Feb 2000 17:12:55 +0100 (MET)
Received: from localhost (e99re41@localhost) by Zebra.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id RAA19095;
Thu, 10 Feb 2000 17:12:54 +0100
X-Authentication-Warning: Zebra.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 10 Feb 2000 17:12:54 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Brian E Gallew <geek+@cmu.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and libpq fixes
In-Reply-To: <200002101602.LAA18256@smtp3.andrew.cmu.edu>
Message-ID: <Pine.GSO.4.02A.10002101708310.19049-100000@Zebra.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 10 Feb 2000, Brian E Gallew wrote:

Then <tgl@sss.pgh.pa.us> spoke up and said:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

This does bring up a thought --- should psql's kill-the-script-on-error
option perhaps zap the script only for errors committed outside of a
transaction block?

But on third thought, probably the thing that would be really useful
for "expected errors" is if there is a backslash-command that turns on
or off the kill-on-error behavior. (The command line switch would
merely set the initial state of this flag.) This way, a script could
use the option in an intelligent fashion:

FYI, the commands are
\set EXIT_ON_ERROR
and
\unset EXIT_ON_ERROR
It's a normal psql variable, but incidentally the syntax seems kind of
easy to remember.

Urhm, wouldn't a better idea be to have something like Ingres' "ON
ERROR" and "ON WARNING" settings? In Ingres esqlc, you can create
functions and then tell Ingres to execute them in the even of a
warning or error. Also, you can say "ON ERROR CONTINUE" and errors
will then be returned to the application as a status, but otherwise
ignored.

That's very nice and all, but psql doesn't work that way. I'm not sure how
other dbs organize their front-end internally, but that sort of scheme
would really take psql places we might not want it to go, and for which it
hasn't been designed -- namely, to be a programming language.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 10 11:17:47 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA26728
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:16:53 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA09744;
Thu, 10 Feb 2000 11:16:31 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002101616.LAA09744@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and libpq fixes
In-Reply-To: <Pine.GSO.4.02A.10002101708310.19049-100000@Zebra.DoCS.UU.SE>
from
Peter Eisentraut at "Feb 10, 2000 05:12:54 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 10 Feb 2000 11:16:31 -0500 (EST)
CC: Brian E Gallew <geek+@cmu.edu>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

FYI, the commands are
\set EXIT_ON_ERROR
and
\unset EXIT_ON_ERROR
It's a normal psql variable, but incidentally the syntax seems kind of
easy to remember.

Can we change that to the more standard ON_ERROR_STOP?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 10 11:18:47 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA27276
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:18:34 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Zebra.DoCS.UU.SE (e99re41@Zebra.DoCS.UU.SE [130.238.9.158])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA22557;
Thu, 10 Feb 2000 17:18:31 +0100 (MET)
Received: from localhost (e99re41@localhost) by Zebra.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id RAA19131;
Thu, 10 Feb 2000 17:18:30 +0100
X-Authentication-Warning: Zebra.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 10 Feb 2000 17:18:30 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Brian E Gallew <geek+@cmu.edu>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and libpq fixes
In-Reply-To: <200002101616.LAA09744@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.10002101718110.19049-100000@Zebra.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 10 Feb 2000, Bruce Momjian wrote:

FYI, the commands are
\set EXIT_ON_ERROR
and
\unset EXIT_ON_ERROR
It's a normal psql variable, but incidentally the syntax seems kind of
easy to remember.

Can we change that to the more standard ON_ERROR_STOP?

Consider it done.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 10 11:20:47 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA27942
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 11:20:30 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA10092;
Thu, 10 Feb 2000 11:19:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002101619.LAA10092@candle.pha.pa.us>
Subject: Re: [HACKERS] createdb default arguments
In-Reply-To: <Pine.GSO.4.02A.10002101706420.19049-100000@Zebra.DoCS.UU.SE>
from
Peter Eisentraut at "Feb 10, 2000 05:08:14 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 10 Feb 2000 11:19:06 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 10 Feb 2000, Thomas Lockhart wrote:

createdb has lost its ability to supply a default database name, and
now *requires* an argument to run. Did we make this change because it
was difficult or impossible to get the default argument on some of our
supported platforms? Or did we make the change because it is "more
correct" or something?

What was supposed to be the default argument?

Peter reminder that perl does not compile, I believe because of pqbool.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 10 11:27:47 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA29842
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 11:27:23 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Zebra.DoCS.UU.SE (e99re41@Zebra.DoCS.UU.SE [130.238.9.158])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA23392;
Thu, 10 Feb 2000 17:27:15 +0100 (MET)
Received: from localhost (e99re41@localhost) by Zebra.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id RAA19169;
Thu, 10 Feb 2000 17:27:13 +0100
X-Authentication-Warning: Zebra.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 10 Feb 2000 17:27:13 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] createdb default arguments
In-Reply-To: <38A2E7B5.DB3D513E@alumni.caltech.edu>
Message-ID: <Pine.GSO.4.02A.10002101726580.19049-100000@Zebra.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 10 Feb 2000, Thomas Lockhart wrote:

createdb has lost its ability to supply a default database name...

What was supposed to be the default argument?

Ah! Same as for psql: the account name on the process running it (ie
the user's name).

Will be done.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 10 11:22:47 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA28557
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 11:22:40 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA19991;
Thu, 10 Feb 2000 16:30:45 GMT
Sender: lockhart@hub.org
Message-ID: <38A2E7B5.DB3D513E@alumni.caltech.edu>
Date: Thu, 10 Feb 2000 16:30:45 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] createdb default arguments
References: <Pine.GSO.4.02A.10002101706420.19049-100000@Zebra.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

createdb has lost its ability to supply a default database name...

What was supposed to be the default argument?

Ah! Same as for psql: the account name on the process running it (ie
the user's name).

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 10 11:35:50 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA32223
for <pgsql-interfaces@postgresql.org>;
Thu, 10 Feb 2000 11:34:58 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12IwYM-000LEMC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-interfaces@postgresql.org;
Thu, 10 Feb 2000 10:34:50 -0600 (CST)
Date: Thu, 10 Feb 2000 10:34:50 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
Cc: Bryan White <bryan@arcamax.com>, pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] The persistance of C functions
Message-ID: <20000210103450.A8610@rice.edu>
References: <00bb01bf7344$fe1dcf00$2dd260d1@arcamax.com>
<Pine.LNX.3.96.1000210103409.21359B-100000@ara.zf.jcu.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.LNX.3.96.1000210103409.21359B-100000@ara.zf.jcu.cz>;
from zakkr@zf.jcu.cz on Thu, Feb 10, 2000 at 10:42:29AM +0100

On Thu, Feb 10, 2000 at 10:42:29AM +0100, Karel Zak - Zakkr wrote:

On Wed, 9 Feb 2000, Bryan White wrote:

If I use CREATE FUNCTION for a C function in a .so file and then use the
function and then change and recompile the function, what steps are needed
to see the change?

As I see it the options are:
A: do nothing, the function is reloaded on every invocation.
B: Reopen the connection to the backend
C: Restart the postmaster

I suspect B is correct but I would like to hear someone confirm it.

'B' is right - the postgreSQL not has any persisten cache for this, and
if you restart connection a backend reload this information again.

Or you can drop/(re)create a function, it is total safe solution.

Not _totally_ safe: if you've got anything that refers to that function,
like a user defined type definition, drop/(re)create will change the
function's oid in the pg_proc table, causing errors when the old
function is looked up. Hmm, an ALTER FUNCTION command might be nice...

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Thu Feb 10 11:48:47 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA36447
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:48:25 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA15709
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:48:15 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Solution for LIMIT cost estimation
Date: Thu, 10 Feb 2000 11:48:15 -0500
Message-ID: <15706.950201295@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

We have discussed in the past the need for the optimizer to take LIMIT
into account when choosing plans. Currently, since planning is done
on the basis of total plan cost for retrieving all tuples, there's
no way to prefer a "fast start" plan over "slow start". But that's
what you want if there's a small LIMIT.

Up to now I haven't seen a practical way to fix this, because the
optimizer does its planning bottom-up (start with scan plans, then
make joins, etc) and there's no easy way to know at the bottom of
the pyramid whether you can expect to take advantage of a LIMIT that
exists at the top. For example, if there's a SORT or GROUP step
in between, you can't apply the LIMIT to the bottom level; but the
bottom guys don't know whether there will be such a step.

I have thought of a fairly clean way to attack this problem, which
is to represent the cost of a plan in two parts instead of only one.
Instead of just "cost", have "startup cost" and "cost per tuple".
(Actually, it'd probably be easier to work with "startup cost" and
"total cost if all tuples are retrieved", but that's a trivial
representational detail; the point is that our cost model will now be
of the form a*N+b when N tuples are retrieved.) It'd be pretty easy
to produce plausible numbers for all the plan types we use. Then,
the plan comparators would keep any plan that wins on either startup
or total cost, rather than only considering total cost. Finally
at the top level of planning, when there is a LIMIT the preferred
plan would be selected by comparing a*LIMIT+b rather than total cost.

I think I can get this done before beta, but before I go into hack-
attack mode I wanted to run it up the flagpole and see if anyone
has any complaints or better ideas.

regards, tom lane

From bouncefilter Thu Feb 10 11:56:47 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA38596
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:55:56 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA10981;
Thu, 10 Feb 2000 11:55:00 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002101655.LAA10981@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and libpq fixes
In-Reply-To: <38A2EEC9.F9A79E23@alumni.caltech.edu> from Thomas Lockhart at
"Feb 10, 2000 05:00:57 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 10 Feb 2000 11:55:00 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, Brian E Gallew <geek+@cmu.edu>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

FYI, the commands are
\set EXIT_ON_ERROR
and
\unset EXIT_ON_ERROR
It's a normal psql variable, but incidentally the syntax seems kind of
easy to remember.

Can we change that to the more standard ON_ERROR_STOP?

Any chance of multi-word options? Like "\set on error stop"?

And at least part of the reason other systems can do some error
recovery is that they decouple the parser from the backend, so the
parser is carried closer to the client, and the client can be more
certain about what is being done. But that carries a lot of baggage
too...

If/when we do get more decoupling, it might be done through a Corba
interface, which would allow us to get away from the string-based
client/server protocol, and will handle typing, marshalling, byte
ordering, etc more-or-less transparently.

I think we would have to have more need for multi-word setttings than
this one before adding that complexity.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 10 11:53:50 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA37873
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 11:53:10 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA20075;
Thu, 10 Feb 2000 17:00:57 GMT
Sender: lockhart@hub.org
Message-ID: <38A2EEC9.F9A79E23@alumni.caltech.edu>
Date: Thu, 10 Feb 2000 17:00:57 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, Brian E Gallew <geek+@cmu.edu>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and libpq fixes
References: <Pine.GSO.4.02A.10002101718110.19049-100000@Zebra.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

FYI, the commands are
\set EXIT_ON_ERROR
and
\unset EXIT_ON_ERROR
It's a normal psql variable, but incidentally the syntax seems kind of
easy to remember.

Can we change that to the more standard ON_ERROR_STOP?

Any chance of multi-word options? Like "\set on error stop"?

And at least part of the reason other systems can do some error
recovery is that they decouple the parser from the backend, so the
parser is carried closer to the client, and the client can be more
certain about what is being done. But that carries a lot of baggage
too...

If/when we do get more decoupling, it might be done through a Corba
interface, which would allow us to get away from the string-based
client/server protocol, and will handle typing, marshalling, byte
ordering, etc more-or-less transparently.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 10 12:13:48 2000
Received: from web2904.mail.yahoo.com (web2904.mail.yahoo.com [128.11.68.47])
by hub.org (8.9.3/8.9.3) with SMTP id MAA42921
for <pgsql-hackers@postgresql.org>;
Thu, 10 Feb 2000 12:12:55 -0500 (EST)
(envelope-from rinid@rocketmail.com)
Received: (qmail 348 invoked by uid 60001); 10 Feb 2000 17:12:54 -0000
Message-ID: <20000210171254.347.qmail@web2904.mail.yahoo.com>
Received: from [206.114.238.111] by web2904.mail.yahoo.com;
Thu, 10 Feb 2000 09:12:54 PST
Date: Thu, 10 Feb 2000 09:12:54 -0800 (PST)
From: Rini Dutta <rinid@rocketmail.com>
Subject: RE: [HACKERS] how to make libpq on winnt using the 'win32.mak's
To: Magnus Hagander <mha@sollentuna.net>, pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi
I managed to build it using an empty config.h file as
you suggested. I had to comment out parts of some
header files where memmove is #defined to bcopy.
Now I have to build my code with the library, and see
if it works.
Thanks!
Rini
ps : I have not tried to get the lib files from the
existing dll (v6.5.1) since I preferred to 'make' it.

--- Magnus Hagander <mha@sollentuna.net> wrote:

You will need to copy "config.h.win32" to "config.h"
in the include
directory.

I think this patch to the docs should be what is
needed.

*** install-win32.sgml.orig     Thu Feb 10 16:21:25
2000
--- install-win32.sgml  Thu Feb 10 16:22:49 2000
***************
*** 20,27 ****

<Para>
To build the libraries, change directory into the
<filename>src</filename>
! directory, and type the command
<programlisting>
nmake /f win32.mak
</programlisting>
This assumes that you have <ProductName>Visual
C++</ProductName> in your
--- 20,28 ----

<Para>
To build the libraries, change directory into the
<filename>src</filename>
! directory, and type the commands
<programlisting>
+ copy include\config.h.win32 include\config.h
nmake /f win32.mak
</programlisting>
This assumes that you have <ProductName>Visual
C++</ProductName> in your

Hmm. I just realised that that is for the current
version, not 6.5.3.
However, you will need something like it - I'm
afraid I don't remember
exactly what. Try either with the config.h.win32
from -current, or simply
try with an empty config.h.

//Magnus

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From bouncefilter Thu Feb 10 12:26:25 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA45686
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 12:23:42 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Zebra.DoCS.UU.SE (e99re41@Zebra.DoCS.UU.SE [130.238.9.158])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id SAA27615;
Thu, 10 Feb 2000 18:23:37 +0100 (MET)
Received: from localhost (e99re41@localhost) by Zebra.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id SAA19270;
Thu, 10 Feb 2000 18:23:36 +0100
X-Authentication-Warning: Zebra.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 10 Feb 2000 18:23:36 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Brian E Gallew <geek+@cmu.edu>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and libpq fixes
In-Reply-To: <38A2EEC9.F9A79E23@alumni.caltech.edu>
Message-ID: <Pine.GSO.4.02A.10002101817550.19049-100000@Zebra.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 10 Feb 2000, Thomas Lockhart wrote:

FYI, the commands are
\set EXIT_ON_ERROR
and
\unset EXIT_ON_ERROR
It's a normal psql variable, but incidentally the syntax seems kind of
easy to remember.

Can we change that to the more standard ON_ERROR_STOP?

Any chance of multi-word options? Like "\set on error stop"?

Actually, that command would set "on" to the value of "errorstop". \set
doesn't have any hard-coded parsing rules, like the SQL look-a-similar, it
just sets variables. They can carry configuration information (like the
above), application state (LASTOID), or whatever you want (\set foo `date
%Y` \\ insert into mytbl values (:foo);). Kind of like a shell or Tcl, I
think.

And at least part of the reason other systems can do some error
recovery is that they decouple the parser from the backend, so the
parser is carried closer to the client, and the client can be more
certain about what is being done. But that carries a lot of baggage
too...

If/when we do get more decoupling, it might be done through a Corba
interface, which would allow us to get away from the string-based
client/server protocol, and will handle typing, marshalling, byte
ordering, etc more-or-less transparently.

At that point we may choose to write a completely new client. ;)

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 10 12:56:48 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA54964
for <pgsql-hackers@postgresql.org>;
Thu, 10 Feb 2000 12:50:35 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12Ixje-000LEMC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Thu, 10 Feb 2000 11:50:34 -0600 (CST)
Date: Thu, 10 Feb 2000 11:50:33 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Message-ID: <20000210115033.B8742@rice.edu>
References: <15706.950201295@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <15706.950201295@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Thu, Feb 10, 2000 at 11:48:15AM -0500

Tom -
This would fit in really well with some ideas I've been working on
with remote table access. Mariposa makes the design decision that
anything might be remote, and the optimizer doesn't get to know what
is and what isn't, so they run the single-site optimization, basically
assuming everything is local, then fragment the plan and ship parts off
for remote execution.

I've been thinking about ways to let the optimizer know about remote
tables, and the capabilites of the server serving the remote table.
I won't fill in the details here. I'm writing up a proposal for how
this will all work: I've got a telecon today to gauge administrative
support for developing this during work hours, which will _dramatically_
speed up it's implementation ;-)

It does seem to me, however, that the cost of going remote is best
described with the a*N+b model you're describing here: for remote tables,
b will be large, and dominate, unless you're pulling a _lot_ of tuples.

Suffice to say, sounds great to me.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

On Thu, Feb 10, 2000 at 11:48:15AM -0500, Tom Lane wrote:

We have discussed in the past the need for the optimizer to take LIMIT
into account when choosing plans. Currently, since planning is done
on the basis of total plan cost for retrieving all tuples, there's
no way to prefer a "fast start" plan over "slow start". But that's
what you want if there's a small LIMIT.

Up to now I haven't seen a practical way to fix this, because the
optimizer does its planning bottom-up (start with scan plans, then
make joins, etc) and there's no easy way to know at the bottom of
the pyramid whether you can expect to take advantage of a LIMIT that
exists at the top. For example, if there's a SORT or GROUP step
in between, you can't apply the LIMIT to the bottom level; but the
bottom guys don't know whether there will be such a step.

I have thought of a fairly clean way to attack this problem, which
is to represent the cost of a plan in two parts instead of only one.
Instead of just "cost", have "startup cost" and "cost per tuple".
(Actually, it'd probably be easier to work with "startup cost" and
"total cost if all tuples are retrieved", but that's a trivial
representational detail; the point is that our cost model will now be
of the form a*N+b when N tuples are retrieved.) It'd be pretty easy
to produce plausible numbers for all the plan types we use. Then,
the plan comparators would keep any plan that wins on either startup
or total cost, rather than only considering total cost. Finally
at the top level of planning, when there is a LIMIT the preferred
plan would be selected by comparing a*LIMIT+b rather than total cost.

I think I can get this done before beta, but before I go into hack-
attack mode I wanted to run it up the flagpole and see if anyone
has any complaints or better ideas.

regards, tom lane

************

From bouncefilter Thu Feb 10 12:52:48 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA55371
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 12:52:14 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id MAA06798;
Thu, 10 Feb 2000 12:51:43 -0500
Message-ID: <38A2FAA7.B48B3B2@wgcr.org>
Date: Thu, 10 Feb 2000 12:51:35 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] createdb default arguments
References: <200002101619.LAA10092@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

What was supposed to be the default argument?

Peter reminder that perl does not compile, I believe because of pqbool.

He's fixed that, at least in the version I was building the other night
when I was griping about the man pages.....

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Thu Feb 10 13:22:48 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA63140
for <hackers@postgresql.org>; Thu, 10 Feb 2000 13:21:54 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12IyDs-000LEMC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for hackers@postgresql.org; Thu, 10 Feb 2000 12:21:48 -0600 (CST)
Date: Thu, 10 Feb 2000 12:21:48 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Postgres Hackers List <hackers@postgresql.org>
Subject: make_ctags script
Message-ID: <20000210122148.A9029@rice.edu>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ"
User-Agent: Mutt/1.0i

--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii

I have a question about the make_ctags script in the src/tools
directory. What are the -d and -t flags to ctags supposed to do?
My version of ctags:

wallace$ ctags --version
Exuberant Ctags 3.2.4, by Darren Hiebert <darren@hiebert.com>

Doesn't recognize them.

Oh, and one little fix: The sym-link generator puts 'tags' symlinks
in the CVS directories. Patch attached.

Ross

--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="make_ctags.patch"

Index: make_ctags
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/tools/make_ctags,v
retrieving revision 1.3
diff -r1.3 make_ctags
9c9
< find . -type d -print |while read DIR
---

find . -name 'CVS' -prune -o -type d -print |while read DIR

--lrZ03NoBR/3+SXJZ--

From bouncefilter Thu Feb 10 13:26:55 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA64137
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 13:26:12 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id KAA14855
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 10:25:44 -0800 (PST)
Message-Id: <3.0.1.32.20000210102333.010c2da0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 10 Feb 2000 10:23:33 -0800
To: pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] minor bug...
In-Reply-To: <10515.950153879@sss.pgh.pa.us>
References: <3.0.1.32.20000209192919.01075de0@mail.pacifier.com>
<3.0.1.32.20000209171726.010ad1b0@mail.pacifier.com>
<3.0.1.32.20000208183105.0108bd60@mail.pacifier.com>
<3.0.1.32.20000208183105.0108bd60@mail.pacifier.com>
<3.0.1.32.20000209171726.010ad1b0@mail.pacifier.com>
<3.0.1.32.20000209192919.01075de0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

I've submitted a patch to pgsql-patches to fix the following
limitations on type bool:

test=> create table foo(b bool);
CREATE
test=> create index foo_idx on foo(b);
ERROR: Can't find a default operator class for type 16.
test=> select * from foo where b<=b;
ERROR: Unable to identify an operator '<=' for types 'bool' and 'bool'
You will have to retype this query using an explicit cast
test=> select * from foo where b>=b;
ERROR: Unable to identify an operator '>=' for types 'bool' and 'bool'
You will have to retype this query using an explicit cast
test=>

The oversite that leads to one not being able to define an index on
type bool I can understand, but who the heck would bother to go to
all the trouble of adding type "bool" and only define four of the
six standard comparison operators?

Oh well...

Tom suggested I submit the patch to pgsql-patches, and I ran my OID
assignments for the new procs, bool_ops, etc past Thomas at Tom's
suggestion, the regression tests pass, I've done some additional testing,
etc.

I didn't look into adding bool to the hash ops defined in pg_amop,
after all yesterday afternoon was the first I'd looked into adding
something to the catalog code and the getting the above set of
functions in took me four hours of reading docs and code, testing
making the diff, etc.

I assume not having a type added to hash ops isn't fatal, because
"numeric" isn't there and Jan strikes me as being a very thorough
guy...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Thu Feb 10 13:35:48 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA66705
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 13:35:29 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA19445;
Thu, 10 Feb 2000 13:34:48 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002101834.NAA19445@candle.pha.pa.us>
Subject: Re: [HACKERS] make_ctags script
In-Reply-To: <20000210122148.A9029@rice.edu> from "Ross J. Reedstrom" at "Feb
10, 2000 12:21:48 pm"
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Date: Thu, 10 Feb 2000 13:34:48 -0500 (EST)
CC: Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have a question about the make_ctags script in the src/tools
directory. What are the -d and -t flags to ctags supposed to do?
My version of ctags:

wallace$ ctags --version
Exuberant Ctags 3.2.4, by Darren Hiebert <darren@hiebert.com>

BSD ctags has:

-d create tags for #defines that don't take arguments; #defines that
take arguments are tagged automatically.

-t create tags for typedefs, structs, unions, and enums.

Doesn't recognize them.

Oh, and one little fix: The sym-link generator puts 'tags' symlinks
in the CVS directories. Patch attached.

Applied.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Feb 10 15:04:49 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA09324
for <hackers@postgresql.org>; Thu, 10 Feb 2000 15:04:39 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63617 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S75840AbQBJUD5>;
Thu, 10 Feb 2000 21:03:57 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12Izqo-0000PP-00; Thu, 10 Feb 2000 21:06:06 +0100
Date: Thu, 10 Feb 2000 21:06:06 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] createdb default arguments
In-Reply-To: <38A2E7B5.DB3D513E@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0002102104240.1014-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-10, Thomas Lockhart mentioned:

createdb has lost its ability to supply a default database name...

What was supposed to be the default argument?

Ah! Same as for psql: the account name on the process running it (ie
the user's name).

This is fixed now, but I don't suppose you want dropdb's default behaviour
to be along those same lines. I'd have a serious problem with that, even
though old destroydb used to do that.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 10 15:12:49 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA11732
for <pgsql-hackers@postgresql.org>;
Thu, 10 Feb 2000 15:12:09 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62363 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S45122AbQBJUL0>;
Thu, 10 Feb 2000 21:11:26 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12IzyA-0000QO-00
for pgsql-hackers@postgresql.org; Thu, 10 Feb 2000 21:13:42 +0100
Date: Thu, 10 Feb 2000 21:13:42 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: psql options
Message-ID: <Pine.LNX.4.21.0002102111160.1014-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

Having taken the discussion under consideration I will, barring protests
and late good ideas, do the following:

-e will echo queries sent to backend (as in 6.*)
-a will echo lines from the script literally
-n will be deprecated

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 10 15:14:50 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA12802
for <pgsql-hackers@postgresql.org>;
Thu, 10 Feb 2000 15:14:39 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61191 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S77891AbQBJUNz>;
Thu, 10 Feb 2000 21:13:55 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12J00Q-0000QQ-00; Thu, 10 Feb 2000 21:16:02 +0100
Date: Thu, 10 Feb 2000 21:16:02 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] psql and libpq fixes
In-Reply-To: <38A2EEC9.F9A79E23@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0002102114140.1014-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 2000-02-10, Thomas Lockhart mentioned:

FYI, the commands are
\set EXIT_ON_ERROR
and
\unset EXIT_ON_ERROR
It's a normal psql variable, but incidentally the syntax seems kind of
easy to remember.

Can we change that to the more standard ON_ERROR_STOP?

Any chance of multi-word options? Like "\set on error stop"?

You can do
\set 'some string with any character \t\001\n\n' enabled
but that's a little hard to type. ;)

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Feb 10 16:03:50 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA28039
for <hackers@postgresql.org>; Thu, 10 Feb 2000 16:03:36 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12J0kR-000LEMC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for hackers@postgresql.org; Thu, 10 Feb 2000 15:03:35 -0600 (CST)
Date: Thu, 10 Feb 2000 15:03:35 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] make_ctags script
Message-ID: <20000210150335.B9514@rice.edu>
References: <20000210122148.A9029@rice.edu>
<200002101834.NAA19445@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <200002101834.NAA19445@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Thu, Feb 10, 2000 at 01:34:48PM
-0500

On Thu, Feb 10, 2000 at 01:34:48PM -0500, Bruce Momjian wrote:

I have a question about the make_ctags script in the src/tools
directory. What are the -d and -t flags to ctags supposed to do?
My version of ctags:

wallace$ ctags --version
Exuberant Ctags 3.2.4, by Darren Hiebert <darren@hiebert.com>

BSD ctags has:

-d create tags for #defines that don't take arguments; #defines that
take arguments are tagged automatically.

-t create tags for typedefs, structs, unions, and enums.

Ah, O.K. then: Exuberant Ctags does all these by default. Just wanted
to make sure I wan't missing anything.

Slightly off topic: While going through the current source, comparing
to Mariposa, I've seen little traces of old code: some ideas seem to
have been reinvented and reimplemented a number of times. Going back
and digging into Postgres95, and the last postquel based release,
postgres-v4r2, to see how they were implemented, it's been fun seeing
"debate/design by comment block" from some of the original university
developers. In particular, one block with a 12 line NOOOOOO! in
backend/commands/version.c had me rolling on the floor. Ah, I see it lives
on in _deadcode. In general, the functional comments in the current code
are more informative, but not as much fun ;-)

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Thu Feb 10 16:38:50 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA51759
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 16:37:52 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id VAA20527;
Thu, 10 Feb 2000 21:45:53 GMT
Sender: lockhart@hub.org
Message-ID: <38A33191.AE082DC8@alumni.caltech.edu>
Date: Thu, 10 Feb 2000 21:45:53 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] minor bug...
References: <3.0.1.32.20000209192919.01075de0@mail.pacifier.com>
<3.0.1.32.20000209171726.010ad1b0@mail.pacifier.com>
<3.0.1.32.20000208183105.0108bd60@mail.pacifier.com>
<3.0.1.32.20000208183105.0108bd60@mail.pacifier.com>
<3.0.1.32.20000209171726.010ad1b0@mail.pacifier.com>
<3.0.1.32.20000209192919.01075de0@mail.pacifier.com>
<3.0.1.32.20000210102333.010c2da0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I assume not having a type added to hash ops isn't fatal, because
"numeric" isn't there and Jan strikes me as being a very thorough
guy...

A hash index is probably even less useful than the btree index for
this type, unless it can be used with multi-column indices. Because
the hash will chain duplicate values into a list of some kind, and
you'll get *long* lists.

Find and steal the code for "char" (the real one-byte character type).
But a one-bit hash is what you really want, so it may be better to
implement your own.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 10 16:43:50 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA53735
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 16:43:36 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id VAA20535;
Thu, 10 Feb 2000 21:51:41 GMT
Sender: lockhart@hub.org
Message-ID: <38A332ED.15CA6B2B@alumni.caltech.edu>
Date: Thu, 10 Feb 2000 21:51:41 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] createdb default arguments
References: <Pine.LNX.4.21.0002102104240.1014-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is fixed now, but I don't suppose you want dropdb's default behaviour
to be along those same lines. I'd have a serious problem with that, even
though old destroydb used to do that.

Hmm, I think I see a correct answer in the way you phrased the
question :)

You are right, the downside to a default argument for dropdb would
argue strongly for supplying *no* default argument. For "create" kinds
of things, the downside is minimal, and the convenience is high.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 10 17:08:51 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA63440
for <hackers@postgreSQL.org>; Thu, 10 Feb 2000 17:08:14 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id WAA20719;
Thu, 10 Feb 2000 22:15:24 GMT
Sender: lockhart@hub.org
Message-ID: <38A3387C.2BFB489E@alumni.caltech.edu>
Date: Thu, 10 Feb 2000 22:15:24 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ivo Simicevic <ivo@ultra.hr>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: ECPG documentation
References: <3872F1C3.8007B24B@hotgames.com>
<38736C26.4A9B8777@alumni.caltech.edu>
<20000105185234.H740@ultra.hr>
<38738906.91E42C78@alumni.caltech.edu>
<41DC7537.58091799@ironmountainsystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I just wanted to let you know that some time ago, after contacting
Michael Meskes I have started working on ECPG documentation.
... you can see some text file sketches on my web at
http://www.ultra.hr/gpl/ecpg

Looks great! Hope you find time to get back to it, and I'll be happy
to help with sgml markup.
btw, if you could finish a first draft (or have enough sections to be
usable) within a month or so there is a good chance we can get it
included in the v7.0 release. Much later than that and we'll probably
miss the window...

Hello Ivo. Have you had a chance to make progress on your docs? I'm
sure people would be *very* interested in them for the upcoming
release, and if you need some help on finishing the writing or editing
I'm sure there will be some volunteers.

Regards.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Thu Feb 10 18:05:53 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA03709
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 18:05:22 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA08644; Fri, 11 Feb 2000 10:04:50 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdUljTC_;
Fri Feb 11 10:04:28 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA27230; Fri, 11 Feb 2000 10:04:27 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdFo7gp_; Fri Feb 11 10:03:20 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA03837;
Fri, 11 Feb 2000 10:03:20 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA05121; Fri, 11 Feb 2000 10:02:42 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
Date: Fri, 11 Feb 2000 10:01:46 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <15706.950201295@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A couple of things occur to me. One is that it sounds like this
proposal could mean that successive SELECTS with LIMIT could
execute completely different plans and therefore return inconsistent
results. For example, let's say I have 26 customers a through z.
My first call to SELECT name from customer limit 3 might return...
a
b
c
and then my next SELECT name from customer limit 3, 3 might return
a
b
c
again, when I might expect d e f. Of course in this case I could SORT,
but unless name is a unique field that won't work. I could sort on oid,
but that is expensive if I don't really want it. I could use a cursor,
but web pages don't like to do that because you don't know how long you
may need to keep the cursor open.

In short, I think the fact that limit doesn't alter the plan may
be more of a feature than a bug.

The other thing is, I would like at some stage to change limit so
that it is attached to a SELECT rather than an entire query so
you could...
SELECT * from x where y in (SELECT y from z LIMIT 10) LIMIT 20;
and I'm not sure how this would interact with that.

Tom Lane wrote:

We have discussed in the past the need for the optimizer to take LIMIT
into account when choosing plans. Currently, since planning is done
on the basis of total plan cost for retrieving all tuples, there's
no way to prefer a "fast start" plan over "slow start". But that's
what you want if there's a small LIMIT.

Up to now I haven't seen a practical way to fix this, because the
optimizer does its planning bottom-up (start with scan plans, then
make joins, etc) and there's no easy way to know at the bottom of
the pyramid whether you can expect to take advantage of a LIMIT that
exists at the top. For example, if there's a SORT or GROUP step
in between, you can't apply the LIMIT to the bottom level; but the
bottom guys don't know whether there will be such a step.

I have thought of a fairly clean way to attack this problem, which
is to represent the cost of a plan in two parts instead of only one.
Instead of just "cost", have "startup cost" and "cost per tuple".
(Actually, it'd probably be easier to work with "startup cost" and
"total cost if all tuples are retrieved", but that's a trivial
representational detail; the point is that our cost model will now be
of the form a*N+b when N tuples are retrieved.) It'd be pretty easy
to produce plausible numbers for all the plan types we use. Then,
the plan comparators would keep any plan that wins on either startup
or total cost, rather than only considering total cost. Finally
at the top level of planning, when there is a LIMIT the preferred
plan would be selected by comparing a*LIMIT+b rather than total cost.

I think I can get this done before beta, but before I go into hack-
attack mode I wanted to run it up the flagpole and see if anyone
has any complaints or better ideas.

regards, tom lane

************

From bouncefilter Thu Feb 10 18:18:52 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA09443
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 18:18:43 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA18466; Fri, 11 Feb 2000 10:18:05 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0ajovE;
Fri Feb 11 10:17:37 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA12389; Fri, 11 Feb 2000 10:17:36 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd00vJn6; Fri Feb 11 10:17:06 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA14198;
Fri, 11 Feb 2000 10:17:01 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA05448; Fri, 11 Feb 2000 10:16:23 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A34690.27BCA255@nimrod.itg.telecom.com.au>
Date: Fri, 11 Feb 2000 10:15:28 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
CC: "'Hannu Krosing'" <hannu@tm.ee>, "'Tom Lane'" <tgl@sss.pgh.pa.us>,
"'chris@bitmead.com'" <chris@bitmead.com>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: AW: [HACKERS] Another nasty cache problem
References:
<219F68D65015D011A8E000006F8590C603FDC247@sdexcsrv1.f000.d0188.sd.spardat.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Zeugswetter Andreas SB wrote:

Is'nt the "blank portal" the name of the cursor you get when you just
do a select without creating a cursor ?

Yes, is that still so ?

I don't really see any advantage, that psql does not do a fetch loop
with a portal.

It only increases traffic, as explicit fetch commands need to be sent
to backend. If one does not declare a cursor, an implicit
fetch all from
blank is performed.

I don't really see how a fetch every x rows (e.g.1000) would add significant
overhead.
The first fetch could still be done implicit, it would only fetch 1000
instead of fetch all.
Thus there would only be overhead for large result sets, where the
wasted memory is of real concern.

Apart from anything else, it would make psql inconvenient for debugging
the regular, non-cursor mechanism if psql went off and always used a
cursor regardless.

And since we know that cursors are not the best way to fix this problem
in
psql (streaming is the answer), then it doesn't seem a good plan.

From bouncefilter Thu Feb 10 18:26:52 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA13239
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 18:26:40 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id PAA01905;
Thu, 10 Feb 2000 15:25:59 -0800 (PST)
Message-Id: <3.0.1.32.20000210152348.010c8450@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 10 Feb 2000 15:23:48 -0800
To: chris@bitmead.com, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
References: <15706.950201295@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:01 AM 2/11/00 +1100, Chris Bitmead wrote:

A couple of things occur to me. One is that it sounds like this
proposal could mean that successive SELECTS with LIMIT could
execute completely different plans and therefore return inconsistent
results. For example, let's say I have 26 customers a through z.
My first call to SELECT name from customer limit 3 might return...
a
b
c
and then my next SELECT name from customer limit 3, 3 might return
a
b
c
again, when I might expect d e f. Of course in this case I could SORT,
but unless name is a unique field that won't work.

Well...SQL *is* a set language, and the tuples returned aren't guaranteed
to be returned in the same order from query to query. The order in
which they're returned is entirely undefined.

You MUST establish an order on the target tuples if you expect to
see them returned in a consistent order. The RDMS only has to
deliver the tuples that satisfy the query, nothing more.

You aren't guaranteed what you want even with the optimizer the
way it is:

donb=# select * from foo;
i
---
1
2
(2 rows)

donb=# delete from foo where i=1;
DELETE 1
donb=# insert into foo values(1);
INSERT 147724 1
donb=# select * from foo;
i
---
2
1
(2 rows)

This isn't the only way to impact the ordering of delivered
rows, either. VACUUM ANALYZE could do it, for instance...

The other thing is, I would like at some stage to change limit so
that it is attached to a SELECT rather than an entire query so
you could...
SELECT * from x where y in (SELECT y from z LIMIT 10) LIMIT 20;
and I'm not sure how this would interact with that.

Since ORDER BY applies to the target row, the rows returned from
the subselect would be in indeterminate order anyway...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Thu Feb 10 19:01:52 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA30367
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 19:01:13 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA00244 for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 11:00:41 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdt.jYk_;
Fri Feb 11 11:00:17 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA13812 for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 11:00:16 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0DZ2GE; Fri Feb 11 10:58:46 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA24141
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 10:58:45 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA06362 for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 10:58:08 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A35058.A8A885BF@nimrod.itg.telecom.com.au>
Date: Fri, 11 Feb 2000 10:57:12 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <15706.950201295@sss.pgh.pa.us>
<3.0.1.32.20000210152348.010c8450@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

Well...SQL *is* a set language, and the tuples returned aren't guaranteed
to be returned in the same order from query to query. The order in
which they're returned is entirely undefined.

Which would make LIMIT a pretty useless function unless you include
every field in your ORDER BY, otherwise LIMIT returns not defined
results.
To keep strict SET based semantics LIMIT should disallowed unless you
ORDER BY a UNIQUE field, or you ORDER BY with every single field in the
clause.

You MUST establish an order on the target tuples if you expect to
see them returned in a consistent order. The RDMS only has to
deliver the tuples that satisfy the query, nothing more.

You aren't guaranteed what you want even with the optimizer the
way it is:

I know, I know, but the current behaviour is "close enough" for
a lot of applications.

The other thing is, I would like at some stage to change limit so
that it is attached to a SELECT rather than an entire query so
you could...
SELECT * from x where y in (SELECT y from z LIMIT 10) LIMIT 20;
and I'm not sure how this would interact with that.

Since ORDER BY applies to the target row, the rows returned from
the subselect would be in indeterminate order anyway...

Oh. Well then I'd like ORDER BY in the subselect too :-).

From bouncefilter Thu Feb 10 22:16:54 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA01796
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 22:16:31 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id MAA00106; Fri, 11 Feb 2000 12:14:38 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Solution for LIMIT cost estimation
Date: Fri, 11 Feb 2000 12:20:40 +0900
Message-ID: <000d01bf743e$f9436080$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <15706.950201295@sss.pgh.pa.us>
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane

I have thought of a fairly clean way to attack this problem, which
is to represent the cost of a plan in two parts instead of only one.
Instead of just "cost", have "startup cost" and "cost per tuple".
(Actually, it'd probably be easier to work with "startup cost" and
"total cost if all tuples are retrieved", but that's a trivial
representational detail; the point is that our cost model will now be
of the form a*N+b when N tuples are retrieved.) It'd be pretty easy
to produce plausible numbers for all the plan types we use. Then,
the plan comparators would keep any plan that wins on either startup
or total cost, rather than only considering total cost. Finally
at the top level of planning, when there is a LIMIT the preferred
plan would be selected by comparing a*LIMIT+b rather than total cost.

I have no objection but have a question.

It seems current cost estimation couldn't be converted into a*N+b
form exactly. For example,the cost of seq scan is
count of pages + count of tuples * cpu_weight + ..
count of pages couldn't be converted into a*N form.
The cost of index scan is more complicated.
I thought of no clear way to treat it when I thought about
this item once.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Thu Feb 10 22:52:55 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA07933
for <pgsql-hackers@postgreSQL.org>;
Thu, 10 Feb 2000 22:52:32 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA18101;
Thu, 10 Feb 2000 22:52:12 -0500 (EST)
To: chris@bitmead.com
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
References: <15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Fri, 11 Feb 2000 10:01:46 +1100"
Date: Thu, 10 Feb 2000 22:52:12 -0500
Message-ID: <18098.950241132@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

... it sounds like this
proposal could mean that successive SELECTS with LIMIT could
execute completely different plans and therefore return inconsistent
results.
In short, I think the fact that limit doesn't alter the plan may
be more of a feature than a bug.

A good point (one I'm embarrassed not to have thought about!) but
I don't think it's a reason not to push forward in this direction.
We have had *way* too many complaints about Postgres not being able
to optimize LIMITed queries, so I'm not willing to ignore the issue;
something's got to be done about it.

As Don B. points out nearby, there's no guarantee anyway that
repeatedly issuing the same query with different LIMIT parameters
will get you consistent results. The only upright and morally
correct approach is to use DECLARE CURSOR followed by FETCH commands
(all within a transaction of course) in order to get results that
are really all part of a single query. Now DECLARE CURSOR is also
presently optimized on the basis of fetching the entire result set,
so that is still a problem --- I neglected to mention before that
I was intending to tweak the optimizer to optimize that case like a
moderate-sized LIMIT.

But having said that, I hear what you're saying and I think it's
worth thinking about. Here are four possible alternative responses:

1. Optimize the query as I sketched previously, but using the "count"
part of the LIMIT spec while deliberately ignoring the "offset".
Then you get consistent results for fetching different chunks of the
query result as long as you use the same count each time. (And as long
as no one else is changing the DB meanwhile, but we'll take that as
read for each of these choices.)

2. Ignore both the count and offset, and optimize any query containing
a LIMIT clause on the basis of some fixed assumption about what fraction
of the tuples will be fetched (I'm thinking something like 1% to 10%).
This allows different fetch sizes to be used without destroying
consistency, but it falls down on the goal of correctly optimizing
"LIMIT 1" hacks.

3. Use the count+offset for all it's worth, and document that you
can't expect to get consistent results from asking for different
LIMITed chunks of the "same" query unless you use ORDER BY to
ensure consistent ordering of the tuples.

4. Fascist variant of #3: make LIMIT without ORDER BY be an error.

SQL92 does not define LIMIT at all, so it's not much help in
deciding what to do. Is there anything in SQL3? What do other
DBMSes do about this issue? Comments, other variants, better ideas
anyone?

The other thing is, I would like at some stage to change limit so
that it is attached to a SELECT rather than an entire query so
you could...
SELECT * from x where y in (SELECT y from z LIMIT 10) LIMIT 20;
and I'm not sure how this would interact with that.

Since ORDER BY is only allowed at the top level by SQL92, there
would be no way for the user to ensure predictable results from
such a query. I think that'd be a dangerous path to go down.
However, if you had an answer that ensured consistent results from
queries with sub-LIMITs, I don't see that there'd be any problem
with allowing the optimizer to optimize 'em.

regards, tom lane

From bouncefilter Fri Feb 11 00:29:56 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA25294
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 00:29:31 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA18285;
Thu, 10 Feb 2000 23:31:36 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <000d01bf743e$f9436080$2801007e@tpf.co.jp>
References: <000d01bf743e$f9436080$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Fri, 11 Feb 2000 12:20:40 +0900"
Date: Thu, 10 Feb 2000 23:31:36 -0500
Message-ID: <18282.950243496@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

It seems current cost estimation couldn't be converted into a*N+b
form exactly. For example,the cost of seq scan is
count of pages + count of tuples * cpu_weight + ..
count of pages couldn't be converted into a*N form.
The cost of index scan is more complicated.

It would not be an exact conversion, because the cost of a query is
clearly *not* a perfectly linear function of the number of tuples
retrieved before stopping. Another example, besides the ones you
mention, is that a nested-loop join will suffer a "hiccup" in
output rate each time it restarts the inner scan, if the inner scan
is of a kind that has nontrivial startup cost. But I believe that
this effect is not very significant compared to all the other
approximations the optimizer already has to make.

Basically, my proposal is that the plan cost estimation routines
provide a "startup cost" (cost expended to retrieve the first
tuple) in addition to the "total cost" they already estimate.
Then, upper-level planning routines that want to estimate the cost
of fetching just part of the query result will estimate that cost
by linear interpolation between the startup cost and the total
cost. Sure, it's just a rough approximation, but it'll be a long
time before that's the worst error made by the planner ;-)

regards, tom lane

From bouncefilter Fri Feb 11 00:09:55 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA20862
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 00:03:24 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA23473; Fri, 11 Feb 2000 16:02:19 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0uvIso;
Fri Feb 11 16:02:01 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA15442; Fri, 11 Feb 2000 16:02:00 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0uM4Qp; Fri Feb 11 15:58:55 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA10713;
Fri, 11 Feb 2000 15:58:54 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
PAA12871; Fri, 11 Feb 2000 15:58:17 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A396B0.BF0509A5@nimrod.itg.telecom.com.au>
Date: Fri, 11 Feb 2000 15:57:20 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Chris <chris@bitmead.com>, Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] libpq
References: <38A2AE00.9EB1BE9B@bitmead.com> <15283.950196239@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Chris <chris@bitmead.com> writes:

What I have in mind is that a new API PQexecStream() doesn't retrieve
the results. The tuples are then read back one by one with
PQnextObject().

OK, but how does this interact with asynchrononous retrieval? It
should be possible to run it in a nonblocking (select-waiting) mode.

I didn't know that was a requirement. Well when doing this sort of
stuff you never know what other sources of data they may want
to wait for, so the only way is to have PQfileDescriptor or something,
but I don't think that affects these decisions does it? If they want
async, they are given the fd and select. When ready they call
nexttuple.

BTW, an earlier proposal for this same sort of thing didn't see it
as an entirely new operating mode, but just a "limit" option added
to a variant of PQexec: the limit says "return no more than N tuples
per PQresult".

As in changing the interface to PQexec?

I can't see the benefit of specifically asking for N tuples. Presumably
behind the scenes it will read from the socket in a respectably
large chunk (8k for example). Beyond that I can't see any more reason
for customisation.

I looked at that before, and while COPY is certainly ugly as sin, it's
not clear that it's worth creating cross-version compatibility problems
to fix it. I'm inclined to leave it alone until such time as we
undertake a really massive protocol change (moving to CORBA, say).

I'll look at that situation further later. Is there a policy on
protocol compatibility? If so, one way or both ways?

The other comments you made, I have to think about further.

From bouncefilter Fri Feb 11 00:59:56 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA30165
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 00:59:25 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id QAA14085;
Fri, 11 Feb 2000 16:37:21 +1100
Message-Id: <3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 11 Feb 2000 16:38:10 +1100
To: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <18098.950241132@sss.pgh.pa.us>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 22:52 10/02/00 -0500, Tom Lane wrote:

But having said that, I hear what you're saying and I think it's
worth thinking about. Here are four possible alternative responses:

Another option is to do what Dec/Rdb does, and allow either optimizer hints
in a saved plan, or via modified SQL (less portable):

select * from foo limit 1 row optimize for fast first;

I also have a question: does the optimizer know about relevant indexes when
it is trying to return an ordered result set? If not, then 'fast first'
retrieval may be substantially improved by including such knowledge.

ie.

select * from foo order by f1,f2 limit 1 row;

should be trivial if there is an index on (f1,f2).

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

From bouncefilter Fri Feb 11 01:03:56 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA31461
for <hackers@postgresql.org>; Fri, 11 Feb 2000 01:03:03 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id GAA23271
for <hackers@postgresql.org>; Fri, 11 Feb 2000 06:10:35 GMT
Sender: lockhart@hub.org
Message-ID: <38A3A7DB.6A684EF@alumni.caltech.edu>
Date: Fri, 11 Feb 2000 06:10:35 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Almost there on column aliases
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've got most of the regression tests running, but one of the rules
tests has uncovered a problem in my code, at least for a query
involving a merge join.

Could someone run a "-d 99" query using the following from the
regression test (rules.sql):

select rtest_t2.a, rtest_t3.b
from rtest_t2, rtest_t3
where rtest_t2.a = rtest_t3.a;

and send me the query, the rewritten query, and the plan emitted by
the backend (it should be a MERGEJOIN plan)? It might speed up my
rummaging around for the reason for the failure :(

Another possibility is that I submit/commit my patches (there are
quite a few files touched and I *really* want to get them off of my
system and into the tree soon) but I was a bit hesitant to commit
something with a known problem of this nature.

TIA

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Fri Feb 11 01:13:56 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA33128
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 01:13:55 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id BAA04816
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 01:13:50 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA18590;
Fri, 11 Feb 2000 01:10:54 -0500 (EST)
To: chris@bitmead.com
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] libpq
In-reply-to: <38A396B0.BF0509A5@nimrod.itg.telecom.com.au>
References: <38A2AE00.9EB1BE9B@bitmead.com> <15283.950196239@sss.pgh.pa.us>
<38A396B0.BF0509A5@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Fri, 11 Feb 2000 15:57:20 +1100"
Date: Fri, 11 Feb 2000 01:10:54 -0500
Message-ID: <18587.950249454@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Tom Lane wrote:

OK, but how does this interact with asynchrononous retrieval? It
should be possible to run it in a nonblocking (select-waiting) mode.

I didn't know that was a requirement.

Well, there may not be anyone holding a gun to your head about it...
but there have been a number of people sweating to make the existing
facilities of libpq usable in a non-blocking fashion. Seems to me
that that sort of app would be particularly likely to want to make
use of a streaming API --- so if you don't think about it, there is
going to be someone else coming along to clean up after you pretty
soon. Better to get it right the first time.

to wait for, so the only way is to have PQfileDescriptor or something,
but I don't think that affects these decisions does it? If they want
async, they are given the fd and select. When ready they call
nexttuple.

Not really. The app can and does wait for select() to show read ready
on libpq's input socket --- but that only indicates that there is a TCP
packet's worth of data available, *not* that a whole tuple is available.
libpq must provide the ability to consume data from the kernel (to
clear the select-read-ready condition) and then either hand back a
completed tuple (or several) or say "sorry, no complete data yet".
I'd suggest understanding the existing facilities more carefully before
you set out to improve on them.

to a variant of PQexec: the limit says "return no more than N tuples
per PQresult".

As in changing the interface to PQexec?

I did say "variant", no? We don't get to break existing callers of
PQexec.

I can't see the benefit of specifically asking for N tuples. Presumably
behind the scenes it will read from the socket in a respectably
large chunk (8k for example). Beyond that I can't see any more reason
for customisation.

Well, that's true from one point of view, but I think it's just libpq's
point of view. The application programmer is fairly likely to have
specific knowledge of the size of tuple he's fetching, and maybe even
to have a global perspective that lets him decide he doesn't really
*want* to deal with retrieved tuples on a packet-by-packet basis.
Maybe waiting till he's got 100K of data is just right for his app.

But I can also believe that the app programmer doesn't want to commit to
a particular tuple size any more than libpq does. Do you have a better
proposal for an API that doesn't commit any decisions about how many
tuples to fetch at once?

not clear that it's worth creating cross-version compatibility problems
to fix it. I'm inclined to leave it alone until such time as we
undertake a really massive protocol change (moving to CORBA, say).

I'll look at that situation further later. Is there a policy on
protocol compatibility? If so, one way or both ways?

The general policy so far has been that backends should be able to
talk to any vintage of frontend, but frontend clients need only be
able to talk to backends of same or later version. (The idea is to
be able to upgrade your server without breaking existing clients,
and then you can go around and update client apps at your
convenience.)

The last time we actually changed the protocol was in 6.4 (at my
instigation BTW) --- and while we didn't get a tidal wave of
"hey my new psql won't talk to an old server" complaints, we got
a pretty fair number of 'em. So I'm very hesitant to break either
forwards or backwards compatibility in new releases. I certainly
don't want to do it just for code beautification; we need a reason
that is compelling to the end users who will be inconvenienced.

regards, tom lane

From bouncefilter Fri Feb 11 01:18:57 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA34523
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 01:18:28 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA21804 for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 17:17:53 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdi_VT5_;
Fri Feb 11 17:17:27 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA14035 for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 17:17:25 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0wSqwV; Fri Feb 11 17:17:02 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA11239
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 17:16:56 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
RAA14591 for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 17:16:19 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
Date: Fri, 11 Feb 2000 17:15:23 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

For my own curiousity, how does the presence of limit affect a plan
anyway?

From bouncefilter Fri Feb 11 01:18:56 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA34492
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 01:18:12 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA18643;
Fri, 11 Feb 2000 01:17:40 -0500 (EST)
To: Philip Warner <pjw@rhyme.com.au>
cc: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
Comments: In-reply-to Philip Warner <pjw@rhyme.com.au>
message dated "Fri, 11 Feb 2000 16:38:10 +1100"
Date: Fri, 11 Feb 2000 01:17:40 -0500
Message-ID: <18640.950249860@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Philip Warner <pjw@rhyme.com.au> writes:

Another option is to do what Dec/Rdb does, and allow either optimizer hints
in a saved plan, or via modified SQL (less portable):

select * from foo limit 1 row optimize for fast first;

The former is not going to happen in time for 7.0, and the latter is
not entirely palatable --- we are trying to become more SQL-spec-
compliant, not less...

I also have a question: does the optimizer know about relevant indexes when
it is trying to return an ordered result set? If not, then 'fast first'
retrieval may be substantially improved by including such knowledge.

It does know about indexes. The problem is that it is making planning
choices on the basis of cost to retrieve the entire ordered result set,
which leads to pessimal planning when you don't really want any such
thing.

regards, tom lane

From bouncefilter Fri Feb 11 04:12:00 2000
Received: from mailroute2.pacifier.com (IDENT:root@mailroute2.pacifier.com
[216.65.128.6]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA04248
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 04:11:37 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from eclipse.pacifier.com (mailroute-internal.pacifier.com
[216.65.128.7])
by mailroute2.pacifier.com (8.9.3/8.9.1) with ESMTP id AAA11695
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 00:12:28 -0800 (PST)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id WAA01645;
Thu, 10 Feb 2000 22:39:05 -0800 (PST)
Message-Id: <3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 10 Feb 2000 22:35:24 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <18098.950241132@sss.pgh.pa.us>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:52 PM 2/10/00 -0500, Tom Lane wrote:

4. Fascist variant of #3: make LIMIT without ORDER BY be an error.

SQL92 does not define LIMIT at all, so it's not much help in
deciding what to do. Is there anything in SQL3? What do other
DBMSes do about this issue? Comments, other variants, better ideas
anyone?

Well ... for my money I never expected LIMIT to be meaningful in
the sense of being deterministic without an ORDER BY clause.

But ... that doesn't mean that some folks might not want to use
it differently. What if LIMIT 2 were more efficient that COUNT(*)
in order to determine if more than one row satisfies a condition?

I don't know if that's even a remote possibility given the current
implementation, but it is an example where a non-deterministic
tuple ordering might not matter.

But I wouldn't feel badly at all if LIMIT limited to queries
with ORDER BY. I think this could be done gramatically, i.e.

[query] ORDER BY

is the SQL paradign, and you'd just hang LIMIT on ORDER BY (or
more properly at the same grammar level allow them in any order).

[ORDER BY | LIMIT clause]*

in one form of pseudo-grammar, with appropriate semantic checking
so you can't say ORDER BY .. ORDER BY ...

The other thing is, I would like at some stage to change limit so
that it is attached to a SELECT rather than an entire query so
you could...
SELECT * from x where y in (SELECT y from z LIMIT 10) LIMIT 20;
and I'm not sure how this would interact with that.

Since ORDER BY is only allowed at the top level by SQL92, there
would be no way for the user to ensure predictable results from
such a query. I think that'd be a dangerous path to go down.

Yep.

However, if you had an answer that ensured consistent results from
queries with sub-LIMITs, I don't see that there'd be any problem
with allowing the optimizer to optimize 'em.

No, it's not an optimizer problem.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Fri Feb 11 01:44:57 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA39125
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 01:44:50 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA03580; Fri, 11 Feb 2000 17:38:32 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdjLlfC_;
Fri Feb 11 17:38:11 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA01785; Fri, 11 Feb 2000 17:38:10 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdEAK9l_; Fri Feb 11 17:37:54 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA23515;
Fri, 11 Feb 2000 17:37:53 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
RAA15108; Fri, 11 Feb 2000 17:37:16 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A3ADE3.AAE1FC7D@nimrod.itg.telecom.com.au>
Date: Fri, 11 Feb 2000 17:36:19 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: chris@bitmead.com, Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] libpq
References: <38A2AE00.9EB1BE9B@bitmead.com> <15283.950196239@sss.pgh.pa.us>
<38A396B0.BF0509A5@nimrod.itg.telecom.com.au>
<18587.950249454@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Well, that's true from one point of view, but I think it's just libpq's
point of view. The application programmer is fairly likely to have
specific knowledge of the size of tuple he's fetching, and maybe even
to have a global perspective that lets him decide he doesn't really
*want* to deal with retrieved tuples on a packet-by-packet basis.
Maybe waiting till he's got 100K of data is just right for his app.

But I can also believe that the app programmer doesn't want to commit to
a particular tuple size any more than libpq does. Do you have a better
proposal for an API that doesn't commit any decisions about how many
tuples to fetch at once?

If you think applications may like to keep buffered 100k of data, isn't
that an argument for the PGobject interface instead of the PGresult
interface?

I'm trying to think of a situation where you want to buffer data. Let's
say psql has something like "more" inbuilt and it needs to buffer
a screenful, and go forward line by line. Now you want to keep the last
40 tuples buffered. First up you want 40 tuples, then you want one
at a time every time you press Enter.

This seems too much responsibility to press onto libpq, but if the user
has control over destruction of PQobjects they can buffer what they
want, how they want, when they want.

From bouncefilter Fri Feb 11 01:47:57 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id BAA39773
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 01:47:12 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 16719 invoked from network); 11 Feb 2000 06:47:03 -0000
Received: from h-62.96.161.99.host.de.colt.net (HELO feivel.fam-meskes.de)
(62.96.161.99)
by pille.addcom.de with SMTP; 11 Feb 2000 06:47:03 -0000
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id ECE8D2BBBC; Fri, 11 Feb 2000 07:39:43 +0100 (CET)
Date: Fri, 11 Feb 2000 07:39:43 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and libpq fixes
Message-ID: <20000211073943.A1289@fam-meskes.de>
Mail-Followup-To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
References: <200002081602.LAA27899@candle.pha.pa.us>
<2131.950027376@sss.pgh.pa.us>
<200002101602.LAA18256@smtp3.andrew.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <200002101602.LAA18256@smtp3.andrew.cmu.edu>;
from geek+@cmu.edu on Thu, Feb 10, 2000 at 11:02:32AM -0500
Sender: michael@fam-meskes.de

On Thu, Feb 10, 2000 at 11:02:32AM -0500, Brian E Gallew wrote:

Urhm, wouldn't a better idea be to have something like Ingres' "ON
ERROR" and "ON WARNING" settings? In Ingres esqlc, you can create

You can do that with ecpg as well. The syntax is exec sql whenever ....
I doubt though that this was about a precompiler but psql. But then esqlc is
a precompiler too.

Michael

--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Fri Feb 11 04:11:58 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA04244
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 04:11:37 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id EAA08193
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 04:11:13 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA18710;
Fri, 11 Feb 2000 01:41:08 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
In-reply-to: <38A3A7DB.6A684EF@alumni.caltech.edu>
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Fri, 11 Feb 2000 06:10:35 +0000"
Date: Fri, 11 Feb 2000 01:41:07 -0500
Message-ID: <18707.950251267@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Could someone run a "-d 99" query using the following from the
regression test (rules.sql):
select rtest_t2.a, rtest_t3.b
from rtest_t2, rtest_t3
where rtest_t2.a = rtest_t3.a;
and send me the query, the rewritten query, and the plan emitted by
the backend (it should be a MERGEJOIN plan)? It might speed up my
rummaging around for the reason for the failure :(

This doesn't look very detailed, is it really what you wanted?

StartTransactionCommand
query: explain
select rtest_t2.a, rtest_t3.b
from rtest_t2, rtest_t3
where rtest_t2.a = rtest_t3.a
parser outputs:

{ QUERY :command 5 :utility ? :resultRelation 0 :into <> :isPortal false :isBinary false :isTemp false :unionall false :distinctClause <> :sortClause <> :rtable <> :targetlist <> :qual <> :groupClause <> :havingQual <> :hasAggs false :hasSubLinks false :unionClause <> :intersectClause <> :limitOffset <> :limitCount <> :rowMark <>}

after rewriting:
{ QUERY
:command 5
:utility ?
:resultRelation 0
:into <>
:isPortal false
:isBinary false
:isTemp false
:unionall false
:distinctClause <>
:sortClause <>
:rtable <>
:targetlist <>
:qual <>
:groupClause <>
:havingQual <>
:hasAggs false
:hasSubLinks false
:unionClause <>
:intersectClause <>
:limitOffset <>
:limitCount <>
:rowMark <>
}

ProcessUtility: explain
select rtest_t2.a, rtest_t3.b
from rtest_t2, rtest_t3
where rtest_t2.a = rtest_t3.a
NOTICE: QUERY PLAN:

Merge Join (cost=164.66 rows=10000 width=12)
-> Sort (cost=69.83 rows=1000 width=8)
-> Seq Scan on rtest_t3 (cost=20.00 rows=1000 width=8)
-> Sort (cost=69.83 rows=1000 width=4)
-> Seq Scan on rtest_t2 (cost=20.00 rows=1000 width=4)

CommitTransactionCommand

Another possibility is that I submit/commit my patches (there are
quite a few files touched and I *really* want to get them off of my
system and into the tree soon) but I was a bit hesitant to commit
something with a known problem of this nature.

Any changes in backend/optimizer/ ? I've got a bunch of uncommitted
changes there myself.

regards, tom lane

From bouncefilter Fri Feb 11 01:47:57 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id BAA39789
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 01:47:18 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 16721 invoked from network); 11 Feb 2000 06:47:03 -0000
Received: from h-62.96.161.99.host.de.colt.net (HELO feivel.fam-meskes.de)
(62.96.161.99)
by pille.addcom.de with SMTP; 11 Feb 2000 06:47:03 -0000
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 461022BC5E; Fri, 11 Feb 2000 07:41:10 +0100 (CET)
Date: Fri, 11 Feb 2000 07:41:10 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and libpq fixes
Message-ID: <20000211074110.B1289@fam-meskes.de>
Mail-Followup-To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
References: <200002101602.LAA18256@smtp3.andrew.cmu.edu>
<Pine.GSO.4.02A.10002101708310.19049-100000@Zebra.DoCS.UU.SE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <Pine.GSO.4.02A.10002101708310.19049-100000@Zebra.DoCS.UU.SE>;
from e99re41@DoCS.UU.SE on Thu, Feb 10, 2000 at 05:12:54PM +0100
Sender: michael@fam-meskes.de

On Thu, Feb 10, 2000 at 05:12:54PM +0100, Peter Eisentraut wrote:

That's very nice and all, but psql doesn't work that way. I'm not sure how
other dbs organize their front-end internally, but that sort of scheme
would really take psql places we might not want it to go, and for which it
hasn't been designed -- namely, to be a programming language.

I wonder why we compare apples and oranges here. Of course esqlc was
designed to be parse a programming language while psql is a query tool.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Sun Feb 13 07:04:28 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA41601
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 07:03:45 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
SAA13688; Fri, 11 Feb 2000 18:00:33 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdAzOzA_;
Fri Feb 11 18:00:14 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
SAA17186; Fri, 11 Feb 2000 18:00:11 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdoq6uf_; Fri Feb 11 17:59:34 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA03707;
Fri, 11 Feb 2000 17:59:33 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
RAA15619; Fri, 11 Feb 2000 17:58:56 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
Date: Fri, 11 Feb 2000 17:57:59 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

But ... that doesn't mean that some folks might not want to use
it differently. What if LIMIT 2 were more efficient that COUNT(*)
in order to determine if more than one row satisfies a condition?

select count(*) > 1 from a;

And if that's not efficient, why not optimise _that_, since it
expresses directly what you want?

But I wouldn't feel badly at all if LIMIT limited to queries
with ORDER BY. I think this could be done gramatically, i.e.

[query] ORDER BY

If you are going to limit it thus, it only makes sense if you
either order by a unique key or order by every single column.
Otherwise, why limit it at all? And that can't be determined
gramatically.

From bouncefilter Fri Feb 11 07:14:56 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA50920
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 07:14:22 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id HAA21142;
Fri, 11 Feb 2000 07:11:23 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <38A3B61D.73F45891@mascari.com>
Date: Fri, 11 Feb 2000 02:11:25 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
CC: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>,
Bryan White <bryan@arcamax.com>
Subject: Re: [HACKERS] Re: [INTERFACES] The persistance of C functions
References: <Pine.LNX.3.96.1000211112520.23828B-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Karel Zak - Zakkr wrote:

Not _totally_ safe: if you've got anything that refers to that function,
like a user defined type definition, drop/(re)create will change the
function's oid in the pg_proc table, causing errors when the old
function is looked up. Hmm, an ALTER FUNCTION command might be nice...

... and/or check dependencies on the function's oid if the function is DROP,
(via FOREIGN KEYs ?). IMHO it is good item to TODO if really nothing check
it. (...resending to hackers)

Karel

Yes. I think it would be an interesting discussion to see whether or not it would
be a good idea to integrate referential integrity with respect to the system
cataloge. The result *could* be backend code which is far easier to maintain, and
(with updateable oids), support for ALTER/DROP code which yields sane results. For
example, with the little COMMENT code, I had to find the backend code responsible
for dropping each of the associated object types - relations, aggregates, types,
functions, etc. in order to also drop the associated COMMENT. *AND *I also had to
find those areas where an object might be implicitly dropped by dropping another
object by calling a different routine -- for example, DROP TRIGGER calls a
different routine (DropTrigger) than what is called by the DROP TABLE code to drop
all triggers associated with it (RelationRemoveTriggers). With RI, a cascading
delete from pg_class could automatically drop the associated indexes, triggers,
comments, etc. And perhaps another trigger on pg_class should be used to remove the
actual relation file itself. Then one would only need to determine whether the DROP
should be allowed (if, for instance, it is a base class of an inheritence
hierarchy) or it should be rejected by the RI code. Likewise, the ALTER code could
perform a cascading update of oid (if necessary), to aide pg_dump when dumping
objects in oid order (TODO) to reduce the possibility of breaking a dependency...

Just some thoughts,

Mike Mascari

From bouncefilter Fri Feb 11 09:39:58 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA85332
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 09:39:41 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA23698;
Fri, 11 Feb 2000 07:16:21 GMT
Sender: lockhart@hub.org
Message-ID: <38A3B745.E720A4AC@alumni.caltech.edu>
Date: Fri, 11 Feb 2000 07:16:21 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Could someone run a "-d 99" query using the following from the
regression test (rules.sql):

This doesn't look very detailed, is it really what you wanted?

Hmm. I expected to get a full plan (labeled "plan:"). Did you do the
query or just an "explain"?

I'm compiling this way, though I don't think that it matters for this:

$ gcc -I../../include -I../../backend -O2 -m486 -O2 -g -O0
-DUSE_ASSERT_CHECKING -DENABLE_OUTER_JOINS -DEXEC_MERGEJOINDEBUG -Wall
-Wmissing-prototypes -I.. -c copyfuncs.c -o copyfuncs.o

Any changes in backend/optimizer/ ? I've got a bunch of uncommitted
changes there myself.

Not too much. Though I've got a null pointer problem in executor for
mergejoins and I'm not certain where it is coming from. Here are the
files which have changed in the optimizer/ tree:

[postgres@golem optimizer]$ cvs -q update .
M prep/prepunion.c
M util/clauses.c

The changes are minor; I'm pretty sure I can remerge if you want to
commit your stuff (at least if your stuff is isolated to the
backend/optimizer/ part of the tree).

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Fri Feb 11 04:12:02 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA04207
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 04:11:24 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id EAA08177
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 04:11:10 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA18806;
Fri, 11 Feb 2000 02:20:38 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
In-reply-to: <38A3B745.E720A4AC@alumni.caltech.edu>
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Fri, 11 Feb 2000 07:16:21 +0000"
Date: Fri, 11 Feb 2000 02:20:38 -0500
Message-ID: <18803.950253638@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

This doesn't look very detailed, is it really what you wanted?

Hmm. I expected to get a full plan (labeled "plan:"). Did you do the
query or just an "explain"?

I'm sorry, just did the "explain". Is this any better?

StartTransactionCommand
query: select rtest_t2.a, rtest_t3.b
from rtest_t2, rtest_t3
where rtest_t2.a = rtest_t3.a
parser outputs:

{ QUERY :command 1 :utility <> :resultRelation 0 :into <> :isPortal false :isBinary false :isTemp false :unionall false :distinctClause <> :sortClause <> :rtable ({ RTE :relname rtest_t2 :refname rtest_t2 :relid 404330 :inh false :inFromCl true :inJoinSet true :skipAcl false} { RTE :relname rtest_t3 :refname rtest_t3 :relid 404340 :inh false :inFromCl true :inJoinSet true :skipAcl false}) :targetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1 :resname a :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 1}} { TARGETENTRY :resdom { RESDOM :resno 2 :restype 23 :restypmod -1 :resname b :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 2 :varattno 2 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 2}}) :qual { EXPR :typeOid 16 :opType op :oper { OPER :opno 96 :opid 0 :opresulttype 16 } :args ({ VAR :varno 1 :v!
!
arattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 1} { VAR :varno 2 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 1})} :groupClause <> :havingQual <> :hasAggs false :hasSubLinks false :unionClause <> :intersectClause <> :limitOffset <> :limitCount <> :rowMark <>}

after rewriting:
{ QUERY
:command 1
:utility <>
:resultRelation 0
:into <>
:isPortal false
:isBinary false
:isTemp false
:unionall false
:distinctClause <>
:sortClause <>
:rtable (
{ RTE
:relname rtest_t2
:refname rtest_t2
:relid 404330
:inh false
:inFromCl true
:inJoinSet true
:skipAcl false
}

{ RTE
:relname rtest_t3
:refname rtest_t3
:relid 404340
:inh false
:inFromCl true
:inJoinSet true
:skipAcl false
}
)

:targetlist (
{ TARGETENTRY
:resdom
{ RESDOM
:resno 1
:restype 23
:restypmod -1
:resname a
:reskey 0
:reskeyop 0
:ressortgroupref 0
:resjunk false
}

:expr
{ VAR
:varno 1
:varattno 1
:vartype 23
:vartypmod -1
:varlevelsup 0
:varnoold 1
:varoattno 1
}
}

{ TARGETENTRY
:resdom
{ RESDOM
:resno 2
:restype 23
:restypmod -1
:resname b
:reskey 0
:reskeyop 0
:ressortgroupref 0
:resjunk false
}

:expr
{ VAR
:varno 2
:varattno 2
:vartype 23
:vartypmod -1
:varlevelsup 0
:varnoold 2
:varoattno 2
}
}
)

:qual
{ EXPR
:typeOid 16
:opType op
:oper
{ OPER
:opno 96
:opid 0
:opresulttype 16
}

:args (
{ VAR
:varno 1
:varattno 1
:vartype 23
:vartypmod -1
:varlevelsup 0
:varnoold 1
:varoattno 1
}

{ VAR
:varno 2
:varattno 1
:vartype 23
:vartypmod -1
:varlevelsup 0
:varnoold 2
:varoattno 1
}
)
}

:groupClause <>
:havingQual <>
:hasAggs false
:hasSubLinks false
:unionClause <>
:intersectClause <>
:limitOffset <>
:limitCount <>
:rowMark <>
}

plan:

{ MERGEJOIN :cost 164.658 :rows 10000 :width 12 :state <> :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1 :resname a :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 65000 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 1}} { TARGETENTRY :resdom { RESDOM :resno 2 :restype 23 :restypmod -1 :resname b :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 65001 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 2}}) :qpqual <> :lefttree { SORT :cost 69.8289 :rows 1000 :width 8 :state <> :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 2 :varattno 2 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 2}} { TARGETENTRY :resdom { RESDOM :resno 2 :restype 23 :restypmod -1 :resname <> :reskey 1 :reskeyop 66 :ressortg!
!
roupref 0 :resjunk false } :expr { VAR :varno 2 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 1}}) :qpqual <> :lefttree { SEQSCAN :cost 20 :rows 1000 :width 8 :state <> :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 2 :varattno 2 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 2}} { TARGETENTRY :resdom { RESDOM :resno 2 :restype 23 :restypmod -1 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 2 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 1}}) :qpqual <> :lefttree <> :righttree <> :extprm () :locprm () :initplan <> :nprm 0 :scanrelid 2 } :righttree <> :extprm () :locprm () :initplan <> :nprm 0 :nonameid 0 :keycount 1 } :righttree { SORT :cost 69.8289 :rows 1000 :width 4 :state <> :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :!
!
restype 23 :restypmod -1 :resname <> :reskey 1 :reskeyop 66 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 1}}) :qpqual <> :lefttree { SEQSCAN :cost 20 :rows 1000 :width 4 :state <> :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 1}}) :qpqual <> :lefttree <> :righttree <> :extprm () :locprm () :initplan <> :nprm 0 :scanrelid 1 } :righttree <> :extprm () :locprm () :initplan <> :nprm 0 :nonameid 0 :keycount 1 } :extprm () :locprm () :initplan <> :nprm 0 :mergeclauses ({ EXPR :typeOid 16 :opType op :oper { OPER :opno 96 :opid 65 :opresulttype 16 } :args ({ VAR :varno 65001 :varattno 2 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 1} { VAR :varno 65000 :varattno 1 :vartype 2!
!
3 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 1})})}

ProcessQuery
CommitTransactionCommand

Any changes in backend/optimizer/ ? I've got a bunch of uncommitted
changes there myself.

Not too much. Though I've got a null pointer problem in executor for
mergejoins and I'm not certain where it is coming from.

Could easy be a planner shortcoming. Maybe you should commit so we
can get more eyeballs on the problem.

Here are the files which have changed in the optimizer/ tree:

[postgres@golem optimizer]$ cvs -q update .
M prep/prepunion.c
M util/clauses.c

The changes are minor; I'm pretty sure I can remerge if you want to
commit your stuff (at least if your stuff is isolated to the
backend/optimizer/ part of the tree).

I know I've tromped on your toes in the past weeks, so I'll wait for
you to commit and then merge. I have no changes in those two files,
but I do have some in the usual-suspect places like nodes/copyfuncs.

regards, tom lane

From bouncefilter Fri Feb 11 04:16:54 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA05902
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 04:16:28 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id QAA00206; Fri, 11 Feb 2000 16:28:58 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Constantin Teodorescu" <teo@flex.ro>,
"Magnus Hagander" <mha@sollentuna.net>
Cc: <pgsql-hackers@postgreSQL.org>, "'Jan Wieck'" <wieck@debis.com>,
"Rini Dutta" <rinid@rocketmail.com>,
"pgsql-interfaces-digest" <pgsql-interfaces-digest@hub.org>
Subject: RE: [HACKERS] how to make libpq on winnt using the 'win32.mak's
Date: Fri, 11 Feb 2000 16:35:02 +0900
Message-ID: <000e01bf7462$81d992c0$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To:
<215896B6B5E1CF11BC5600805FFEA82103045A1D@sirius.edu.sollentuna.se>
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Magnus Hagander

Hi

I'm running postgres v6.5.3. I need to make calls to
the functions in libpq in my code. For this I need the
files - libpq.lib/libpq.lib.dll/libpqdll.lib.

You find prepared .dll's under

src/bin/pgaccess/win32/dll

Wasn't there some utility to generate .lib files from .dll's?

I've made the dll's(libpq.dll libpgtcl.dll) under pgaccess/win32
by Constantin's request. Could someone make them instead
from now ? I've used them little myself and would lose VC++
environmemt in the near future.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp