Re: [GENERAL] +/- Inf for float8's

So, any suggestions as to how we can store +/- infinity as a valid float8
value in a database table?

Right: the SQL standard doesn't say anything about what to do for these
cases for floats (except by defining the syntax of an approximate numeric
constant as basically a float), but the IEEE754 does: as you discovered
below, they're NaN, -Infinity, and +Infinity.

Not all computers fully support IEEE754, though many new ones do.

I notice, btw, that 'NaN' is accepted as a valid float8. Is there any
particular reason why something similar for, eg '-Inf' and 'Inf' doesn't
also exist? Just discovered, there is a special number 'Infinity', which
seems to be recognised, except you can't insert it into a table because it
reports an overflow error. Getting warm, it seems, but not there yet. And
there doesn't seem to be a negative equivalent.

And this is a bug. From looking at the source, I see that Thomas added
code to accept 'NaN' and 'Infinity' (but not '-Infinity'), and Tom Lane
tweaked it, but it's never been able to get an Infinity all the way to
the table, as far as I can see: the value gets set to HUGE_VAL, but the
call to CheckFloat8Val compares against FLOAT8_MAX (and FLOAT8_MIN),
and complains, since HUGE_VAL is _defined_ to be larger than DBL_MAX.
And, there's no test case in the regression tests for inserting NaN or
Infinity. (Shame on Thomas ;-)

Ah, I'm just trying to leave some rewarding work for other folks ;)

I think the right thing to do is move the call to CheckFloat8Val into a
branch of the test for NaN and Infinity, thereby not calling it if we've
been passed those constants. I'm compiling up a test of this right now,
and I'll submit a patch to Bruce if it passes regression. Looks like
that function hasn't been touch in a while, so the patch should apply
to 7.0.X as well as current CVS.

istm that the existing protection (or something like it) is required for
some platforms, while other platforms may be able to handle NaN and
+/-Inf just fine. Seems like a job for autoconf to determine the FP
capabilities of a system, unless Posix defines some way to tell. Of
course, even then we'd need an autoconf test to deal with non-Posix
platforms.

Looks like it works, and passes the regression tests as they are. I'm
patching the tests to include the cases 'NaN', 'Infinity', and '-Infinity'
as valid float8s, and 'not a float' as an invalid representation, and
rerunning to get output to submit with the patch. This might be a bit
hairy, since there are 5 different expected/float8* files. Should I try
to hand patch them to deal with the new rows, or let them be regenerated
by people with the appropriate platforms?

How about setting up a separate test (say, ieee754.sql) so that
non-compliant platforms can still pass the original FP test suite. Then
other platforms can be added in as they are tested.

Some platforms may need their compiler switches tweaked; I haven't
checked the Alpha/DUnix configuration but I recall needing to fix some
flags to get compiled code to move these edge cases around even just
through subroutine calls. One example was in trying to call finite(),
which threw an error during the call to it if the number was NaN or
Infinity. Which sort of defeated the purpose of the call :)

Bigger problem with changing the float8 regression tests: a lot of our
math functions seem to be guarded with CheckFloat8Val(result), so, if we
allow these values in a float8 column, most of the math functions with
elog(). It strikes me that there must have been a reason for this at one
time. There's even a #define UNSAFE_FLOATS, to disable these checks. By
reading the comments in old copies of float.c, it looks like this was
added for an old, buggy linux/Alpha libc that would throw floating point
exceptions, otherwise.

There are still reasons on some platforms, as noted above...

Is there an intrinsic problem with allowing values outside the range
FLOAT8_MAX <= x =>FLOAT8_MIN ? 'ORDER BY' seems to still work, with
'Infinity' and '-Infinity' sorting properly. Having a 'NaN' in there
breaks sorting however. That's a current, live bug. Could be fixed
by treating 'NaN' as a different flavor of NULL. Probably a fairly deep
change, however. Hmm, NULL in a float8 sorts to the end, regardless of
ASC or DESC, is that right?

NULL and NaN are not quite the same thing imho. If we are allowing NaN
in columns, then it is *known* to be NaN.

Anyway, here's the patch for just float.c , if anyone wants to look
at it. As I said, it passes the existing float8 regression tests, but
raises a lot of interesting questions.

Are you interested in pursuing this further? It seems like we might be
able to move in the direction you suggest on *some* platforms, but we
will need to scrub the math functions to be able to handle these edge
cases.

- Thomas

On Tue, Aug 15, 2000 at 03:27:55AM +0000, Thomas Lockhart wrote:

Not all computers fully support IEEE754, though many new ones do.

True - the question becomes: how new is new? Are we supporting ones
that aren't? If so, that's fine. If not, it's a lot easier to fix. ;-)

And, there's no test case in the regression tests for inserting NaN or
Infinity. (Shame on Thomas ;-)

Ah, I'm just trying to leave some rewarding work for other folks ;)

And we appreciate the crumbs. Actually, it _was_ good practice grovelling
out versions from CVS and matching log messages.

istm that the existing protection (or something like it) is required for
some platforms, while other platforms may be able to handle NaN and
+/-Inf just fine. Seems like a job for autoconf to determine the FP
capabilities of a system, unless Posix defines some way to tell. Of
course, even then we'd need an autoconf test to deal with non-Posix
platforms.

Yeah, need to get Peter Eisentraut involved, perhaps. Should actually be
pretty simple: the #define is already there: UNSAFE_FLOATS. Define that,
and the CheckFloat[48]Val functions just return true.

How about setting up a separate test (say, ieee754.sql) so that
non-compliant platforms can still pass the original FP test suite. Then
other platforms can be added in as they are tested.

Hmm, I wish we had clue what other systems might be non-compliant, and how.
The question becomes one of if it's _possible_ to support NaN, +/-Inf on
some platforms. Then, we end up with a difference in functionality.

Is there an intrinsic problem with allowing values outside the range
FLOAT8_MAX <= x =>FLOAT8_MIN ? 'ORDER BY' seems to still work, with
'Infinity' and '-Infinity' sorting properly. Having a 'NaN' in there
breaks sorting however. That's a current, live bug. Could be fixed
by treating 'NaN' as a different flavor of NULL. Probably a fairly deep
change, however. Hmm, NULL in a float8 sorts to the end, regardless of
ASC or DESC, is that right?

NULL and NaN are not quite the same thing imho. If we are allowing NaN
in columns, then it is *known* to be NaN.

For the purposes of ordering, however, they are very similar. Neither one
can be placed corectly with respect to the other values: NULL, because
we don't know were it really is, NaN because we know it's not even on
this axis. I'm suggesting the we fix sorting on floats to treat NaN as
NULL, and sort it to the end. As it stands, sorting is broken, since it
returns the NaN rows wherever they happen to be. This causes them to
act as barriers, partitioning the returned set into seperately sorted
sub sequences.

Anyway, here's the patch for just float.c , if anyone wants to look
at it. As I said, it passes the existing float8 regression tests, but
raises a lot of interesting questions.

Are you interested in pursuing this further? It seems like we might be
able to move in the direction you suggest on *some* platforms, but we
will need to scrub the math functions to be able to handle these edge
cases.

Sure. I'm no great floating point wiz, but I'm sure Tom and Don will
jump on anything I get wrong. Duping the float tests and feeding them
NaN/+/-Inf as a seperate test set is probably a good idea.

The existing patch moves the call to CheckFloat8Val() inside float8in
so it is only called if strtod() consumes all it's input, and does not
set errno. Seems safe to me: if strtod() doesn't consume it's input,
we check to make sure it's not NaN/+/-Inf (gah, need a shorthand word
for those three values), else elog(). If it does, but sets errno,
we catch that. Then, in belt-and-suspenders style, we call
CheckFloat8Val(). For that check to fail, strtod() would have to consume
its entire input, return +/-HUGE_VAL, and _not_ set errno to ERANGE.

BTW, this also brings up something that got discussed before the last
release, but never implemented. The original problem from Tim Allen had
to do with using a work around for not having +/- Inf: storing the values
-1.79769313486232e+308 and 1.79769313486232e+308. He was having trouble,
since a pg_dump/restore cycle broke, do to rounding the values to out
of range for floats. This wasn't caught by the current regression tests,
but would have been caught by the suggested dump/restore/dump/compare
dumps cycle someone suggested for exercizing the *out and *in functions.

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

Thomas -
A general design question. There seems to be a good reason to allow +/-Inf
in float8 columns: Tim Allen has an need for them, for example. That's
pretty straight forward, they seem to act properly if the underlying float
libs handle them.

I'm not convinced NaN gives us anything useful, especially given how
badly it breaks sorting. I've been digging into that code a little,
and it's not going to be pretty. It strikes me as wrong to embed type
specific info into the generic sorting routines.

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

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

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

Hmm. With Tom Lane's new fmgr interface, you *can* return NULL if you
spot a NaN result. Maybe that is the best way to go about it; we'll
stipulate that NaN and NULL are equivalent. And we'll further stipulate
that if you are messing with NaN then you deserve what you get ;)

- Thomas

I can't say whether its worth the trouble to add NaN, but I will say that NaN
is not the same as NULL. NULL is missing data; NaN is 0./0. The difference
is significant for numerical applications.

Tim

"Ross J. Reedstrom" wrote:

Thomas -
A general design question. There seems to be a good reason to allow +/-Inf
in float8 columns: Tim Allen has an need for them, for example. That's
pretty straight forward, they seem to act properly if the underlying float
libs handle them.

I'm not convinced NaN gives us anything useful, especially given how
badly it breaks sorting. I've been digging into that code a little,
and it's not going to be pretty. It strikes me as wrong to embed type
specific info into the generic sorting routines.

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

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

--
Timothy H. Keitt
National Center for Ecological Analysis and Synthesis
735 State Street, Suite 300, Santa Barbara, CA 93101
Phone: 805-892-2519, FAX: 805-892-2510
http://www.nceas.ucsb.edu/~keitt/

I'm not convinced NaN gives us anything useful, especially given how
badly it breaks sorting. I've been digging into that code a little,
and it's not going to be pretty. It strikes me as wrong to embed type
specific info into the generic sorting routines.

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

Ross

Just a wild guess, NaN could be used to indicated invalid numeric
data. However, this seems odd because it should have been checked prior to
being put in the DB.

NULL is no value, +/- infinity could be just that or out of range, unless
you want NaN to be out of range. Depending on your scheme for
representation you could take an out of range value and store it as +/i
infinity.

These are just suggestions.

Thomas

Hi,

just to add my opinion on NaN in the IEEE standard. As far as I
remember, IEEE numbers work as follows:

1 bit sign
some bits base
some bits exponent

This allows you to do several things:

interpret the exp bits as a normal integer and get
- exp=below half: negative exponents
- exp=half: exponent=0
- exp=above half: positive exponents
- exp=all set: NaN, quite a few at that

For all of these the sign can be either positive or negative, leading
to pos/neg zero (quite a strange concept).

With the NaNs, you get quite a few possibilities, but notably:
- base=0 (NaN -- this is not a number, but an animal)
- base=max (pos/neg infinity, depending on sign)

Someone mentioned a representation for 0/0 and I might add that there
are four possibilities:
(( 1.)*0.) / (( 1.)*0.)
(( 1.)*0.) / ((-1.)*0.)
((-1.)*0.) / (( 1.)*0.)
((-1.)*0.) / ((-1.)*0.)
These (given commutativity, except that we're dealing with a finite
representation, but predictable in that it is actually possible to
factor out the sign) can be reduced to:
( 1) * (0./0.)
(-1) * (0./0.)
which amounts to pos/neg infinity of some sort.

Now my take on NULL vs NaN is that there should be a whole bunch of
NULL, just like there is a whole bunch of NaN. Just off the top of my
head, I could imagine "unknown", "unknowable", "out of range in
direction X". But, alas, the SQL standard doesn't provide for such
things (though the storage implementation would: but what would you do
with comparisons, conversions and displays?).

so long,

Oliver

Thomas -
A general design question. There seems to be a good reason to
allow +/-Inf in float8 columns: Tim Allen has an need for them, for
example. That's pretty straight forward, they seem to act properly if
the underlying float libs handle them.

Thanks for pursuing this, Ross. I shall look forward to not having to use
a workaround in future versions.

I'm not convinced NaN gives us anything useful, especially given how
badly it breaks sorting. I've been digging into that code a little,
and it's not going to be pretty. It strikes me as wrong to embed type
specific info into the generic sorting routines.

Actually, we also have a use for NaN. The main thing we're using this for
is to store "fields", ie general descriptions of particular items of
metadata that occur in our application. Each field can have a validity
condition (ie min <= X <= max), and for open ranges we find the easiest
way to handle that without needing any extra bool flags or whatever is
just to set the minimum value to -infinity and/or the max to +infinity.

Our fields also have a default value, used in case the user didn't
actually enter anything. However, we want to be able to support something
like a NULL, so that if the user doesn't enter anything then in some cases
that means "there is no value". These values get passed around inside our
applications in various ways, in subsystems that don't have any direct
communication with the database, so using a database NULL doesn't do the
job. An NaN, however, is perfect for the job, because you can transmit
NaN's down sockets between processes, you can copy them around without
needing any special handling, and you can (currently) write them to and
read them from the database. So, for what it's worth, here's one vote for
keeping NaN's. As for sorting, we don't really care how they sort. Any
consistent behaviour will do for us.

Yes, there is a difference between an NaN and a NULL, but that difference
is not important in our application. We never do any serious arithmetic on
our float8 values, we just store them in the database and allow users to
view and edit the values.

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

It's this last point that makes NaN's useful; most non DB numeric
applications don't have a NULL, and NaN can make an adequate substitute.
One thing we could do, I suppose, is add code to our db interface layer to
translate NaN's to NULL's and vice versa. But if we don't have to, we'd be
happier :-).

Ross

Tim

--
-----------------------------------------------
Tim Allen tim@proximity.com.au
Proximity Pty Ltd http://www.proximity.com.au/
http://www4.tpg.com.au/users/rita_tim/

On Wed, Aug 16, 2000 at 11:16:24AM +1000, Tim Allen wrote:

Thanks for pursuing this, Ross. I shall look forward to not having to use
a workaround in future versions.

See, Tim knows how to get work out of Open Source programmers. Flattery, not
flames ;-)

Actually, we also have a use for NaN. The main thing we're using this for

<snip>

read them from the database. So, for what it's worth, here's one vote for
keeping NaN's. As for sorting, we don't really care how they sort. Any
consistent behaviour will do for us.

Right. Currently, NaN's break sorting of everything else in the column.
Not good. But Thomas mentioned a possible clever work around. I've got to
dig into the code a bit more to see if it'll work.

Yes, there is a difference between an NaN and a NULL, but that difference
is not important in our application. We never do any serious arithmetic on
our float8 values, we just store them in the database and allow users to
view and edit the values.

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

It's this last point that makes NaN's useful; most non DB numeric
applications don't have a NULL, and NaN can make an adequate substitute.
One thing we could do, I suppose, is add code to our db interface layer to
translate NaN's to NULL's and vice versa. But if we don't have to, we'd be
happier :-).

Well, this is open source: all we need is one customer, if the idea
is sound. (Usually, that's the coder themselves, but not always. And
conversely, if it's a lousy idea, it doesn't matter howmany people
want it!) I had forgotten that the DB often interacts with non-DB
code. (What, you mean psql and hand typed queries isn't good enough for
your clients?) 'Course, I'm the type that's been known to code figures
directly in Postscript because the drawing package wouldn't do what I
wanted to.

I'll definitely look into this some more. If we can solve the sort
problem without to big a kludge, I think we might be able to let people
do serious math in the backend, let the non-finites fly!

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

(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)

Ross J. Reedstrom writes:

Yeah, need to get Peter Eisentraut involved, perhaps. Should actually be
pretty simple: the #define is already there: UNSAFE_FLOATS. Define that,
and the CheckFloat[48]Val functions just return true.

Show me a system where it doesn't work and we'll get it to work.
UNSAFE_FLOATS as it stands it probably not the most appropriate behaviour;
it intends to speed things up, not make things portable.

NULL and NaN are not quite the same thing imho. If we are allowing NaN
in columns, then it is *known* to be NaN.

For the purposes of ordering, however, they are very similar.

Then we can also treat them similar, i.e. sort them all last or all first.
If you have NaN's in your data you wouldn't be interested in ordering
anyway.

we check to make sure it's not NaN/+/-Inf (gah, need a shorthand word
for those three values), else elog().

"non-finite values"

Side note 2: The paper "How Java's floating point hurts everyone
everywhere" provides for good context reading.

Side note 3: Once you read that paper you will agree that using floating
point with Postgres is completely insane as long as the FE/BE protocol is
text-based.

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

Thomas Lockhart writes:

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

Hmm. With Tom Lane's new fmgr interface, you *can* return NULL if you
spot a NaN result. Maybe that is the best way to go about it; we'll
stipulate that NaN and NULL are equivalent. And we'll further stipulate
that if you are messing with NaN then you deserve what you get ;)

I beg to differ, this behaviour would not be correct. Instead, this should
happen:

NULL < NULL => NULL
NULL < 1.0 => NULL
NULL < Nan => NULL
1.0 < NULL => NULL
1.0 < NaN => false
NaN < NULL => NULL
NaN < 1.0 => false

Then all the NaN's sort either all first or all last before or after the
NULLs.

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

At 12:33 AM 8/20/00 +0200, Peter Eisentraut wrote:

(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)

OpenACS and arsDigita are using Ben Adida's software development manager,
which includes a ticket-tracking module. It's still under development,
but you can take a look at www.openacs.org/sdm to see how we're using
it.

It was developed for Postgres (which is what you see at the above URL)
then ported to Oracle (which is what you arsDigita does). aD has also
added some functionality which is supposed to be ported back to the
Postgres version.

Among other things it integrates with a todo list manager that maintains
individual todo lists for developers ... you're assigned a bug, it
ends up on your todo list.

- 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.

Ben has an account on Hub, and aolserver has been installed, so if you
guys want to install and get this working, just tell me what else you need
as far as software and/or configurations are concerned and "it shall be
done" ...

On Sat, 19 Aug 2000, Don Baccus wrote:

At 12:33 AM 8/20/00 +0200, Peter Eisentraut wrote:

(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)

OpenACS and arsDigita are using Ben Adida's software development manager,
which includes a ticket-tracking module. It's still under development,
but you can take a look at www.openacs.org/sdm to see how we're using
it.

It was developed for Postgres (which is what you see at the above URL)
then ported to Oracle (which is what you arsDigita does). aD has also
added some functionality which is supposed to be ported back to the
Postgres version.

Among other things it integrates with a todo list manager that maintains
individual todo lists for developers ... you're assigned a bug, it
ends up on your todo list.

- 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.

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

At 09:01 PM 8/19/00 -0300, The Hermit Hacker wrote:

Ben has an account on Hub, and aolserver has been installed, so if you
guys want to install and get this working, just tell me what else you need
as far as software and/or configurations are concerned and "it shall be
done" ...

I've e-mailed Ben a "heads-up", though he monitors this list and will probably
see your note.

I'll be gone about five of the next 6-7 weeks mostly doing my annual stint as
a field biologist where I'm only accessible once a day via radio by BLM
Dispatch
in Elko, Nevada so I'm afraid this (like many other things at the moment) will
fall on Ben's shoulders...

- 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.

http://www.postgresql.org/bugs/

I was about to implement it once before and the directory disappeared.
But anyway it's there.

Vince.

On Sat, 19 Aug 2000, The Hermit Hacker wrote:

Ben has an account on Hub, and aolserver has been installed, so if you
guys want to install and get this working, just tell me what else you need
as far as software and/or configurations are concerned and "it shall be
done" ...

On Sat, 19 Aug 2000, Don Baccus wrote:

At 12:33 AM 8/20/00 +0200, Peter Eisentraut wrote:

(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)

OpenACS and arsDigita are using Ben Adida's software development manager,
which includes a ticket-tracking module. It's still under development,
but you can take a look at www.openacs.org/sdm to see how we're using
it.

It was developed for Postgres (which is what you see at the above URL)
then ported to Oracle (which is what you arsDigita does). aD has also
added some functionality which is supposed to be ported back to the
Postgres version.

Among other things it integrates with a todo list manager that maintains
individual todo lists for developers ... you're assigned a bug, it
ends up on your todo list.

- 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.

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

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

At 08:34 PM 8/19/00 -0400, Vince Vielhaber wrote:

http://www.postgresql.org/bugs/

I was about to implement it once before and the directory disappeared.
But anyway it's there.

Cool, I tried it and broke it on my second click ... any particular reason
to roll your own rather than use something that's already being used by
several other development projects and is under active development for
that reason? (i.e. the SDM)

- 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.

Don Baccus wrote:

(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)

istm that it is *not* that easy. We tried (very briefly) a bug tracking
system. Whatever technical problems it had (which other tools may not),
the fundamental problem is that the mailing lists do a *great* job of
screening problem reports while also supporting and enhancing the
"Postgres culture", whereas a "bug report tool" eliminates that traffic
and requires one or a few people to pay attention to the bug list to
manage new and existing bug reports.

This has (or could have) a *huge* impact on the culture and tradition of
Postgres development, which imho is one of the most satisfying,
pleasant, and effective environments in open source development. So if
we try to do something with a bug tracking system, we will need to
figure out:

o how to retain a free and helpful discussion on the mailing lists, and
to not degrade into a "shut up and check the bug reports" response.

o how to filter or qualify bug reports so that developers don't spend
time having to do that.

All imho of course ;)

- Thomas

At 01:22 AM 8/20/00 +0000, Thomas Lockhart wrote:

istm that it is *not* that easy. We tried (very briefly) a bug tracking
system. Whatever technical problems it had (which other tools may not),
the fundamental problem is that the mailing lists do a *great* job of
screening problem reports while also supporting and enhancing the
"Postgres culture", whereas a "bug report tool" eliminates that traffic
and requires one or a few people to pay attention to the bug list to
manage new and existing bug reports.

In the SDM you can, of course, ask to be notified of various events
by e-mail. And there's a commenting facility so in essence a bug
report or feature request starts a conversation thread.

I don't recall saying that the SDM is simply a "bug report tool". There's
quite a bit more to it, and the goal is to INCREASE interactivity, not
decrease it.

This has (or could have) a *huge* impact on the culture and tradition of
Postgres development, which imho is one of the most satisfying,
pleasant, and effective environments in open source development. So if
we try to do something with a bug tracking system, we will need to
figure out:

o how to retain a free and helpful discussion on the mailing lists, and
to not degrade into a "shut up and check the bug reports" response.

This is a social, not software, engineering issue.

o how to filter or qualify bug reports so that developers don't spend
time having to do that.

Developers don't have to filter or qualify bug reports e-mailed to the
bugs list today? Who's doing it, then, and why can't they continue doing
so if another tool is used to manage bug reports?

The SDM allows a little more granularity than the single e-mail list
aproach allows for. You can designate modules within a package. For
instance, psql might be a module with Peter assigned as an administrator,
and he might elect to get e-mail alerts whenever a bug is submitted to
for psql.

But he might not, for instance, be particularly interested in getting
e-mail alerts on (say) the JDBC driver.

There's a certain amount of delegation inherent in an approach like
this, and developers focused on narrow portions of the product (and
Peter came to mind because of psql, I'm not suggesting he only has
a narrow interest in the product) can arrange to only get nagged, if
you will, for stuff they've taken responsibility for.

My guess is that such a system probably isn't as cozy and useful for
developers, as you're implying.

I think it might well be more friendly for users, though. Certainly
the OpenACS and arsDigita communities - both fairly large though
not as long in the tooth as PG, I might add - seem to appreciate having
access to such a 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.

On Sat, 19 Aug 2000, Don Baccus wrote:

At 08:34 PM 8/19/00 -0400, Vince Vielhaber wrote:

http://www.postgresql.org/bugs/

I was about to implement it once before and the directory disappeared.
But anyway it's there.

Cool, I tried it and broke it on my second click ... any particular reason
to roll your own rather than use something that's already being used by
several other development projects and is under active development for
that reason? (i.e. the SDM)

Like I said, the dir disappeared before I could commit it, probably some
config stuff too. We tried a couple of already in use items and frankly
I got tired of learning a new package that noone used anyway. I figured
at least this one could be more of what we needed. It logs the problem
in the database and emails the bugs list (I may have the wrong list
addr in there too). The status can be changed, entries can be made as
to the status.

What did you do to break it and what broke?

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

If Ben and gang are willing to work on the bug tracking system to get it
to fit what we want/need, it would give a good example of OpenACS and gang
for them to use ... we could just shot "wants" at them and they could
improve as we go along?

On Sat, 19 Aug 2000, Vince Vielhaber wrote:

On Sat, 19 Aug 2000, Don Baccus wrote:

At 08:34 PM 8/19/00 -0400, Vince Vielhaber wrote:

http://www.postgresql.org/bugs/

I was about to implement it once before and the directory disappeared.
But anyway it's there.

Cool, I tried it and broke it on my second click ... any particular reason
to roll your own rather than use something that's already being used by
several other development projects and is under active development for
that reason? (i.e. the SDM)

Like I said, the dir disappeared before I could commit it, probably some
config stuff too. We tried a couple of already in use items and frankly
I got tired of learning a new package that noone used anyway. I figured
at least this one could be more of what we needed. It logs the problem
in the database and emails the bugs list (I may have the wrong list
addr in there too). The status can be changed, entries can be made as
to the status.

What did you do to break it and what broke?

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

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

On Sat, 19 Aug 2000, Don Baccus wrote:

o how to filter or qualify bug reports so that developers don't spend
time having to do that.

Developers don't have to filter or qualify bug reports e-mailed to the
bugs list today? Who's doing it, then, and why can't they continue
doing so if another tool is used to manage bug reports?

the problem as I see it with any bug tracking tool is someone has to close
off those bugs when fixed ... right now, someone commits a bug fix, and
then fires off an email to the list stating its fixed ... with a bug
tracking system, then they have to go one more step, open up a web
browser, login to the system, find the bug report and close it ...

On Sun, 20 Aug 2000, The Hermit Hacker wrote:

If Ben and gang are willing to work on the bug tracking system to get it
to fit what we want/need, it would give a good example of OpenACS and gang
for them to use ... we could just shot "wants" at them and they could
improve as we go along?

Fine by me, BUT I have no desire to learn how it works. If that's gonna
be the end result then rm -Rf is my preference. This'll be the third or
forth one so far, the others were pushed off the edge of the earth. Sorry
to be so harsh but no matter what the bug tool is I can't see it lasting
very long. This group has shown repeatedly that it's not as desired as
it appears to be.

Vince.

On Sat, 19 Aug 2000, Vince Vielhaber wrote:

On Sat, 19 Aug 2000, Don Baccus wrote:

At 08:34 PM 8/19/00 -0400, Vince Vielhaber wrote:

http://www.postgresql.org/bugs/

I was about to implement it once before and the directory disappeared.
But anyway it's there.

Cool, I tried it and broke it on my second click ... any particular reason
to roll your own rather than use something that's already being used by
several other development projects and is under active development for
that reason? (i.e. the SDM)

Like I said, the dir disappeared before I could commit it, probably some
config stuff too. We tried a couple of already in use items and frankly
I got tired of learning a new package that noone used anyway. I figured
at least this one could be more of what we needed. It logs the problem
in the database and emails the bugs list (I may have the wrong list
addr in there too). The status can be changed, entries can be made as
to the status.

What did you do to break it and what broke?

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

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

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

FWIW, I agree with Thomas' comments: our last try at a bug-tracking
system was a spectacular failure, and rather than just trying again
with a technically better bug-tracker, we need to understand why we
failed before.

I think we do need to look for a better answer than what we have, but
I do not have any faith in "install system FOO and all your problems
will be solved".

My take is that

(a) a bug *tracking* system is not the same as a bug *reporting*
system. A tracking system will be useless if it gets cluttered
with non-bug reports, duplicate entries, etc. There must be a human
filter controlling what gets entered into the system.

(b) our previous try (with Keystone) was a failure in part because
it was not even effective as a bug reporting system: it did not
encourage people to fill in our standard "bug report form", with the
result that bug reports were seriously incomplete w.r.t. version
numbers, platforms, etc. This is a relatively simple technical
deficiency, not a social-engineering problem, but it does point up
the fact that one-size-fits-all solutions fit nobody.

(c) fill-in-the-web-form reporting systems suck. They make it
difficult to copy-and-paste query output, dump files, etc.
Also, the window for entering text is always either too small or too
large. Email with attachments is fundamentally superior.

(d) divorcing the bug reporting system from the existing mailing
list community is foolish, as Thomas pointed out. When a bug report
is a non-bug (user error, etc) or fixed in a later version or just
a duplicate, we tend to rely on the rest of the community to give
the reporter a helpful response. Funneling reports into a separate
system that is only read by a few key developers will lose.

I'm not sure what I want, but I know what I don't want...

regards, tom lane

The Hermit Hacker wrote:

the problem as I see it with any bug tracking tool is someone has to close
off those bugs when fixed ... right now, someone commits a bug fix, and
then fires off an email to the list stating its fixed ... with a bug
tracking system, then they have to go one more step, open up a web
browser, login to the system, find the bug report and close it ...

With something like the SDM, the developer can also just mark that bug fixed
online and whoever requested notifications (like maybe the pgsql-hackers
mailing list) can get a one-liner automated email. This is great for
individual users who are particularly interested in seeing one bug fixed:
they request notification on that bug, and only get notifications that
pertain to it...

-Ben

Tom Lane wrote:

FWIW, I agree with Thomas' comments: our last try at a bug-tracking
system was a spectacular failure, and rather than just trying again
with a technically better bug-tracker, we need to understand why we
failed before.

Okay, well then this is an interesting discussion: the OpenACS project
and my company (OpenForce) would very much be interested in discussing
what you guys think would be a useful bug tracking system. What kind of
features would it need? Nothing is too fancy here, the idea is to have
the best possible system, one that focused developers like the PG team
would use.

Maybe we should take this offline? I'm happy to keep this discussion
going and hear everything you've got to say: understanding what it would
take to build a system you guys would use is *very* important data.

-Ben

Perhaps this is foolhardy, but it might be worth making a list of
requirements, at least so we can tick moxes when considering any system...

(a) a bug *tracking* system is not the same as a bug *reporting*
system. A tracking system will be useless if it gets cluttered
with non-bug reports, duplicate entries, etc. There must be a human
filter controlling what gets entered into the system.

1. Human filtering of 'incoming' reports.

2. Separation of 'bug reports' from 'bugs'.

(b) our previous try (with Keystone) was a failure in part because
it was not even effective as a bug reporting system: it did not
encourage people to fill in our standard "bug report form", with the
result that bug reports were seriously incomplete w.r.t. version
numbers, platforms, etc. This is a relatively simple technical
deficiency, not a social-engineering problem, but it does point up
the fact that one-size-fits-all solutions fit nobody.

3. Web and email submissions should do data verification and reject
incomplete reports (giving reasons).

(c) fill-in-the-web-form reporting systems suck. They make it
difficult to copy-and-paste query output, dump files, etc.
Also, the window for entering text is always either too small or too
large. Email with attachments is fundamentally superior.

[I disagree with the above (web *can* work), but...]

4. Must support email AND web submissions, or at least email submissions
and web reporting.

(d) divorcing the bug reporting system from the existing mailing
list community is foolish, as Thomas pointed out.

5. Must integrate with mailing lists.

And to add some of my own (suggested) requirements:

6. Require: name, email address, OS & version, PG version, short description.

7. Optional: compiler & version, long description, file attachments.

8. Creation of 'bug reports' is a public function. Creation of 'bug
entries' is a priv'd function.

9. Simple reporting - unprocessed bug reports, open bugs, bugs by module etc.

I have tried to keep this relatively simple in an effort to define what we
need to make it work in the current context. But I'm sure I've missed
things....

<YABRS>
As it happens, I have a Perl/PGSql based bug-tracking system that I give my
clients access to, which does about 80-90% of this, and I would be willing
to GPL it.

Before anybody asks, the reason I rolled my own was because there weren't
many that supported email and web submission, and the ones that did, did
not support PG easily. This system also implements my prefferred model for
bug reporting which is to separate (to use my terminology) 'Incidents' from
'Issues': an Incident is an event (or set of events) that causes a user to
make a report. An Issue is an individual item that needs attention (usually
a single bug). Typically users send email (or web forms) and I create one
or more Issues. When two Incidents (bug reports) are made about the same
Issue, then the system allows the two to be linked, so that when the Issue
is fixed, all Incident owners are notified etc.

The email integration does very little validation, and it is *not*
integrated with a mailing list (but it is on my ToDo list). I had planned
to do the following:

- When a message is received and the subject does not start with 'Re:' (or
'Aw:'!), submit it as a bug report. If the bug report code returns an
error, then reject it from the list. If the bug report works, then send it
on to Majordomo & Mhonarc.

- If the message starts with 'Re:' then just submit it to the list.

Let me know if anyone would be interested, and I can set up a sample
'product' for people to play with and then, if it is still worth pursuing,
make the code a little more presentable (and decrease it's reliance on my
own perl libraries).

Bear in mind that this is designed for an Apache/mod-perl environment, so
may not be acceptable to some people.
</YABRS>

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

On Sun, 20 Aug 2000, Ben Adida wrote:

The Hermit Hacker wrote:

the problem as I see it with any bug tracking tool is someone has to close
off those bugs when fixed ... right now, someone commits a bug fix, and
then fires off an email to the list stating its fixed ... with a bug
tracking system, then they have to go one more step, open up a web
browser, login to the system, find the bug report and close it ...

With something like the SDM, the developer can also just mark that bug
fixed online and whoever requested notifications (like maybe the
pgsql-hackers mailing list) can get a one-liner automated email. This
is great for individual users who are particularly interested in
seeing one bug fixed: they request notification on that bug, and only
get notifications that pertain to it...

what we'd need would be soemthing where a person enters the bug report, it
gets email'd out to -bugs so that developers see it ... if a developer
comments on it, it should go from taht email into the database ... if a
developer fixes it, there should be an easy email mechanism whereby the
developer can close it ...

maybe somethign so simple as those with commit access, who can fix the
bugs, have a passwd that they can include, like majordomo, in their email
to a central 'admin' mailbox that they can send a mesage to like:

passwd <passwd> close #1

Tom Lane writes:

(a) a bug *tracking* system is not the same as a bug *reporting*
system. A tracking system will be useless if it gets cluttered
with non-bug reports, duplicate entries, etc. There must be a human
filter controlling what gets entered into the system.

Letting any user submit bug reports directly into any such system is
certainly not going to work, we'd have "query does not use index" 5 times
a day. I consider the current *reporting* procedure pretty good; web forms
are overrated in my mind.

What I had in mind was more a databased incarnation of the TODO list. I
mean, who are we kidding, we are writing a database and maintain the list
of problems in flat text. The TODO list has already moved to the
TODO.detail extension, but we could take it a bit further.

I think currently too many issues get lost, or discussed over and over
again. Many developers maintain their own little lists. The TODO list
often cannot be deciphered by end users and hence does not get read.

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

Peter Eisentraut wrote:

Tom Lane writes:

(a) a bug *tracking* system is not the same as a bug *reporting*
system. A tracking system will be useless if it gets cluttered
with non-bug reports, duplicate entries, etc. There must be a human
filter controlling what gets entered into the system.

Letting any user submit bug reports directly into any such system is
certainly not going to work, we'd have "query does not use index" 5 times
a day. I consider the current *reporting* procedure pretty good; web forms
are overrated in my mind.

What I had in mind was more a databased incarnation of the TODO list. I
mean, who are we kidding, we are writing a database and maintain the list
of problems in flat text. The TODO list has already moved to the
TODO.detail extension, but we could take it a bit further.

I maintain my todo items for my projects in a postgres database. But
there are a lot of issues to consider there too:

- a table of projects (or topics)
- a table of todo items with synopsis, full description, ...
- a table of versions (item is planned to be solved in version, x.x.x,
actually solved in y.y.y)
- a table of developers
- assign table (projects -> developers, items -> developers)
- change type: bug,doc,rfe (request for enhancement),idc (internal
design change), ...
- change state (accepted, evaluated, fixed, rejected, incomplete,
committed, ...
- severity or priority of each item, project
- search functionality

Regards
Wim

On Sun, 20 Aug 2000, Peter Eisentraut wrote:

Tom Lane writes:

(a) a bug *tracking* system is not the same as a bug *reporting*
system. A tracking system will be useless if it gets cluttered
with non-bug reports, duplicate entries, etc. There must be a human
filter controlling what gets entered into the system.

Letting any user submit bug reports directly into any such system is
certainly not going to work, we'd have "query does not use index" 5 times
a day. I consider the current *reporting* procedure pretty good; web forms
are overrated in my mind.

What I had in mind was more a databased incarnation of the TODO list. I
mean, who are we kidding, we are writing a database and maintain the list
of problems in flat text. The TODO list has already moved to the
TODO.detail extension, but we could take it a bit further.

I think currently too many issues get lost, or discussed over and over
again. Many developers maintain their own little lists. The TODO list
often cannot be deciphered by end users and hence does not get read.

A TODO list that one can add comments to ...

I'm putting on my suits-type suit for just a moment.

In order to Conquer The Universe(tm) why don't we just call it "PG"?

-dlj.

On Sun, Aug 20, 2000 at 12:33:00AM +0200, Peter Eisentraut wrote:
<snip side comment about bug tracking. My input: for an email controllable
system, take a look at the debian bug tracking system>

Show me a system where it doesn't work and we'll get it to work.
UNSAFE_FLOATS as it stands it probably not the most appropriate behaviour;
it intends to speed things up, not make things portable.

I agree. In the previous thread on this, Thomas suggested creating a flag
that would allow control turning the CheckFloat8Val function calls into
a macro NOOP. Sound slike a plan to me.

NULL and NaN are not quite the same thing imho. If we are allowing NaN
in columns, then it is *known* to be NaN.

For the purposes of ordering, however, they are very similar.

Then we can also treat them similar, i.e. sort them all last or all first.
If you have NaN's in your data you wouldn't be interested in ordering
anyway.

Right, but the problem is that NULLs are an SQL language feature, and
there for rightly special cased directly in the sorting apparatus. NaN is
type specific, and I'd be loath to special case it in the same place. As
it happens, I've spent some time this weekend groveling through the sort
(and index, as it happens) code, and have an idea for a type specific fix.

Here's the deal, and an actual, honest to goodness bug in the current code.

As it stands, we allow one non-finite to be stored in a float8 field:
NaN, with partial parsing of 'Infinity'.

As I reported last week, NaNs break sorts: they act as barriers, creating
sorted subsections in the output. As those familiar with the code have
already guessed, there is a more serious bug: NaNs break indicies on
float8 fields, essentially chopping the index off at the first NaN.

Fixing this turns out to be a one liner to btfloat8cmp.

Fixing sorts is a bit tricker, but can be done: Currently, I've hacked
the float8lt and float8gt code to sort NaN to after +/-Infinity. (since
NULLs are special cased, they end up sorting after NaN). I don't see
any problems with this solution, and it give the desired behavior.

I've attached a patch which fixes all the sort and index problems, as well
as adding input support for -Infinity. This is not a complete solution,
since I haven't done anything with the CheckFloat8Val test. On my
system (linux/glibc2.1) compiling with UNSAFE_FLOATS seems to work fine
for testing.

Side note 2: The paper "How Java's floating point hurts everyone
everywhere" provides for good context reading.

http://http/cs.berkeley.edu/~wkahan/JAVAhurt.pdf ? I'll take a look at it
when I get in to work Monday.

Side note 3: Once you read that paper you will agree that using floating
point with Postgres is completely insane as long as the FE/BE protocol is
text-based.

Probably. But it's not our job to enforce sanity, right? Another way to think
about it is fixing the implementation so the deficiencies of the FE/BE stand
out in a clearer light. ;-)

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

what's wrong wth "Post-Gres-QL"?

I find it soooo simple to pronounce *shrug*

On Sun, 20 Aug 2000, David Lloyd-Jones wrote:

I'm putting on my suits-type suit for just a moment.

In order to Conquer The Universe(tm) why don't we just call it "PG"?

-dlj.

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

At 01:15 20/08/00 -0400, Ben Adida wrote:

Okay, well then this is an interesting discussion: the OpenACS project
and my company (OpenForce) would very much be interested in discussing
what you guys think would be a useful bug tracking system.

So am I.

Maybe we should take this offline?

If you do decide to go offline, I'd appreciate some CCs...

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

If you all don't mind, I think it'd be great to keep this discussion on the
list. As some of you know, Great Bridge is working on its own project
hosting site (including a PG-backed bug tracking module). We're not quite
ready to pull back the curtain yet, but are getting close, and will be
actively soliciting input (and hacks) from the community.

The process of getting hacker requirements for such a system is a very
useful one, IMHO...

Regards,
Ned

Philip Warner wrote:

"Ross J. Reedstrom" <reedstrm@rice.edu> writes:

! switch (isinf(num))
! {
! case -1:
! PG_RETURN_CSTRING(strcpy(ascii, "-Infinity"));
! break;
! case 1:
! PG_RETURN_CSTRING(strcpy(ascii, "Infinity"));
! break;
! default:
! break;
! }

My man page for isinf() sez:

isinf() returns a positive integer if x is +INFINITY, or a negative
integer if x is -INFINITY. Otherwise it returns zero.

so the above switch statement is making an unportable assumption about
exactly which positive or negative value will be returned.

+ if (isnan(arg2)) PG_RETURN_BOOL(1);

PG_RETURN_BOOL(true), please...

! if (isnan(a))
! PG_RETURN_INT32(1);

Do not like this at all --- doesn't it make the result of btint4cmp(NaN,
NaN) dependent on which argument chances to be first? Seems to me that
you must consider two NaNs to be equal, unless you want to subdivide
the category of NaNs.

regards, tom lane

At 10:22 PM 8/20/00 -0400, Ned Lilly wrote:

If you all don't mind, I think it'd be great to keep this discussion on the
list. As some of you know, Great Bridge is working on its own project
hosting site (including a PG-backed bug tracking module). We're not quite
ready to pull back the curtain yet, but are getting close, and will be
actively soliciting input (and hacks) from the community.

So - again - why roll your own instead of build upon a base which at least
is already seeing some use, by some fairly large organizations (arsDigita
is larger and more deeply funded than Great Bridge, making profits to boot,
and I won't even start talking about AOL)? arsDigita is putting some
developer
effort into the SDM, so it's no longer just Ben and whoever he can rope into
helping out.

Couldn't you guys more profitably spend time, say, working on outer joins
rather than doing something like this?

The folks working on the SDM have a LOT more web/db development experience
than whoever's rolling your bug tracking system.

I keep sniffing the odor of NIH ...

- 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.

At 10:22 PM 8/20/00 -0400, Ned Lilly wrote:

If you all don't mind, I think it'd be great to keep this discussion on the
list. As some of you know, Great Bridge is working on its own project
hosting site (including a PG-backed bug tracking module). We're not quite
ready to pull back the curtain yet, but are getting close, and will be
actively soliciting input (and hacks) from the community.

Another implication which missed me first time 'round is that Great Bridge
might be planning to have its own bug reporting system, separate from
that used by the development community at large?

I hope not. There should be one central place for bug reporting. If
Great Bridge wants to run it, fine, also if Great Bridge wants to be able
to incorporate some sort of prioritization system for those with paid
support (or some other discriminatory system) it is still probably better
to figure out a way to accomodate it rather than have two separate
bug reporting systems.

- 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.

On Mon, 21 Aug 2000, Don Baccus wrote:

At 10:22 PM 8/20/00 -0400, Ned Lilly wrote:

If you all don't mind, I think it'd be great to keep this discussion on the
list. As some of you know, Great Bridge is working on its own project
hosting site (including a PG-backed bug tracking module). We're not quite
ready to pull back the curtain yet, but are getting close, and will be
actively soliciting input (and hacks) from the community.

So - again - why roll your own instead of build upon a base which at least
is already seeing some use, by some fairly large organizations (arsDigita
is larger and more deeply funded than Great Bridge, making profits to boot,
and I won't even start talking about AOL)? arsDigita is putting some
developer
effort into the SDM, so it's no longer just Ben and whoever he can rope into
helping out.

Couldn't you guys more profitably spend time, say, working on outer joins
rather than doing something like this?

The folks working on the SDM have a LOT more web/db development experience
than whoever's rolling your bug tracking system.

I keep sniffing the odor of NIH ...

Could it be possible that folks are shying away because of having
to install and learn an entire webserver and tools and then the
bug tracker on top of that?

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

Vince Vielhaber wrote:

Could it be possible that folks are shying away because of having
to install and learn an entire webserver and tools and then the
bug tracker on top of that?

And so the solution is to build a totally new system?

Coming from the Postgres team, this is relatively surprising. Postgres is a great
tool. I dropped Oracle and learned Postgres because I thought it would eventually
become a better tool, and because it was already better in many ways. It took
time and effort to do so, but eventually it was the right thing to do because I
can now make full use of a very powerful open-source database.

It seems to me that the whole point of Open-Source vs. Not Invented Here is that
you are *supposed* to go out and make the effort necessary to learn new tools
that can then become extremely useful. If you accept the attitude of "it's not
Apache/mod-perl so I'm not using it," then it's time to stop all criticism of
those who use MySQL, Oracle, Windows, etc... Those people are *used* to their
technology, and the only reason they refuse to switch is that they don't want to
spend time learning something new.

Just my 2 cents.... the useful tools are not always the ones everyone is using.

-Ben

On Mon, 21 Aug 2000, Ben Adida wrote:

Vince Vielhaber wrote:

Could it be possible that folks are shying away because of having
to install and learn an entire webserver and tools and then the
bug tracker on top of that?

And so the solution is to build a totally new system?

In some cases yes.

Coming from the Postgres team, this is relatively surprising. Postgres is a great
tool. I dropped Oracle and learned Postgres because I thought it would eventually
become a better tool, and because it was already better in many ways. It took
time and effort to do so, but eventually it was the right thing to do because I
can now make full use of a very powerful open-source database.

I am *NOT* "the Postgres team". But have you listened to what you & Don
are suggesting that we, or for that matter anyone else in need of a bug
tracking system, do? You want us to install the full blown arsDigita with
all the bells and whistles just for a bug tracker. That's like saying I
need a pickup truck to move a chair so I'm going to go out and get a new
FreightLiner with a 55' trailer to do the job.

It seems to me that the whole point of Open-Source vs. Not Invented Here is that
you are *supposed* to go out and make the effort necessary to learn new tools
that can then become extremely useful. If you accept the attitude of "it's not
Apache/mod-perl so I'm not using it," then it's time to stop all criticism of
those who use MySQL, Oracle, Windows, etc... Those people are *used* to their
technology, and the only reason they refuse to switch is that they don't want to
spend time learning something new.

You missed the point. It's called overkill. You needed a full blown
database for your project. We need (although _want_ may be another story)
a bug tracker - not a new webserver.

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

Tom -
Thanks for the review. Here's a new version of the patch, fixing the two
you objected to. Unfotunately, I seem to have found another corner case
in the existing code that needs fixing. Here's the one line version:

Use of an index in an ORDER BY DESC result changes placement of NULLs
(and NaNs, now) from last returned to first returned tuples

Long version:

While examining the output from ORDER BY queries, both using and not using
an index, I came across a discrepancy: the explicit handling of NULLs in
the tuplesort case always sorts NULLs to the end, regardless of direction
of sort. Intellectually, I kind of like that: "We don't know what these are,
let's just tack them on the end". I implemented NaN sorting to emulate that
behavior. This also has the pleasant property that NULL (or NaN) are never
returned as > or < any other possible value, should be expected.

However, if an index is involved, the index gets built, and the NULL
values are stored at one end of the index. So, when a ORDER BY DESC is
requested, the index is just read backwards, sending the NULLs (and NaNs)
first. (They're still not returned from a query with a clause such as
WHERE f1 > 0.)

An example of the output is attached, from the regress float8 table (with
a NULL and non-finites added. Don't need the non-finites to to display
the problem, though, since it's NULLs as well) Note the blank row,
which is the NULL, moves from the bottom to the top in the last case,
using the index.

So, what way should we go here? Make ASC/DESC actual mirrors of each other
in the direct sort case, as well? Hack the index scan to know about nodes
that always go to the end? Document it as a quirk? (Not likely: selection of
plan should never affect output.)

To make the direct sort the same as the index read would work for NULL,
but for NaN would either require allowing NaN to be returned as >
Infinity, which doesn't happen now, or add another ordering operator
that is only used for the sort case (use of '>' and '<' seems to be
hardcoded all the way to the parser)

Thoughts?

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, Aug 21, 2000 at 07:35:10AM -0700, Don Baccus wrote:

At 10:22 PM 8/20/00 -0400, Ned Lilly wrote:

If you all don't mind, I think it'd be great to keep this discussion on the
list. As some of you know, Great Bridge is working on its own project
hosting site (including a PG-backed bug tracking module). We're not quite
ready to pull back the curtain yet, but are getting close, and will be
actively soliciting input (and hacks) from the community.

Another implication which missed me first time 'round is that Great Bridge
might be planning to have its own bug reporting system, separate from
that used by the development community at large?

Cool your conspiracy theories. I'm not yet involved with either side
of this discussion, but before it runs out of control...

I hope not. There should be one central place for bug reporting. If
Great Bridge wants to run it, fine, also if Great Bridge wants to be able
to incorporate some sort of prioritization system for those with paid
support (or some other discriminatory system) it is still probably better
to figure out a way to accomodate it rather than have two separate
bug reporting systems.

The fact is that postgres already has a very good system for keeping
track of issues from report to fix to verification. So far the main defect
is the obvious one of "People don't know the history unless they troll the
message archives or lurk". Everyone here is leery of "fixing" a working
system. Especially when it entails modifying the working system to deal
with a new issue database.

Bug Database/Issue Trackers can be done in two ways.

Someone can grab an off-the-shelf system like Bugzilla or this ArsTechnica
thing and then try to make the project conform to it. So far, everyone
I've talked to who has touched Bugzilla has said that it sucks. I don't
know anything about this other proposed system but it will probably require
a lot of time to even get people to use it regularly, much less use it well.

The other method is to create the system to match the process in place.
Since the postgres project is already very well organized, I personally would
like to see the custom system, rather then make Bruce throw away his TODO
list and use someone else's idea of an issue tracking system. It takes a lot
more work--someone has to pay attention to what is going on with the project
and make sure the database stays in sync, but in the long run, it is less
disruptive and smoother to integrate into an already working project like
this one.

--
Adam Haberlach | "A farm tractor is not a motorcycle."
adam@newsnipple.com | --California DMV 1999
http://www.newsnipple.com/ | Motorcycle Driver Handbook

"Ross J. Reedstrom" <reedstrm@rice.edu> writes:

While examining the output from ORDER BY queries, both using and not using
an index, I came across a discrepancy: the explicit handling of NULLs in
the tuplesort case always sorts NULLs to the end, regardless of direction
of sort.

Yeah. I think that's widely considered a bug --- we have a TODO item to
fix it. You might care to dig in the archives for prior discussions.

To make the direct sort the same as the index read would work for NULL,
but for NaN would either require allowing NaN to be returned as >
Infinity, which doesn't happen now,

Seems to me the sort order should be

-Infinity
normal values
+Infinity
other types of NaN
NULL

and the reverse in a descending sort.

or add another ordering operator that is only used for the sort case
(use of '>' and '<' seems to be hardcoded all the way to the parser)

don't even think about that...

regards, tom lane

At 10:48 AM 8/21/00 -0400, Vince Vielhaber wrote:

Could it be possible that folks are shying away because of having
to install and learn an entire webserver and tools and then the
bug tracker on top of that?

Learning to use AOLserver is going to be harder than writing a
bugtracker and associated tools from scratch? I find that hard to
believe.

If it's true, of course they could run Apache, since arsDigita
provides a module which implements the AOLserver API in Apache
for exactly this reason, thus making it possible to run the
toolkit (including the SDM) under Apache.

- 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.

At 11:12 AM 8/21/00 -0400, Vince Vielhaber wrote:

I am *NOT* "the Postgres team". But have you listened to what you & Don
are suggesting that we, or for that matter anyone else in need of a bug
tracking system, do? You want us to install the full blown arsDigita with
all the bells and whistles just for a bug tracker. That's like saying I
need a pickup truck to move a chair so I'm going to go out and get a new
FreightLiner with a 55' trailer to do the job.

A rather dubious analogy.

It takes me less than half a day to install AOLserver, Postgres and the
toolkit on a virgin system, including setting up user accounts, etc.

And ... you never know. Other parts of the toolkit might turn out to be
useful.

If not, just leave them turned off. Take a look at openacs.org - do you
find any traces of the e-commerce module there? The intranet company
management module? What do you see? You see the use of perhaps 10% of
the toolkit.

This is slightly different than hauling an 18-wheeler around. Software
and trucks bear little resemblence to each other, though Freightliner does
have its home here in Portland, OR.

And, of course, the SDM has a bit more functionality than a simple bugtracker,
which is just one piece. It will be gaining more functionality over time,
including increased integration with CVS (there is already some integration,
i.e. the ability to browse the tree).

You missed the point. It's called overkill. You needed a full blown
database for your project. We need (although _want_ may be another story)
a bug tracker - not a new webserver.

Then run it under Apache.

- 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.

At 10:28 AM 8/21/00 -0700, Adam Haberlach wrote:

On Mon, Aug 21, 2000 at 07:35:10AM -0700, Don Baccus wrote:

Another implication which missed me first time 'round is that Great Bridge
might be planning to have its own bug reporting system, separate from
that used by the development community at large?

Cool your conspiracy theories.

I'm making an observation, that's all. Cool your own wild theories, please.

I hope not. There should be one central place for bug reporting. If
Great Bridge wants to run it, fine, also if Great Bridge wants to be able
to incorporate some sort of prioritization system for those with paid
support (or some other discriminatory system) it is still probably better
to figure out a way to accomodate it rather than have two separate
bug reporting systems.

The fact is that postgres already has a very good system for keeping
track of issues from report to fix to verification.

<shrug> I didn't raise the subject, it was a core developer who started
this thread with a semi-rant about it being about time that the project
had decent bug tracking software.

So apparently not everyone in the community agrees with your analysis. If
there were consensus that the current system's great then Great Bridge
wouldn't
be looking at implementing something different, and Peter wouldn't be ranting
that something better is needed.

So far the main defect
is the obvious one of "People don't know the history unless they troll the
message archives or lurk". Everyone here is leery of "fixing" a working
system.

There seems to be some disagreement about how well it works. Again, I didn't
raise the issue, I simply responded with a possible solution when one of the
core developers raised it. And I know that Great Bridge wants to do something
web-based - this isn't some fantasy I dreamed up when in a psychotic state.

I'm only saying that if a different approach is to be taken, why not build
on something that exists, is under active development, and is being driven
by folks who are VERY open to working with the project to make the tool
fit the project rather than vice-versa?

Someone can grab an off-the-shelf system like Bugzilla or this ArsTechnica

arsDigita

thing and then try to make the project conform to it.

Read above. Ben's already posted that he's eager for design input. aD has
already enhanced the thing based on their own needs, and there's no reason
why Great Bridge and the Postgres crew can't do the same.

I don't
know anything about this other proposed system but it will probably require
a lot of time to even get people to use it regularly, much less use it well.

Strange, OpenACS folk use it regularly and all we've done is put a "report
a bug" link on the home page.

I haven't heard so many arguments against change since the VT100 started
replacing the KSR 35!

- 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.

* Don Baccus <dhogaza@pacifier.com> [000821 11:48] wrote:

At 11:12 AM 8/21/00 -0400, Vince Vielhaber wrote:

You missed the point. It's called overkill. You needed a full blown
database for your project. We need (although _want_ may be another story)
a bug tracker - not a new webserver.

Then run it under Apache.

Sorry to jump in without reading the entire thread, but has GNATS
(what the FreeBSD team uses) or Bugzilla come up as options?

GNATS is a bit crusty but works pretty ok for us.

--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

On Mon, 21 Aug 2000, Don Baccus wrote:

At 10:48 AM 8/21/00 -0400, Vince Vielhaber wrote:

Could it be possible that folks are shying away because of having
to install and learn an entire webserver and tools and then the
bug tracker on top of that?

Learning to use AOLserver is going to be harder than writing a
bugtracker and associated tools from scratch? I find that hard to
believe.

Learning how to use it is only a tiny part of it. You still have to
migrate your website to it. It's not a drop in replacement. So
writing a bugtracker that will fit the environment vs learning a new
webserver & migrating your website & rebuilding or rewriting custom
apps ... For the average, busy admin, don't count too heavily on
the latter. They're more likely to stick with what they know and
trust regardless of how good something else is reported to be.

If it's true, of course they could run Apache, since arsDigita
provides a module which implements the AOLserver API in Apache
for exactly this reason, thus making it possible to run the
toolkit (including the SDM) under Apache.

First I heard of this, but I'd also have concerns of it's reliability.
It has to be real new. And if it fails it's not ars that looks bad,
it's the site that's running it. Remember the flack over udmsearch?
PostgreSQL was slammed over and over because udmsearch wasn't working
right.

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

On Mon, 21 Aug 2000, Don Baccus wrote:

At 11:12 AM 8/21/00 -0400, Vince Vielhaber wrote:

I am *NOT* "the Postgres team". But have you listened to what you & Don
are suggesting that we, or for that matter anyone else in need of a bug
tracking system, do? You want us to install the full blown arsDigita with
all the bells and whistles just for a bug tracker. That's like saying I
need a pickup truck to move a chair so I'm going to go out and get a new
FreightLiner with a 55' trailer to do the job.

A rather dubious analogy.

It takes me less than half a day to install AOLserver, Postgres and the
toolkit on a virgin system, including setting up user accounts, etc.

How familiar are you with it as opposed to most others on the net?

And ... you never know. Other parts of the toolkit might turn out to be
useful.

If not, just leave them turned off. Take a look at openacs.org - do you
find any traces of the e-commerce module there? The intranet company
management module? What do you see? You see the use of perhaps 10% of
the toolkit.

This is slightly different than hauling an 18-wheeler around. Software
and trucks bear little resemblence to each other, though Freightliner does
have its home here in Portland, OR.

You really don't get it do you? I'm not comparing software and trucks,
I'm comparing tools to do a job. Once you grasp that concept you'll be
able to catch on to what I'm talking about - until then I'm just wasting
my time.

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

At 02:54 PM 8/21/00 -0400, Vince Vielhaber wrote:

On Mon, 21 Aug 2000, Don Baccus wrote:

Learning to use AOLserver is going to be harder than writing a
bugtracker and associated tools from scratch? I find that hard to
believe.

Learning how to use it is only a tiny part of it. You still have to
migrate your website to it. It's not a drop in replacement. So
writing a bugtracker that will fit the environment vs learning a new
webserver & migrating your website & rebuilding or rewriting custom
apps ... For the average, busy admin, don't count too heavily on
the latter. They're more likely to stick with what they know and
trust regardless of how good something else is reported to be.

So run the development portion of the site on a different server. Who
said anything about migrating the entire postgres site to AOLserver???

If it's true, of course they could run Apache, since arsDigita
provides a module which implements the AOLserver API in Apache
for exactly this reason, thus making it possible to run the
toolkit (including the SDM) under Apache.

First I heard of this, but I'd also have concerns of it's reliability.
It has to be real new.

Yep. Written by Robert Thau, one of the original eight core Apache
developers, under contract to aD.

And if it fails it's not ars that looks bad,
it's the site that's running it.

arsDigita gets on average greater than $500,000 to develop and deploy
a website.

If aD deploys one on Apache+mod_aolserver (they paid for the development
of this module) and it falls over, do you really believe aD won't look
bad?

Seeing as they'd very likely be sued, I think you're wrong.

- 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.

At 02:58 PM 8/21/00 -0400, Vince Vielhaber wrote:

On Mon, 21 Aug 2000, Don Baccus wrote:

It takes me less than half a day to install AOLserver, Postgres and the
toolkit on a virgin system, including setting up user accounts, etc.

How familiar are you with it as opposed to most others on the net?

Ben has already offered to help out and has an account on hub. If I weren't
leaving town for five of the next six or so weeks, I would too.

Still, we have strangers to all three pieces installing everything in a
weekend, usually with a bit of help. If you were to install it, you'd
be familiar with Postgres which is about 1/3 of the confusion for newcomers.

You really don't get it do you?

Yes, I do.

I'm not comparing software and trucks,
I'm comparing tools to do a job. Once you grasp that concept you'll be
able to catch on to what I'm talking about - until then I'm just wasting
my time.

Do I detect a flame? Ohhh...

It's a toolkit, Vincent. Once you grasp the notion that using a wrench
out of your toolbox doesn't mean you have to use every tool in the
toolbox you'll be able to grasp what I'm talking about.

I answered your previous question plainly. If you're not capable of
understanding the answer, don't answer with an invitation for a flamefest
you have no chance of winning, 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.

On Mon, Aug 21, 2000 at 01:39:32PM -0400, Tom Lane wrote:

"Ross J. Reedstrom" <reedstrm@rice.edu> writes:

While examining the output from ORDER BY queries, both using and not using
an index, I came across a discrepancy: the explicit handling of NULLs in
the tuplesort case always sorts NULLs to the end, regardless of direction
of sort.

Yeah. I think that's widely considered a bug --- we have a TODO item to
fix it. You might care to dig in the archives for prior discussions.

I'll take a look.

To make the direct sort the same as the index read would work for NULL,
but for NaN would either require allowing NaN to be returned as >
Infinity, which doesn't happen now,

Seems to me the sort order should be

-Infinity
normal values
+Infinity
other types of NaN
NULL

and the reverse in a descending sort.

or add another ordering operator that is only used for the sort case
(use of '>' and '<' seems to be hardcoded all the way to the parser)

don't even think about that...

Sure, but any ideas _how_ to get 'NaN > +Infinity' to happen only during a
sort operation, and not when '>' is called explicity as a WHERE condition,
by touching only type specific code? 'Cause I'd call it a bug to be able
to say:

SELECT * from foo where f8 > 'Infinity';

and get anything at all back.

NULL is taken care of by special casing in the sort code, as I already mentioned,
and can be fixed immediately.

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

At 04:34 PM 8/21/00 -0300, The Hermit Hacker wrote:

Ummm, just stupid question here, but I already posted that AOLserver was
installed and ready for you guys to implement this ... Ben already has an
account to get in and do it ... instead of arguing about it, why not just
do it? If nobody likes it/uses it, so be it ... its no skin off my
back. But right now the arguments that are going back and forth seem to
be sooooooo useless since they *seem* to involve technical issues that
aren't issues ...

Well, this is a breath of fresh air ...

Hopefully Ben will have time soon to do so. Unfortunately (well, not from
my personal point of view!) I'm about to leave for five of the next six
weeks, four of those spent where the internet doesn't reach (where nothing
but BLM radio dispatch doesn't reach, to be more precise) so I'm not going
to be able to help.

Otherwise I'd just jump in.

Of course, putting it up will just make its shortcomings apparent, and
those who resist even the concept of change will ignore the fact that
Ben and I have both stated that modifying the SDM to fit the project
rather than modifying the project to fit the SDM and say, "see, this
doesn't fit our needs!" blah blah blah.

Just as the red herring you've mentioned has been raised.

- 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.

Well, just to throw another piece of information into the
mix, there is a new bug-tracking system under development by
the folks at collab.net. They call it "scarab", and last I
talked to them that they thought it would be ready for
production use Real Soon Now:

http://scarab.tigris.org/

I guess they regard this as a replacement for bugzilla.

Some personal opinions:

(1) I would actually like to see bugzilla fixed rather than
replaced. The collab.net guys are into java servlets
because they're CS geeks who are down on perl. Me, I'm a
perl loyalist who thinks that Larry Wall is onto something
-- mathematical elegance may not be the right standard to
judge a computer language.

(2) And maybe it'd be nice if the "religous wars" could be
dropped in favor of pure objective technical decision
making, but i don't think they can be: the social and the
technical don't neatly split into two little piles. (A case
in point: the argument that using a mailing list for bug
control is somehow "warmer" or "more human" than a bug
database.

[first off, I got rid of that awful cc: list..... ARggghhh....]
Don Baccus wrote:

At 04:34 PM 8/21/00 -0300, The Hermit Hacker wrote:

Ummm, just stupid question here, but I already posted that AOLserver was
installed and ready for you guys to implement this ... Ben already has an
account to get in and do it ... instead of arguing about it, why not just

Well, this is a breath of fresh air ...

Hopefully Ben will have time soon to do so. Unfortunately (well, not from

I'm available to help some, and also have a hub account (as well as an
operational AOLserver+PostgreSQL+OpenACS site to work on here....).

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Mon, 21 Aug 2000, Don Baccus wrote:

At 02:58 PM 8/21/00 -0400, Vince Vielhaber wrote:

On Mon, 21 Aug 2000, Don Baccus wrote:

It takes me less than half a day to install AOLserver, Postgres and the
toolkit on a virgin system, including setting up user accounts, etc.

How familiar are you with it as opposed to most others on the net?

Ben has already offered to help out and has an account on hub. If I weren't
leaving town for five of the next six or so weeks, I would too.

Still, we have strangers to all three pieces installing everything in a
weekend, usually with a bit of help. If you were to install it, you'd
be familiar with Postgres which is about 1/3 of the confusion for newcomers.

You really don't get it do you?

Yes, I do.

I'm not comparing software and trucks,
I'm comparing tools to do a job. Once you grasp that concept you'll be
able to catch on to what I'm talking about - until then I'm just wasting
my time.

Do I detect a flame? Ohhh...

It's a toolkit, Vincent. Once you grasp the notion that using a wrench
out of your toolbox doesn't mean you have to use every tool in the
toolbox you'll be able to grasp what I'm talking about.

Yet you insist on shoving the entire toolbox down our throats every time
there's a task to be done, Donnie.

I answered your previous question plainly. If you're not capable of
understanding the answer, don't answer with an invitation for a flamefest
you have no chance of winning, OK?

When the day comes that you actually answer a question without telling
the world that openacs, arsdigita, aolserver or whatever you want to call
it is the answer and saviour to everything from world peace to who cares
what else, I'll believe you answered a "question plainly". But that's
not likely to ever happen. And since you think that anything I've said
so far has been a flame I doubt you'd know one if it slapped you with a
trout.

One more thing, Donnie... ***PLONK***

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

On Mon, 21 Aug 2000, Don Baccus wrote:

At 04:34 PM 8/21/00 -0300, The Hermit Hacker wrote:

Ummm, just stupid question here, but I already posted that AOLserver was
installed and ready for you guys to implement this ... Ben already has an
account to get in and do it ... instead of arguing about it, why not just
do it? If nobody likes it/uses it, so be it ... its no skin off my
back. But right now the arguments that are going back and forth seem to
be sooooooo useless since they *seem* to involve technical issues that
aren't issues ...

Well, this is a breath of fresh air ...

Hopefully Ben will have time soon to do so. Unfortunately (well, not from
my personal point of view!) I'm about to leave for five of the next six
weeks, four of those spent where the internet doesn't reach (where nothing
but BLM radio dispatch doesn't reach, to be more precise) so I'm not going
to be able to help.

Otherwise I'd just jump in.

Of course, putting it up will just make its shortcomings apparent, and
those who resist even the concept of change will ignore the fact that
Ben and I have both stated that modifying the SDM to fit the project
rather than modifying the project to fit the SDM and say, "see, this
doesn't fit our needs!" blah blah blah.

Just as the red herring you've mentioned has been raised.

Right now, you've thrown out "it can do this, it can do that" ... I've
put forth the resources so that you can prove that it will work, its in
your court now :)

On Mon, 21 Aug 2000, Vince Vielhaber wrote:

On Mon, 21 Aug 2000, Don Baccus wrote:

At 10:48 AM 8/21/00 -0400, Vince Vielhaber wrote:

Could it be possible that folks are shying away because of having
to install and learn an entire webserver and tools and then the
bug tracker on top of that?

Learning to use AOLserver is going to be harder than writing a
bugtracker and associated tools from scratch? I find that hard to
believe.

Learning how to use it is only a tiny part of it. You still have to
migrate your website to it. It's not a drop in replacement. So
writing a bugtracker that will fit the environment vs learning a new
webserver & migrating your website & rebuilding or rewriting custom
apps ... For the average, busy admin, don't count too heavily on the
latter. They're more likely to stick with what they know and trust
regardless of how good something else is reported to be.

why not just run aolserver on a different port like we do?

At 7:48 PM -0300 8/20/00, The Hermit Hacker wrote:

what's wrong wth "Post-Gres-QL"?

I find it soooo simple to pronounce *shrug*

On Sun, 20 Aug 2000, David Lloyd-Jones wrote:

I'm putting on my suits-type suit for just a moment.

In order to Conquer The Universe(tm) why don't we just call it "PG"?

IMNSHO the "QL" are silent and you pronounce it Postgres. I consider
the SQL query language to be merely a (major) feature added during
the evolution of the system.

Signature held pending an ISO 9000 compliant
signature design and approval process.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

On Mon, 21 Aug 2000, The Hermit Hacker wrote:

On Mon, 21 Aug 2000, Vince Vielhaber wrote:

On Mon, 21 Aug 2000, Don Baccus wrote:

At 10:48 AM 8/21/00 -0400, Vince Vielhaber wrote:

Could it be possible that folks are shying away because of having
to install and learn an entire webserver and tools and then the
bug tracker on top of that?

Learning to use AOLserver is going to be harder than writing a
bugtracker and associated tools from scratch? I find that hard to
believe.

Learning how to use it is only a tiny part of it. You still have to
migrate your website to it. It's not a drop in replacement. So
writing a bugtracker that will fit the environment vs learning a new
webserver & migrating your website & rebuilding or rewriting custom
apps ... For the average, busy admin, don't count too heavily on the
latter. They're more likely to stick with what they know and trust
regardless of how good something else is reported to be.

why not just run aolserver on a different port like we do?

If it has the functionality you desire and are looking for, sure. My
contention is that the average site isn't going to do it for a couple
of features and would roll their own instead.

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

On Mon, 21 Aug 2000, Jan Wieck wrote:

The Hermit Hacker wrote:

what's wrong wth "Post-Gres-QL"?

I find it soooo simple to pronounce *shrug*

Mee too. And I'm not sure if anybody pronounces PG the same
way. Is it PeeGee or PiG (in which case we'd have the wrong
animal in our logo).

Actually, the one that gets me is those that refer to it as Postgres
... postgres was a project out of Berkeley way back in the 80's, early
90's ... hell, it was based on a PostQuel language ... this ain't
postgres, its only based on it :(

Jan

On Sun, 20 Aug 2000, David Lloyd-Jones wrote:

I'm putting on my suits-type suit for just a moment.

In order to Conquer The Universe(tm) why don't we just call it "PG"?

-dlj.

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

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

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

On Mon, 21 Aug 2000, Henry B. Hotz wrote:

At 7:48 PM -0300 8/20/00, The Hermit Hacker wrote:

what's wrong wth "Post-Gres-QL"?

I find it soooo simple to pronounce *shrug*

On Sun, 20 Aug 2000, David Lloyd-Jones wrote:

I'm putting on my suits-type suit for just a moment.

In order to Conquer The Universe(tm) why don't we just call it "PG"?

IMNSHO the "QL" are silent and you pronounce it Postgres. I consider
the SQL query language to be merely a (major) feature added during
the evolution of the system.

as stated in another email, it is not pronounced Postgres ... postgres was
a whole different beast based on a completely different query language
... if you refer to Postgres, you are, IMHO, refering to the only
Postgres 4.2 which was the grand-daddy to what its evolved into ...

[trimmed cc: list]

Vince Vielhaber wrote:

On Mon, 21 Aug 2000, Don Baccus wrote:

Vince wrote:

You really don't get it do you?

Yes, I do.

Vince, Don really does 'get it' -- he's just pretty vehement about his
'getting it'.

It's a toolkit, Vincent. Once you grasp the notion that using a wrench
out of your toolbox doesn't mean you have to use every tool in the
toolbox you'll be able to grasp what I'm talking about.

Yet you insist on shoving the entire toolbox down our throats every time
there's a task to be done, Donnie.

One of the many useful features of OpenACS is that you get the whole
toolbox -- a toolbox, as opposed to a 'box of tools' -- Jensen makes a
nice profit selling toolboxes with matched tools -- neat, clean, trim,
and don't look anything like my four-drawer toolbox made up of a melange
of tools and a Wal-mart toolbox.

OpenACS is like the Jensen toolset -- you get a matched case, and
high-quality tools matches to the case. With OpenACS you get a
framework that tools can be plugged into -- tools that were designed to
be plugged in that way (well, it's not perfect -- but nothing is).
Everything can be covered by the system-wide authentication module, user
group module, etc. Everything is designed to work smoothly together.
so you only use authentication+SDM -- so what. You can expand as you
need to -- and it doesn't take up _that_ much space.

PostgreSQL is much like OpenACS (barring the funny capitalization, but I
digress): PostgreSQL is a toolbox of database routines and modules, tied
together by a SQL parser and a large set of clients with matching
arbiter/backends. Download postgresql-version.tar.gz, and you _have_ to
get the C++ code -- even if you don't want it. You have to get pgaccess
-- even if you won't use it. If you want to do meaningful development,
you have to keep nearly the whole source tree around......etc. How is
this different from the OpenACS model? Don't want a part of OpenACS?
Nobody is preventing you from nuking that part from your installation
tree -- just like no one is preventing someone from installing
PostgreSQL in a client-only sort of way (much easier with an RPMset, but
I again digress.....).

PostgreSQL requires libpq -- OpenACS requires (but doesn't include)
AOLserver -- that analogy is not perfect, but close.

And, OpenACS can run just fine under Apache with mod_aolserver.
Although, since Marc has an AOLserver available and running.... :-) and
a killer db server (bigger :-))...

Vince, Don: sparring like this is not productive. Both of you are
excellent hackers -- I've seen both of your code. Let's just make it
work, and see what the hackers think of it.

I answered your previous question plainly. If you're not capable of
understanding the answer, don't answer with an invitation for a flamefest
you have no chance of winning, OK?

Flamefests are unwinnable. All parties to flamwars get burned -- either
directly, or indirectly. I have seen too many flamewars -- and it's not
worth the risk to reputation to go too far with one. This one is mild
so far -- on a scale from one to ten, this makes it to one-and-a-half
thus far (I've been on news.groups and news.admin (and cross-posted to
alt.flame) more than once several years back....).

When the day comes that you actually answer a question without telling
the world that openacs, arsdigita, aolserver or whatever you want to call
it is the answer and saviour to everything from world peace to who cares

Vince, try it. You might like it. But, it does require some different
thinking -- which if you don't have time to do, your loss. Or, to put
it differently -- I just recently learned how to write CGI scripts.
That may seem laughable -- but I had already written many dynamic web
pages using AOLserver TCL -- who needs CGI? The current rush on PHP
programmers shows this -- many PHP programmers wouldn't have a clue how
to go about writing a CGI script -- and, guess what -- with PHP you
don't need CGI. The AOLserver TCL API is like PHP on steroids in many
case -- and, in many other cases, PHP out-API's AOLserver.

And I do remember that you _have_ tried AOLserver, about a year ago....

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Mon, 21 Aug 2000, Vince Vielhaber wrote:

why not just run aolserver on a different port like we do?

If it has the functionality you desire and are looking for, sure. My
contention is that the average site isn't going to do it for a couple
of features and would roll their own instead.

Sounds like a big waste of time investment when few of us have much of it
to start with ...

I've talked to Ben and he's going to work on getting the OpenACS version
up and running ... once he has that going, he's going to talk to you
(Vince) about getting the look to match what our web site looks like
... once we have that in place, the next step will be to customize it so
that it does what *we* want it to do ...

[cc: list trimmed]

Vince Vielhaber wrote:

On Mon, 21 Aug 2000, The Hermit Hacker wrote:

why not just run aolserver on a different port like we do?

If it has the functionality you desire and are looking for, sure. My
contention is that the average site isn't going to do it for a couple
of features and would roll their own instead.

Isn't this the biggest reason people give for using MySQL and not
PostgreSQL???? (re: transaction support, triggers, etc).

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

The Hermit Hacker wrote:

what's wrong wth "Post-Gres-QL"?

I find it soooo simple to pronounce *shrug*

Mee too. And I'm not sure if anybody pronounces PG the same
way. Is it PeeGee or PiG (in which case we'd have the wrong
animal in our logo).

Jan

On Sun, 20 Aug 2000, David Lloyd-Jones wrote:

I'm putting on my suits-type suit for just a moment.

In order to Conquer The Universe(tm) why don't we just call it "PG"?

-dlj.

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

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

On Mon, 21 Aug 2000, The Hermit Hacker wrote:

On Mon, 21 Aug 2000, Vince Vielhaber wrote:

why not just run aolserver on a different port like we do?

If it has the functionality you desire and are looking for, sure. My
contention is that the average site isn't going to do it for a couple
of features and would roll their own instead.

Sounds like a big waste of time investment when few of us have much of it
to start with ...

I've talked to Ben and he's going to work on getting the OpenACS version
up and running ... once he has that going, he's going to talk to you
(Vince) about getting the look to match what our web site looks like
... once we have that in place, the next step will be to customize it so
that it does what *we* want it to do ...

Who is going to customize it?

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

On Mon, 21 Aug 2000, Vince Vielhaber wrote:

On Mon, 21 Aug 2000, The Hermit Hacker wrote:

On Mon, 21 Aug 2000, Vince Vielhaber wrote:

why not just run aolserver on a different port like we do?

If it has the functionality you desire and are looking for, sure. My
contention is that the average site isn't going to do it for a couple
of features and would roll their own instead.

Sounds like a big waste of time investment when few of us have much of it
to start with ...

I've talked to Ben and he's going to work on getting the OpenACS version
up and running ... once he has that going, he's going to talk to you
(Vince) about getting the look to match what our web site looks like
... once we have that in place, the next step will be to customize it so
that it does what *we* want it to do ...

Who is going to customize it?

He will

"Ross J. Reedstrom" <reedstrm@rice.edu> writes:

or add another ordering operator that is only used for the sort case
(use of '>' and '<' seems to be hardcoded all the way to the parser)

don't even think about that...

Sure, but any ideas _how_ to get 'NaN > +Infinity' to happen only during a
sort operation, and not when '>' is called explicity as a WHERE condition,
by touching only type specific code?

That's exactly what you shouldn't even think about. The entire index
and sorting system is predicated on the assumption that '<' and related
operators agree with the order induced by a btree index. You do not get
to make the operators behave differently in the free-standing case than
when they are used with an index.

'Cause I'd call it a bug to be able to say:
SELECT * from foo where f8 > 'Infinity';
and get anything at all back.

I agree it's pretty arbitrary to define NaN as > Infinity, but the sort
ordering is necessarily arbitrary. We can special-case NULL because
that's a type-independent concept, but special-casing NaN is out of the
question IMHO. Pick where you want it in the type-specific order, and
live with it.

regards, tom lane

On Mon, 21 Aug 2000, The Hermit Hacker wrote:

On Mon, 21 Aug 2000, Vince Vielhaber wrote:

On Mon, 21 Aug 2000, The Hermit Hacker wrote:

On Mon, 21 Aug 2000, Vince Vielhaber wrote:

why not just run aolserver on a different port like we do?

If it has the functionality you desire and are looking for, sure. My
contention is that the average site isn't going to do it for a couple
of features and would roll their own instead.

Sounds like a big waste of time investment when few of us have much of it
to start with ...

I've talked to Ben and he's going to work on getting the OpenACS version
up and running ... once he has that going, he's going to talk to you
(Vince) about getting the look to match what our web site looks like
... once we have that in place, the next step will be to customize it so
that it does what *we* want it to do ...

Who is going to customize it?

He will

works for me.

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

On Mon, Aug 21, 2000 at 02:32:08PM -0500, Ross J. Reedstrom wrote:

On Mon, Aug 21, 2000 at 01:39:32PM -0400, Tom Lane wrote:

Seems to me the sort order should be

-Infinity
normal values
+Infinity
other types of NaN
NULL

and the reverse in a descending sort.

NULL is taken care of by special casing in the sort code, as I already mentioned,
and can be fixed immediately.

Grr, I take this back. By the time comparetup_* see the tuples, we've no idea
which order we're sorting in, just a pointer to the appropriate sortop.

<whine mode>
Why does every thing I touch in pgsql end up pulling in down into the
guts of the whole system? Even something that looks nicely factored
at first, like the type system? I guess this stuff is _hard_.
</whine mode>

Sigh, back to fixing up referential integrity violations in the DB
I'm finally upgrading from 6.5 to 7.0.X. (DBA life lesson number XX:
implementing RI in the backend _from the very start of a project_ is a
very good thing. Cleansing the data of cruft left from _not_ having RI in
the backend, is a bad thing. And those clever, recursive self-referencing
table structures for representing trees are a pain in the DBA to reload.)

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

At 5:16 PM -0300 8/21/00, The Hermit Hacker wrote:

On Mon, 21 Aug 2000, Henry B. Hotz wrote:

At 7:48 PM -0300 8/20/00, The Hermit Hacker wrote:

what's wrong wth "Post-Gres-QL"?

I find it soooo simple to pronounce *shrug*

On Sun, 20 Aug 2000, David Lloyd-Jones wrote:

I'm putting on my suits-type suit for just a moment.

In order to Conquer The Universe(tm) why don't we just call it "PG"?

IMNSHO the "QL" are silent and you pronounce it Postgres. I consider
the SQL query language to be merely a (major) feature added during
the evolution of the system.

as stated in another email, it is not pronounced Postgres ... postgres was
a whole different beast based on a completely different query language
... if you refer to Postgres, you are, IMHO, refering to the only
Postgres 4.2 which was the grand-daddy to what its evolved into ...

;-)

Signature held pending an ISO 9000 compliant
signature design and approval process.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

Hi Joe,

We're looking at elements of the Tigris architecture for the site
that I referenced in an earlier email (so Don, we're not reinventing
the wheel). Scarab has apparently been in development for awhile
now - the Tigris project is currently using Bugzilla until Scarab
itself is ready for prime time, then they intend to switch it over.

We've also spent some time looking at an app called BugRat (even
ported it to Postgres from MySQL)... it seems to offer a pretty good
mix of features as well.

The greatbridge.org site will likely get started with either BugRat
or Bugzilla, then transitition to Scarab when/if it's ready. BTW,
the goal of the site (which I didn't really explain too well in my
earlier message) will be to provide a hosting infrastructure for
some related projects (like interfaces, or the apps and tools we're
listing at http://www.greatbridge.com/tools/toollist.php)... also,
all the software we develop internally will go up on that site.

So please don't interpret our interest as getting in the middle of
what the main Postgres project uses for bug tracking - although the
requirements outlined in the earlier messages was helpful just for
our own development of the greatbridge.org site. If Ben and the
OpenACS gang are willing to put the time into a bug tracker for the
project, I think that couldn't help but be a good thing.

Regards,
Ned

Joe Brenner wrote:

At 1:25 AM -0400 8/21/00, Tom Lane wrote:

"Ross J. Reedstrom" <reedstrm@rice.edu> writes:

! if (isnan(a))
! PG_RETURN_INT32(1);

Do not like this at all --- doesn't it make the result of btint4cmp(NaN,
NaN) dependent on which argument chances to be first? Seems to me that
you must consider two NaNs to be equal, unless you want to subdivide
the category of NaNs.

I'm pretty sure IEEE 754 says that NaN does not compare equal to
anything, including themselves. I also believe that Infinity isn't
equal to itself either, it's just bigger than anything else except
NaN (which isn't littler either).

Without having seen the start of this thread I think the biggest
problem is that some of the results of compares depend on the mode
that the FP hardware is put in. IEEE specifies some modes, but not
how you set the mode you want on the system you are actually running
on. For example I think comparing zero and -Infinity may return
three possible results: 0 > -Infinity, 0 < -Infinity (because it was
told to ignore the sign of Infinity), or an illegal value exception.
Likewise signalling/non-signalling NaN's act different depending on
mode settings.

We need to first figure out what floating point behavior we want to
support. Then we figure what mode settings provide that behavior
with a minimum of overhead. Then we need to figure out how to set
those modes on all the platforms we support. We will probably
discover that not all required modes actually exist on all hardware
platforms. I know that 68000 and SPARC are pretty good, but PowerPC
punted some stuff to exception handlers which may not be correct on
all OS's. I've heard that Java has some portability issues because
Intel fudged some stuff in the newer hardware.

Does anyone feel like tracing down how to set the modes for all the
different systems that we try to run on? If there is interest then I
might poke at a couple/three NetBSD ports and Solaris/SPARC. But
only if there is interest.

Sun has put some code out under GPL which will let you test for these
special values and handle them, but that seems like a big hit for
what should be a simple compare. I assume that we can't put GPL code
into the main sources any more than the *BSD's do. Perhaps we could
get away with it if it is only included if configure can't figure out
how to set the modes properly?

Signature held pending an ISO 9000 compliant
signature design and approval process.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

On Mon, Aug 21, 2000 at 04:37:21PM -0400, Tom Lane wrote:

"Ross J. Reedstrom" <reedstrm@rice.edu> writes:

or add another ordering operator that is only used for the sort case
(use of '>' and '<' seems to be hardcoded all the way to the parser)

don't even think about that...

Sure, but any ideas _how_ to get 'NaN > +Infinity' to happen only during a
sort operation, and not when '>' is called explicity as a WHERE condition,
by touching only type specific code?

That's exactly what you shouldn't even think about. The entire index
and sorting system is predicated on the assumption that '<' and related
operators agree with the order induced by a btree index. You do not get
to make the operators behave differently in the free-standing case than
when they are used with an index.

Oh really? Then why do btree's have their own comparator functions,
seperate from heap sorts, and datum sorts, and explicit use of '<' ? The
current code infrastructure allows for the possibility that these may need
to diverge, requiring the coders to keep them in sync. Annoying, that, but
useful for edge cases.

Since btree already uses it's own comparator, The only reason I can
see that the parser drops in '<' and '>' as the name of the sorting
operator to use for ORDER BY is convenience: the functions are there,
and have the (mostly) correct behavior.

Changing this would only require writing another set of operators for
the parser to drop in, that are used only for sorting, so that the
sort behavior could diverge slightly, by knowing how to sort NULLs and
NaNs. Yes, it'd be a third set of operators to keep in sync with the
btree and default ones, but it could give completely correct behavior.

Hmm, I another thought: all the comparator code assumes (a<b || a>b || a==c)
and therefor only test 2 of the three conditions, falling through to the
third. In the three places I just looked, two fall thorough to the equal case,
and one to the 'less than' case. If all three fell through to the 'greater than'
case, it might work with no tweaking at all. I'll have to try that, first.

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, Aug 21, 2000 at 05:30:21PM -0500, Ross J. Reedstrom wrote:

Hmm, I another thought: all the comparator code assumes (a<b || a>b || a==c)
and therefor only test 2 of the three conditions, falling through to the
third. In the three places I just looked, two fall thorough to the equal case,
and one to the 'less than' case. If all three fell through to the 'greater than'
case, it might work with no tweaking at all. I'll have to try that, first.

Looking again, I realize that the sort comparetup_* code doesn't have
access to a operator to test for equality, so can't do this. Sigh. Time
to go home, I think.

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

"Ross J. Reedstrom" <reedstrm@rice.edu> writes:

On Mon, Aug 21, 2000 at 04:37:21PM -0400, Tom Lane wrote:

That's exactly what you shouldn't even think about. The entire index
and sorting system is predicated on the assumption that '<' and related
operators agree with the order induced by a btree index. You do not get
to make the operators behave differently in the free-standing case than
when they are used with an index.

Oh really? Then why do btree's have their own comparator functions,
seperate from heap sorts, and datum sorts, and explicit use of '<' ?

Strictly and only to save a few function-call cycles. Some paths in the
btree code need a three-way comparison (is A<B, or A=B, or A>B?) and
about half the time you'd need two calls to type-specific comparator
functions to make that determination if you only had the user-level
operators available. This does *not* mean that you have license to make
the 3-way comparator's behavior differ from the operators, because the
operators are used too. Note also that it is a three-way comparison
function, not four-way: there is no provision for answering "none of the
above" (except when a NULL is involved, and that only works because it's
special-cased without calling type-specific code at all).

The reason the sort code doesn't use the comparator routine is strictly
historical, AFAICT. It really should, for speed reasons; but there may
not be a 3-way comparator associated with a given '<' operator, and
we've got a longstanding convention that a user-selected sort order is
specified by naming a particular '<'-like operator. It may also be
worth pointing out that the sort code still assumes trichotomy: it
tests A<B, and if that is false it tries B<A, and if that's also false
then it assumes A=B. There's still no room for an "unordered" response.

The current code infrastructure allows for the possibility that these
may need to diverge, requiring the coders to keep them in
sync. Annoying, that, but useful for edge cases.

It is annoying. Many of the datatypes where comparison is nontrivial
actually use an underlying 3-way comparison routine that the boolean
comparators call, so as to avoid code-divergence problems.

Changing this would only require writing another set of operators for
the parser to drop in, that are used only for sorting,

No, because *the user-level operators must match the index*. How many
times do I have to repeat that? The transformation that allows, say,
SELECT * FROM tab WHERE foo > 33 AND foo < 42
to be implemented by an indexscan (of an index on foo) is fundamentally
dependent on the assumption that the operators '>' and '<' induce the
same ordering of data values as is stored in the index. Otherwise you
can't scan a subrange of the index and know that you've hit all the
matching rows. The planner actually takes considerable care to verify
that the operators appearing in WHERE *do* match the index ordering ---
that's what pg_opclass and pg_amop are all about. If you invent an
internal set of operators that provide a different index ordering,
you will find that the planner ignores your index.

regards, tom lane

On Mon, Aug 21, 2000 at 11:34:45AM -0700, Don Baccus wrote:

Strange, OpenACS folk use it regularly and all we've done is put a "report
a bug" link on the home page.

...I'm not sure you noticed, but this project isn't OpenACS. It is
an established project with decent management that only needs a few features.
Switching everything over to a canned solution, no matter how good of a
toolbox you feel it is, is not necessarily going to solve the few problems
we have without causing a whole host of new ones...

I haven't heard so many arguments against change since the VT100 started
replacing the KSR 35!

Oh, and in case you didn't hear it earlier... PLONK.

--
Adam Haberlach | "A farm tractor is not a motorcycle."
adam@newsnipple.com | --California DMV 1999
http://www.newsnipple.com/ | Motorcycle Driver Handbook

On Mon, 21 Aug 2000, Adam Haberlach wrote:

On Mon, Aug 21, 2000 at 11:34:45AM -0700, Don Baccus wrote:

Strange, OpenACS folk use it regularly and all we've done is put a "report
a bug" link on the home page.

...I'm not sure you noticed, but this project isn't OpenACS. It is
an established project with decent management that only needs a few features.
Switching everything over to a canned solution, no matter how good of a
toolbox you feel it is, is not necessarily going to solve the few problems
we have without causing a whole host of new ones...

Ummmm, who was talking about switching anything over to a canned
solution? *raised eyebrow* we are talking about allowing the OpenACS
folks setup a bug tracking system for us and seeing if it servces us
better then other attempts have in the past ...

At 09:40 PM 8/21/00 -0300, The Hermit Hacker wrote:

On Mon, 21 Aug 2000, Adam Haberlach wrote:

On Mon, Aug 21, 2000 at 11:34:45AM -0700, Don Baccus wrote:

Strange, OpenACS folk use it regularly and all we've done is put a

"report

a bug" link on the home page.

...I'm not sure you noticed, but this project isn't OpenACS. It is
an established project with decent management that only needs a few

features.

Switching everything over to a canned solution, no matter how good of a
toolbox you feel it is, is not necessarily going to solve the few problems
we have without causing a whole host of new ones...

Ummmm, who was talking about switching anything over to a canned
solution? *raised eyebrow* we are talking about allowing the OpenACS
folks setup a bug tracking system for us and seeing if it servces us
better then other attempts have in the past ...

Which it probably won't - customization is the key, we're not quite as
stupid as Adam makes us out to be.

Here's an idea:

How about ignoring whether or not a new solution is borne, or the SDM
can be customized to fit your needs with less work than, and concentrating
on what features you want to see?

Has anyone thought about this, or was the last attempt such a failure that
people have given it no further thought?

- 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.

The Hermit Hacker <scrappy@hub.org> wrote:

On Mon, 21 Aug 2000, Jan Wieck wrote:

The Hermit Hacker wrote:

what's wrong wth "Post-Gres-QL"?

I find it soooo simple to pronounce *shrug*

Mee too. And I'm not sure if anybody pronounces PG the same
way. Is it PeeGee or PiG (in which case we'd have the wrong
animal in our logo).

Actually, the one that gets me is those that refer to it as Postgres
... postgres was a project out of Berkeley way back in the 80's, early
90's ... hell, it was based on a PostQuel language ... this ain't
postgres, its only based on it :(

Personally, I say P-G-Sequel or Post-Grease-S-Q-L.

And I have to say that "postgresql" has one of the worst
names of any software I've ever encountered. I'm entirely
in sympathy with the "suit" who suggested calling it "PG".

I would go further and say that in the near future when some
milestone is reached (say, the addition of outer joins?) it
might be a good idea to mark the occasion with a name change
of some sort.

I cringe at the thought of the hassles involved with
choosing a new name though.

Openbase? Freebase? ACIDtrip?

I think I like "Grease".

On Mon, 21 Aug 2000, Joe Brenner wrote:

The Hermit Hacker <scrappy@hub.org> wrote:

On Mon, 21 Aug 2000, Jan Wieck wrote:

The Hermit Hacker wrote:

what's wrong wth "Post-Gres-QL"?

I find it soooo simple to pronounce *shrug*

Mee too. And I'm not sure if anybody pronounces PG the same
way. Is it PeeGee or PiG (in which case we'd have the wrong
animal in our logo).

Actually, the one that gets me is those that refer to it as Postgres
... postgres was a project out of Berkeley way back in the 80's, early
90's ... hell, it was based on a PostQuel language ... this ain't
postgres, its only based on it :(

Personally, I say P-G-Sequel or Post-Grease-S-Q-L.

And I have to say that "postgresql" has one of the worst
names of any software I've ever encountered. I'm entirely
in sympathy with the "suit" who suggested calling it "PG".

I would go further and say that in the near future when some milestone
is reached (say, the addition of outer joins?) it might be a good idea
to mark the occasion with a name change of some sort.

I don't think so ... we changed the name 4+ years ago, and, quite frankly,
have worked for 4+ years at building an identity around that ... ppl know
what PostgreSQL is, and what it represents ... could you imagine someone
changing Apache, or Linux, or Oracle? I really don't see what is so hard
about pronouncing Post-Gres-QL ... *shrug*

Don Baccus wrote:

How about ignoring whether or not a new solution is borne, or the SDM
can be customized to fit your needs with less work than, and concentrating
on what features you want to see?

Has anyone thought about this, or was the last attempt such a failure that
people have given it no further thought?

I don't know what the major code contributors need beyond the
TODO list. But I remember what went wrong with the older system
-- people would post non-bug issues, and in large numbers, as
bugs. And the system would "pend" those non-issues, assigning
them to core developers, who, at the time, were very busy
implementing MVCC and crushing real bugs by the hundreds. It
seems all Peter wants is a system whereby authorized users
(presumably those with CVS privileges) would have the ability to
post and close bugs. Perhaps such a system might have prevented
the duplicate work done recently on the "binary compatibility WRT
functional indexes" issue. Just from lurking, I think the core
developers' consensus was that anything which allows Joe User to
open tickets, without a "front-line" of advanced users/minor code
contributors willing to act as filters, would consume too much
time. People with great frequency ignore the note on the web-site
which reads "Note: You must post elsewhere first" with respect to
the pgsql-hackers list.

So I don't think it was an issue with the technology, but the
process. Although, from what I've read, I suspect ArsDigita is
light-years ahead of the Keystone software that was the
"PostgreSQL Bug Tracking System".

P.S.: I've been looking forward to seeing ArsDigita running on
postgresql.org for some time. I suspect there would be some
short-term pain, but substantial long-term gain. :-)

Mike Mascari

The Hermit Hacker <scrappy@hub.org> writes:

I don't think so ... we changed the name 4+ years ago, and, quite frankly,
have worked for 4+ years at building an identity around that ... ppl know
what PostgreSQL is, and what it represents ... could you imagine someone
changing Apache, or Linux, or Oracle? I really don't see what is so hard
about pronouncing Post-Gres-QL ... *shrug*

The name is certainly ugly, but it's got history behind it: it gives
appropriate credit to those who went before us. (Don't forget that
the roots of this project go back twenty-odd years.) There's unlikely
to be much support around here for changing the name, no matter what
alternative is offered.

FWIW, I say "post-gres-cue-ell", same as Marc.

regards, tom lane

On Mon, 21 Aug 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

I don't think so ... we changed the name 4+ years ago, and, quite frankly,
have worked for 4+ years at building an identity around that ... ppl know
what PostgreSQL is, and what it represents ... could you imagine someone
changing Apache, or Linux, or Oracle? I really don't see what is so hard
about pronouncing Post-Gres-QL ... *shrug*

The name is certainly ugly, but it's got history behind it: it gives
appropriate credit to those who went before us. (Don't forget that
the roots of this project go back twenty-odd years.) There's unlikely
to be much support around here for changing the name, no matter what
alternative is offered.

FWIW, I say "post-gres-cue-ell", same as Marc.

I think we need to get this put up on the main page in big bold letters as
one of those "dictionary pronounciation" sort of things so that it the
first thing that ppl learn when they hit our site :)

On Tue, 22 Aug 2000, The Hermit Hacker wrote:

On Mon, 21 Aug 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

I don't think so ... we changed the name 4+ years ago, and, quite frankly,
have worked for 4+ years at building an identity around that ... ppl know
what PostgreSQL is, and what it represents ... could you imagine someone
changing Apache, or Linux, or Oracle? I really don't see what is so hard
about pronouncing Post-Gres-QL ... *shrug*

The name is certainly ugly, but it's got history behind it: it gives
appropriate credit to those who went before us. (Don't forget that
the roots of this project go back twenty-odd years.) There's unlikely
to be much support around here for changing the name, no matter what
alternative is offered.

FWIW, I say "post-gres-cue-ell", same as Marc.

I think we need to get this put up on the main page in big bold letters as
one of those "dictionary pronounciation" sort of things so that it the
first thing that ppl learn when they hit our site :)

Or an embedded audio file? :)

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

The Hermit Hacker <scrappy@hub.org> writes:

Actually, the one that gets me is those that refer to it as Postgres
... postgres was a project out of Berkeley way back in the 80's, early
90's ... hell, it was based on a PostQuel language ... this ain't
postgres, its only based on it :(

Yes, and besides, if you call it Postgres, you are certain to offend the
struggling Postgres community. Those PostQuel language zealots have enough
problems keeping their technology alive as it is without people going around
creating gratuitous brand confusion.

-Michael Robinson

On Tue, Aug 22, 2000 at 02:16:44PM +0200, Peter Eisentraut wrote:

Ross J. Reedstrom writes:

Fixing sorts is a bit tricker, but can be done: Currently, I've hacked
the float8lt and float8gt code to sort NaN to after +/-Infinity. (since
NULLs are special cased, they end up sorting after NaN). I don't see
any problems with this solution, and it give the desired behavior.

SQL 99, part 5, section 17.2 specifies that the sort order for ASC and
DESC is defined in terms of the particular type's < and > operators.
Therefore the NaN's must always be at the end. (Before or after NULL is
implementation-defined, btw.)

I'm not sure what your suggesting, Peter. Which is 'the end'? And how does
'Therefore' follow from considering the type behavior of NaN and the < and

operators ?

I think your suggesting that NaN always sort to one end, either greater
than Infinity or less than -Infinity, regardless of sort direction.
Therefore, depending on the direction of ORDER BY, NaNs will be returned
either be first or last, not always last, as I've currently implemented.

I agree with this, but my reason comes from the required treatment of NULLs.

My reasoning is as follows:

The standard says (17.2):

The relative position of rows X and Y in the result is determined by
comparing XV(i) and YV(i) according to the rules of Subclause 8.2,
"<comparison predicate>", in ISO/IEC 9075-2, where the <comp op>
is the applicable <comp op> for K(i), [...]

and Subclause 8.2 says:

2) Numbers are compared with respect to their algebraic value.

However, NaN is _not_ algebraically > or < any other number: in fact,
General Rule 1. of subclause 8.2 does deal with this:

5) X <comp op> Y is_unknown if X <comp op> Y is neither
true_ nor false_ .

So, we're left with not knowing where to put NaN.

However, the only other case where the comparision is unknown is:

a) If either XV or YV is the null value, then
X <comp op> Y is unknown_ .

And, going back to section 17.2:

[...] where the <comp op> is the applicable <comp op> for K(i),
with the following special treatment of null values. Whether a
sort key value that is null is considered greater or less than a
non-null value is implementation-defined, but all sort key values
that are null shall either be considered greater than all non-null
values or be considered less than all non-null values.

So, NULLs go at one end (less or greater), always, so NaN should as well.
And NULL will go outside them, since NULLs are required to be considered
greater than (in our case) all non-null values (including NaN).

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

The Hermit Hacker wrote:

On Mon, 21 Aug 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

I don't think so ... we changed the name 4+ years ago, and, quite frankly,
have worked for 4+ years at building an identity around that ... ppl know
what PostgreSQL is, and what it represents ... could you imagine someone
changing Apache, or Linux, or Oracle? I really don't see what is so hard
about pronouncing Post-Gres-QL ... *shrug*

The name is certainly ugly, but it's got history behind it: it gives
appropriate credit to those who went before us. (Don't forget that
the roots of this project go back twenty-odd years.) There's unlikely
to be much support around here for changing the name, no matter what
alternative is offered.

FWIW, I say "post-gres-cue-ell", same as Marc.

I think we need to get this put up on the main page in big bold letters as
one of those "dictionary pronounciation" sort of things so that it the
first thing that ppl learn when they hit our site :)

We in spanish speaking areas, are clueless most of the times when pronouncing
english names when speaking to non-english speakers, or when mixing english
words with spanish words. As to PostgreSQL, I pronounce it (in spanish)
"postgres" "s" "q" "l" inevitably doubling the "s", and hardly saying the "t".
Alternatively, I'd just say "postgres" as most of the people hasn't ever heard
about Berkeley's ages old project. Pronouncing it "postgre" "s" "q" "l" is hard
in spanish as the "name" of the letter "s" is "ese", and so saying "postgre"
"ese" "q" "l" is harder (and uglier) to pronounce than "postgres" "s" "q" "l".

Regards,
Haroldo.

On Tue, Aug 22, 2000 at 08:22:21PM +0200, Peter Eisentraut wrote:

Hmm, I'm getting the feeling that perhaps at this point we should
explicitly *not* support NaN at all. After all, the underlying reason for
offering them is to provide IEEE 754 compliant floating point arithmetic,
but if we start making compromises such as NaN == NaN or NaN > +Infinity
then we might as well not do it. In these cases I opine that if you can't
do something correctly then you should perhaps be honest and don't do
it. After all, users that want a "not-a-number" can use NULL in most
cases, and hard-core floating point users are going to fail miserably
with the FE/BE protocol anyway.

Pretty much were I have come to on this, as well. The point is to get
the existing NaN to not break indicies or sorting. The simplest way is
to disable it.

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

I would go further and say that in the near future when some
milestone is reached (say, the addition of outer joins?) it
might be a good idea to mark the occasion with a name change
of some sort.

In my personal experience, out in the real world, people refer to it as
"Postgres". The QL being a mouthful, and contrary to the common practice
of pronouncing SQL as SEQUEL. While Marc points out that technically
Postgres died when it left Berkeley, that discontinuity is really only
something we choose to acknowledge. As Henry points out, SQL is only one
feature that happened to be added. Apart from not owning the domain
name, why shouldn't it just be "Postgres"?

On Wed, 23 Aug 2000, Chris Bitmead wrote:

I would go further and say that in the near future when some
milestone is reached (say, the addition of outer joins?) it
might be a good idea to mark the occasion with a name change
of some sort.

In my personal experience, out in the real world, people refer to it
as "Postgres". The QL being a mouthful, and contrary to the common
practice of pronouncing SQL as SEQUEL. While Marc points out that
technically Postgres died when it left Berkeley, that discontinuity is
really only something we choose to acknowledge. As Henry points out,
SQL is only one feature that happened to be added. Apart from not
owning the domain name, why shouldn't it just be "Postgres"?

4 years ago we discussed what to rename the project, since Postgres95
wasn't considerd a very "long term name" (kinda like Windows2000), and
PostgreSQL was choosen, as it both represented our roots as well as what
we've grown into ... we've spent 4 years now building up a market presence
with that name, getting it known so that ppl know what it is ... changing
it now is not an option. If PostgreSQL were considered a bad name, maybe
... look at MySQL with their new "MaxSQL" product ... but it isn't, and is
growing stronger ...

The Hermit Hacker wrote:

4 years ago we discussed what to rename the project, since Postgres95
wasn't considerd a very "long term name" (kinda like Windows2000), and
PostgreSQL was choosen, as it both represented our roots as well as what
we've grown into ... we've spent 4 years now building up a market presence
with that name,

Question: Did it work? Or are people really calling it Postgres instead?
Kind of like Coca Cola. At some point in time they realised people
weren't calling it Coca Cola anymore, they were calling it Coke. So
instead of resisting the inevitable - trying to educate people to ask
for a "Coca Cola", they accepted it, trademarked the name "Coke", and
started putting "Coke" on all their products.

When someone asks me what RDBMS our company uses for most projects and I say
post-gray 'Es Queue El' everyone always says "Huh? Post-what?"

I love the product but the name is a bitch of a tongue twister. It's strange
to say and doesn't roll off the tongue very well. Still, after I repeat
myself a few times they generally end up calling it "Postgres" all on their
own -- I guess there is some natural inclination for people to move from
post-gray 'Es Queue El' to plain old "Postgres"...

It's becoming more and more known even if it is a bit of a strange name at
first so I think it will all work out just fine..

-Mitch

----- Original Message -----
From: "Chris Bitmead" <chrisb@nimrod.itg.telstra.com.au>
To: "PostgreSQL HACKERS" <pgsql-hackers@postgreSQL.org>
Sent: Tuesday, August 22, 2000 5:42 PM
Subject: Re: [HACKERS] How Do You Pronounce "PostgreSQL"?

The Hermit Hacker wrote:

4 years ago we discussed what to rename the project, since Postgres95
wasn't considerd a very "long term name" (kinda like Windows2000), and
PostgreSQL was choosen, as it both represented our roots as well as what
we've grown into ... we've spent 4 years now building up a market

presence

with that name,

Question: Did it work? Or are people really calling it Postgres instead?
Kind of like Coca Cola. At some point in time they realised people
weren't calling it Coca Cola anymore, they were calling it Coke. So
instead of resisting the inevitable - trying to educate people to ask
for a "Coca Cola", they accepted it, trademarked the name "Coke", and
started putting "Coke" on all their products.

getting it known so that ppl know what it is ... changing
it now is not an option. If PostgreSQL were considered a bad name,

maybe

... look at MySQL with their new "MaxSQL" product ... but it isn't, and

is

On Tue, Aug 22, 2000 at 08:22:21PM +0200, Peter Eisentraut wrote:

Hmm, I'm getting the feeling that perhaps at this point we should
explicitly *not* support NaN at all.

Well ... this is a database, not a number-crunching system. It seems
to me that we should be able to store and retrieve NaNs (at least on
IEEE-compliant platforms). But I'm less excited about whether the
sorting/comparison operators we offer are 100% IEEE-compliant.

It has been quite a few years since I looked closely at the IEEE FP
specs, but I do still recall that they made a distinction between "IEEE
aware" and "non IEEE aware" comparison operators --- specifically, the
first kind understood about unordered comparisons and the second didn't.
Perhaps we could satisfy both SQL and IEEE requirements if we stipulate
that we implement only IEEE's "non-aware" comparisons? Worth looking at
anyway.

... hard-core floating point users are going to fail miserably
with the FE/BE protocol anyway.

It would be a mistake to design backend behavior on the assumption that
we'll never have an FE/BE protocol better than the one we have today.

(You could actually fix this problem without any protocol change,
just a SET variable to determine output precision for FP values.
Well-written platforms will reproduce floats exactly given "%.17g"
or more precision demand in sprintf. If that fails it's libc's
bug not ours.)

regards, tom lane

The Hermit Hacker wrote:

On Mon, 21 Aug 2000, Jan Wieck wrote:

The Hermit Hacker wrote:

what's wrong wth "Post-Gres-QL"?

I find it soooo simple to pronounce *shrug*

Mee too. And I'm not sure if anybody pronounces PG the same
way. Is it PeeGee or PiG (in which case we'd have the wrong
animal in our logo).

Actually, the one that gets me is those that refer to it as Postgres

I suspect that it is still at least 75% postgres codewize, no?

... postgres was a project out of Berkeley way back in the 80's, early
90's ... hell, it was based on a PostQuel language ... this ain't
postgres, its only based on it :(

so postgres-QL is based on a project that is based on PostQuel

as the ease of initial transition from PostQuel to SQL shows, it is not
"based on" SQL, it just happens to use SQL as a query language.
It did not even loose too much features in transition.

IMHO PG is based on solid relational database technology.

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

The Hermit Hacker <scrappy@hub.org> writes:

Actually, the one that gets me is those that refer to it as Postgres
... postgres was a project out of Berkeley way back in the 80's, early
90's ... hell, it was based on a PostQuel language ... this ain't
postgres, its only based on it :(

Yes, and besides, if you call it Postgres, you are certain to offend the
struggling Postgres community.

Is there anybody out there to offend ?

Those PostQuel language zealots have enough
problems keeping their technology alive as it is without people going

around

creating gratuitous brand confusion.

Hmm? Are you suggesting that the PostQuel Postgres is still
under development, and those zealots exist ?
I thought it is dead since Version 4.2.
Could you give me a pointer ?

Thanks
Andreas

In my personal experience, out in the real world, people refer to it as
"Postgres". The QL being a mouthful, and contrary to the common practice
of pronouncing SQL as SEQUEL. While Marc points out that technically
Postgres died when it left Berkeley, that discontinuity is really only
something we choose to acknowledge. As Henry points out, SQL
is only one
feature that happened to be added. Apart from not owning the domain
name, why shouldn't it just be "Postgres"?

Everybody I know also still sais "Postgres", leaving out the Q L
becaus it is too long. In german we would not have the "sequel" problem,
since we pronounce it "ess ku ell". I think they all know that they are
really
referring to PostgreSQL.

Guess what you find under www.postgres.com ? Yes, it is Great Bridge.
postgresql.com is taken by some Korean domain grabber.

BTW Marc, I would make www.postgres.org point to postgresql.

Andreas

On Thu, 24 Aug 2000, Zeugswetter Andreas SB wrote:

In my personal experience, out in the real world, people refer to it as
"Postgres". The QL being a mouthful, and contrary to the common practice
of pronouncing SQL as SEQUEL. While Marc points out that technically
Postgres died when it left Berkeley, that discontinuity is really only
something we choose to acknowledge. As Henry points out, SQL
is only one
feature that happened to be added. Apart from not owning the domain
name, why shouldn't it just be "Postgres"?

Everybody I know also still sais "Postgres", leaving out the Q L
becaus it is too long. In german we would not have the "sequel" problem,
since we pronounce it "ess ku ell". I think they all know that they are
really
referring to PostgreSQL.

Guess what you find under www.postgres.com ? Yes, it is Great Bridge.
postgresql.com is taken by some Korean domain grabber.

BTW Marc, I would make www.postgres.org point to postgresql.

Not our domain to point ... it too belongs to Great Bridge ...

At 10:29 AM 8/24/00 +0200, Zeugswetter Andreas SB wrote:

The Hermit Hacker <scrappy@hub.org> writes:

Actually, the one that gets me is those that refer to it as Postgres
... postgres was a project out of Berkeley way back in the 80's, early
90's ... hell, it was based on a PostQuel language ... this ain't
postgres, its only based on it :(

Yes, and besides, if you call it Postgres, you are certain to offend the
struggling Postgres community.

Is there anybody out there to offend ?

Those PostQuel language zealots have enough
problems keeping their technology alive as it is without people going

around

creating gratuitous brand confusion.

Hmm? Are you suggesting that the PostQuel Postgres is still
under development, and those zealots exist ?
I thought it is dead since Version 4.2.
Could you give me a pointer ?

Uhhh...satire alert! satire alert!

- 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.

The Hermit Hacker wrote:

Guess what you find under www.postgres.com ? Yes, it is Great Bridge.
postgresql.com is taken by some Korean domain grabber.

BTW Marc, I would make www.postgres.org point to postgresql.

Not our domain to point ... it too belongs to Great Bridge ...

That's interesting, when did GreatBridge acquire them?

In my opinion, we should change the name to Postgres, and get
GreatBridge to donate the .org domain to the opensource project. That's
good for Greatbridge because they own the .com which would actually then
become useful. It's good for the free project because people are calling
it postgres anyway and it's a better brand name.

On Fri, 25 Aug 2000, Chris Bitmead wrote:

The Hermit Hacker wrote:

Guess what you find under www.postgres.com ? Yes, it is Great Bridge.
postgresql.com is taken by some Korean domain grabber.

BTW Marc, I would make www.postgres.org point to postgresql.

Not our domain to point ... it too belongs to Great Bridge ...

That's interesting, when did GreatBridge acquire them?

In my opinion, we should change the name to Postgres, and get
GreatBridge to donate the .org domain to the opensource project. That's
good for Greatbridge because they own the .com which would actually then
become useful. It's good for the free project because people are calling
it postgres anyway and it's a better brand name.

Just because ppl are referring to the project by the wrong name doesn't
make it right ... just because MySQL changes their name to MaxSQL, are you
going to accept them any differently?

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

The Hermit Hacker wrote:

Just because ppl are referring to the project by the wrong name doesn't
make it right...

Which do you prefer? To be the only one who is right, when everyone else
is wrong. Or to change the definition of right so that the software is
universally called by its correct name?

On Fri, 25 Aug 2000, Chris Bitmead wrote:

The Hermit Hacker wrote:

Just because ppl are referring to the project by the wrong name doesn't
make it right...

Which do you prefer? To be the only one who is right, when everyone else
is wrong. Or to change the definition of right so that the software is
universally called by its correct name?

Hmmm. Let's make a little table, shall we?

Proper name Nickname
----------- --------
Chevrolet Chevy
PostgreSQL Postgres
Christopher Chris
Marcus Marc
Robert Bob
Richard Rick

Since I don't see Chevrolet changing their name to Chevy just because
everyone calls it that, or Christopher Chris, Marcus Marc, Robert Bob,
etc. why do you feel it necessary to change PostgreSQL to Postgres?

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

Vince Vielhaber wrote:

Hmmm. Let's make a little table, shall we?

Proper name Nickname
----------- --------
Chevrolet Chevy
PostgreSQL Postgres
Christopher Chris
Marcus Marc
Robert Bob
Richard Rick

Since I don't see Chevrolet changing their name to Chevy just because
everyone calls it that, or Christopher Chris, Marcus Marc, Robert Bob,
etc. why do you feel it necessary to change PostgreSQL to Postgres?

I would be far overstating my case to say it is "necessary". Only
putting forward an opinion that it is desirable.

The current release of PostgreSQL is 7.0. In reality it is release 3.0,
the four releases prior to that were known as Postgres. I don't see the
name change as having been desirable.

For Christopher -> Chris, I must say that this is one aspect I dislike
about my own name. I have deliberately chosen names for my own children
which are unlikely to require an abbreviation.

I could also draw up my own table of abbreviations which have become so
ubiquitous that the original names are all but forgotten. In fact one
could go through the dictionary and point out many of the words as
having arisen from an abbreviation of a longer expression.

On Sat, 26 Aug 2000, Chris wrote:

Vince Vielhaber wrote:

Hmmm. Let's make a little table, shall we?

Proper name Nickname
----------- --------
Chevrolet Chevy
PostgreSQL Postgres
Christopher Chris
Marcus Marc
Robert Bob
Richard Rick

Since I don't see Chevrolet changing their name to Chevy just because
everyone calls it that, or Christopher Chris, Marcus Marc, Robert Bob,
etc. why do you feel it necessary to change PostgreSQL to Postgres?

I would be far overstating my case to say it is "necessary". Only
putting forward an opinion that it is desirable.

The current release of PostgreSQL is 7.0. In reality it is release 3.0,
the four releases prior to that were known as Postgres. I don't see the
name change as having been desirable.

Huh? v1.09 was Postgres95, v2.x (our v6.x) was PostgreSQL, and that was
over 4 years ago ...

The current release of PostgreSQL is 7.0. In reality it is release 3.0,
the four releases prior to that were known as Postgres. I don't see the
name change as having been desirable.

Huh? v1.09 was Postgres95, v2.x (our v6.x) was PostgreSQL, and that was
over 4 years ago ...

I stand corrected. The current release should be 2.0 of PostgreSQL.

I hate these discussions. Endless back and forth -- much ado about nothing.
Yet...

"PostgresSQL" does seem kinda unwieldy and awkward. And the "SQL" part does
seem superfluous since most databases now support SQL in some way shape or
form. Adding "SQL" now seems almost as arbitrary as the previous "95".

Yes, not all databases can claim full SQL compliance, and Postgres does it
better than MySQL but so what? PostgreSQL's "competition" is much broader:
Oracle, SQL Server, DB2, etc. -- all of whom have excellent SQL support.

If it is deemed important to tack on defining features of a "next
generation" database then prehaps "OR" (object-relational) should be tacked
on instead of, or in addition to "SQL"? But in five years this will again
seem an unnecessary addition to "Postgre(s)" and the name would still be
cumbersome.

PostgreSQLOR?, PostgreSQL-OR?, PostgreORSQL? Postgre-ORSQL?

I really don't know what the best name would be, and keeping it the way it
is is just fine with me. I use PostgreSQL for what it is, not what it is
called. Returning to the core descriptive term: "Postgre(s)" would be fine
also.

John

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

From: "Mitch Vincent" <mitch@venux.net>

When someone asks me what RDBMS our company uses for most projects and I

say

post-gray 'Es Queue El' everyone always says "Huh? Post-what?"

I love the product but the name is a bitch of a tongue twister. It's

strange

to say and doesn't roll off the tongue very well.

Just a small detail for evvybuddy: "Postgres," -- dot-com, dot-net, and I
stopped checking after that -- have belonged to some company called, uh,
Great Bridge, in Norfolk Virginia, since April 20th.

I don't make these strange and wonderful stories up...

-dlj.

Since I don't see Chevrolet changing their name to Chevy just because
everyone calls it that, or Christopher Chris, Marcus Marc, Robert Bob,
etc. why do you feel it necessary to change PostgreSQL to Postgres?

I like this interpretation of short name vs long name, but Marc sais we
(referring to PostgreSQL by short name) are "evil".

I think what we want is, that you easily find our webpage/product if you
only know the short name.

Andreas

On Mon, Aug 21, 2000 at 07:55:00PM -0700, Joe Brenner wrote:
...

And I have to say that "postgresql" has one of the worst
names of any software I've ever encountered. I'm entirely
in sympathy with the "suit" who suggested calling it "PG".

Like the tea-bags ;-)

My assumption is that we never came up with any solution to this, right?

On Sun, Aug 20, 2000 at 12:33:00AM +0200, Peter Eisentraut wrote:
<snip side comment about bug tracking. My input: for an email controllable
system, take a look at the debian bug tracking system>

Show me a system where it doesn't work and we'll get it to work.
UNSAFE_FLOATS as it stands it probably not the most appropriate behaviour;
it intends to speed things up, not make things portable.

I agree. In the previous thread on this, Thomas suggested creating a flag
that would allow control turning the CheckFloat8Val function calls into
a macro NOOP. Sound slike a plan to me.

NULL and NaN are not quite the same thing imho. If we are allowing NaN
in columns, then it is *known* to be NaN.

For the purposes of ordering, however, they are very similar.

Then we can also treat them similar, i.e. sort them all last or all first.
If you have NaN's in your data you wouldn't be interested in ordering
anyway.

Right, but the problem is that NULLs are an SQL language feature, and
there for rightly special cased directly in the sorting apparatus. NaN is
type specific, and I'd be loath to special case it in the same place. As
it happens, I've spent some time this weekend groveling through the sort
(and index, as it happens) code, and have an idea for a type specific fix.

Here's the deal, and an actual, honest to goodness bug in the current code.

As it stands, we allow one non-finite to be stored in a float8 field:
NaN, with partial parsing of 'Infinity'.

As I reported last week, NaNs break sorts: they act as barriers, creating
sorted subsections in the output. As those familiar with the code have
already guessed, there is a more serious bug: NaNs break indicies on
float8 fields, essentially chopping the index off at the first NaN.

Fixing this turns out to be a one liner to btfloat8cmp.

Fixing sorts is a bit tricker, but can be done: Currently, I've hacked
the float8lt and float8gt code to sort NaN to after +/-Infinity. (since
NULLs are special cased, they end up sorting after NaN). I don't see
any problems with this solution, and it give the desired behavior.

I've attached a patch which fixes all the sort and index problems, as well
as adding input support for -Infinity. This is not a complete solution,
since I haven't done anything with the CheckFloat8Val test. On my
system (linux/glibc2.1) compiling with UNSAFE_FLOATS seems to work fine
for testing.

Side note 2: The paper "How Java's floating point hurts everyone
everywhere" provides for good context reading.

http://http/cs.berkeley.edu/~wkahan/JAVAhurt.pdf ? I'll take a look at it
when I get in to work Monday.

Side note 3: Once you read that paper you will agree that using floating
point with Postgres is completely insane as long as the FE/BE protocol is
text-based.

Probably. But it's not our job to enforce sanity, right? Another way to think
about it is fixing the implementation so the deficiencies of the FE/BE stand
out in a clearer light. ;-)

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

[ Attachment, skipping... ]

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  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 writes:

My assumption is that we never came up with any solution to this, right?

It stopped when we noticed that proper support for non-finite values will
break indexing, because the relational trichotomy doesn't hold.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

[ Charset ISO-8859-1 unsupported, converting... ]

In my personal experience, out in the real world, people refer to it as
"Postgres". The QL being a mouthful, and contrary to the common practice
of pronouncing SQL as SEQUEL. While Marc points out that technically
Postgres died when it left Berkeley, that discontinuity is really only
something we choose to acknowledge. As Henry points out, SQL
is only one
feature that happened to be added. Apart from not owning the domain
name, why shouldn't it just be "Postgres"?

Everybody I know also still sais "Postgres", leaving out the Q L
becaus it is too long. In german we would not have the "sequel" problem,
since we pronounce it "ess ku ell". I think they all know that they are
really
referring to PostgreSQL.

Someone once described our name as anti-marketing. That point hit home
with me.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  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

On Fri, 25 Aug 2000, Chris Bitmead wrote:

The Hermit Hacker wrote:

Just because ppl are referring to the project by the wrong name doesn't
make it right...

Which do you prefer? To be the only one who is right, when everyone else
is wrong. Or to change the definition of right so that the software is
universally called by its correct name?

Hmmm. Let's make a little table, shall we?

Proper name Nickname
----------- --------
Chevrolet Chevy
PostgreSQL Postgres
Christopher Chris
Marcus Marc
Robert Bob
Richard Rick

Since I don't see Chevrolet changing their name to Chevy just because
everyone calls it that, or Christopher Chris, Marcus Marc, Robert Bob,
etc. why do you feel it necessary to change PostgreSQL to Postgres?

This is unfair because Vince(Vincent?) works for Chrysler. :-)

Also, I never realized Marc was short for Marcus. I thought it was just
a funny (Canuk/Canadian) spelling of Mark. :-) Shows you how stupid I
am in some things.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  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

[ continuing a discussion from last August ]

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

My assumption is that we never came up with any solution to this, right?

It stopped when we noticed that proper support for non-finite values will
break indexing, because the relational trichotomy doesn't hold.

I believe that's not a problem anymore. The current form of the float
comparison functions will perform sorting and comparisons according to
the sequence

-infinity < normal values < infinity < NaN < NULL

with all NaNs treated as equal. This may not be exactly what an IEEE
purist would like, but given that we have to define *some* consistent
sort order, it seems as reasonable as we can get.

Accordingly, I suggest that Ross go back to work on persuading the code
to treat infinities and NaNs properly in other respects. IIRC, there
are still open issues concerning whether we still need/want
CheckFloat8Val/CheckFloat4Val, what the I/O conversion functions should
do on non-IEEE machines, etc. They all seemed soluble, though.

regards, tom lane

Tom Lane writes:

[ continuing a discussion from last August ]

[I was *just* thinking about this. Funny.]

I believe that's not a problem anymore. The current form of the float
comparison functions will perform sorting and comparisons according to
the sequence

-infinity < normal values < infinity < NaN < NULL

I was thinking about making NaN equivalent to NULL. That would give
consistency in ordering, and probably also in arithmetic. Additionally,
if the platform supports it we ought to make the Invalid Operation FP
exception (which yields NaN) configurable: either get NULL or get an
error.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Peter Eisentraut <peter_e@gmx.net> writes:

I was thinking about making NaN equivalent to NULL.

Mumble ... in the thread last August, someone made the point that SQL's
idea of NULL ("unknown value") is not really the same as a NaN ("I know
that this is not a well-defined number"). Even though there's a lot of
similarity in the behaviors, I'd be inclined to preserve that semantic
distinction.

If we did want to do this, the implication would be that all
float-returning functions would be required to make sure they were not
returning NaNs:
if (isnan(x))
PG_RETURN_NULL();
else
PG_RETURN_FLOAT8(x);
Possibly this logic could be folded right into the PG_RETURN_FLOAT
macros.

if the platform supports it we ought to make the Invalid Operation FP
exception (which yields NaN) configurable: either get NULL or get an
error.

Seems like we could equally well offer the switch as "either get NaN
or get an error".

Something to be kept in mind here is the likelihood of divergence in
our behavior between IEEE and non-IEEE platforms. I don't object to
that --- it's sort of the point --- but we should be aware of how much
difference we're creating, and try to avoid unnecessary differences.
Hmm ... I suppose an attraction of a NULL-vs-error, as opposed to NaN-
vs-error, option is that it could theoretically be supported on NaN-less
hardware. But is that realizable in practice? SIGFPE is messy.

regards, tom lane

-infinity < normal values < infinity < NaN < NULL

I was thinking about making NaN equivalent to NULL. That would give
consistency in ordering, and probably also in arithmetic. Additionally,
if the platform supports it we ought to make the Invalid Operation FP
exception (which yields NaN) configurable: either get NULL or get an
error.

I'd like to see the distinction between NaN and NULL retained, since the
two "values" arise from different circumstances and under different
conditions. If a particular app needs them to be equivalent, then that
is easy enough to do with SQL or triggers.

- Thomas

On a modestly related note, I'm come over to the notion that the
date/time value 'current' could be ripped out eventually. Tom, isn't
that the only case for those types which bolluxes up caching of
date/time types?

Thomas Lockhart <lockhart@fourpalms.org> writes:

On a modestly related note, I'm come over to the notion that the
date/time value 'current' could be ripped out eventually. Tom, isn't
that the only case for those types which bolluxes up caching of
date/time types?

Yes, I believe so. At least, that was the consideration that led me
to mark those functions noncachable ...

regards, tom lane