Upcoming Attractions, web site

Looks nice. Might rephrase:

Those of you who did not like
our table-level locking will be pleasantly surprised.

to be something like

Those of you wanting alternatives to
our table-level locking will be pleasantly surprised.

The new CASE statement might be of interest, and I'm looking forward to
getting far enough along on outer joins to get a mention of that too :)

- Tom

Bruce, Marc, et al-

Bruce Momjian wrote:

I think it might be nice to get this out on the web page in a prominent
place until we release 6.5. Seems like we should be talking up these
features so people can get excited.

In February, we start beta on 6.5...

I have been working on some revisions for the main home page.
A preliminary version, including the 6.5 blurb, can be found at:

http://www.postgresql.org/mainx.html

What do you think?

Looks great.

Notes:

- I deleted references to Vadim and Jan to make the item seem less
less like a private communication intended for insiders. No slight
is intended here.

OK.

- The navigation bar is no longer a frame. I think Marc and I agree
the old navigation-bar frame scheme should be revised. I'd like it
to have explanatory onMouseOvers, but this isn't there yet - I'm
still trying out several things. Changing how the navigation bars
work will affect most pages on the site, giving it a different feel.

I like that too.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Looks nice. Might rephrase:

Those of you who did not like
our table-level locking will be pleasantly surprised.

to be something like

Those of you wanting alternatives to
our table-level locking will be pleasantly surprised.

The new CASE statement might be of interest, and I'm looking forward to
getting far enough along on outer joins to get a mention of that too :)

Yes, CASE would be good to add. You can say:

An SQL-standard CASE statement is planned too.

Thomas, do you need help on outer joins?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Looks nice. Might rephrase:

Those of you who did not like
our table-level locking will be pleasantly surprised.

to be something like

Those of you wanting alternatives to
our table-level locking will be pleasantly surprised.

I don't like the new wording. It sounds like we are adding an optional
functionality, while we are replacing table-level locking because MVCC
is much better. We can say:

Those of you need better locking than our current
table-level locking will be pleasantly surprised.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Thomas, do you need help on outer joins?

Yes. I'm going slowly partly because I get distracted with other
Postgres stuff like docs, and partly because I don't understand all of
the pieces I'm working with.

I've identified the place in the MergeJoin code where the null filling
for outer joins needs to happen, and have the "merge walk" code done.
But I don't have the supporting code which actually would know how to
null-fill a result tuple from the left or right. I thought you might be
interested in that?

I've done some work in the parser, and can now do things like:

postgres=> select * from t1 join t2 using (i);
NOTICE: JOIN not yet implemented
i|j|i|k
-+-+-+-
1|2|1|3
(1 row)

But this is just an inner join, and the result isn't quite right since
the second "i" column should probably be omitted. At the moment I
transform it from the syntax above into existing parse nodes, and
everything from there on works.

I don't yet pass an explicit join node into the planner/optimizer, and
that will be the hardest part I assume. Perhaps we can work on that
together.

So, what I'll try to do (soon, in the next few days?) is put in

#ifdef ENABLE_OUTER_JOINS

conditional code into the parser area (already there for the executor)
and commit everything to the development tree. Does that sound OK?

Oh, and if anyone is looking for something to do, I've got a couple of
CASE statements in the case.sql regression test which are commented out
because they crash the backend. They involve references to multiple
tables within a single result column, and in other contexts that
construct works. It would be great if someone had time to track it
down...

- Tom

Thomas, do you need help on outer joins?

Yes. I'm going slowly partly because I get distracted with other
Postgres stuff like docs, and partly because I don't understand all of
the pieces I'm working with.

I've identified the place in the MergeJoin code where the null filling
for outer joins needs to happen, and have the "merge walk" code done.
But I don't have the supporting code which actually would know how to
null-fill a result tuple from the left or right. I thought
you might be
interested in that?

I've done some work in the parser, and can now do things like:

postgres=> select * from t1 join t2 using (i);
NOTICE: JOIN not yet implemented
i|j|i|k
-+-+-+-
1|2|1|3
(1 row)

But this is just an inner join, and the result isn't quite right since
the second "i" column should probably be omitted. At the moment I
transform it from the syntax above into existing parse nodes, and
everything from there on works.

I could be wrong (I don't have a copy of the standard), but I don't
believe that the above syntax follows the standard. Let me know if I'm
wrong, but my understanding of the syntax would be more like:
SELECT * FROM t1 JOIN t2 ON (t1.i = t2.i);
with the same result set as you listed (t2.i isn't suppressed).
This would have a difference in approach from the above. If I wanted to
join on columns with different names I couldn't use your syntax (as one
example).
-DEJ

I could be wrong (I don't have a copy of the standard), but I don't
believe that the above syntax follows the standard. Let me know if
I'm wrong, but my understanding of the syntax would be more like:
SELECT * FROM t1 JOIN t2 ON (t1.i = t2.i);
with the same result set as you listed (t2.i isn't suppressed).
This would have a difference in approach from the above. If I wanted
to join on columns with different names I couldn't use your syntax (as
one example).

The standard allows both syntaxes; USING is simpler to type, and ON is
more general, as you point out.

In fact, the standard is annoyingly helpful in allowing multiple ways to
write the same query. Makes the parsing and parse tree transformation
more complicated :(

- Tom

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

I could be wrong (I don't have a copy of the standard), but I don't
believe that the above syntax follows the standard. Let me know if
I'm wrong, but my understanding of the syntax would be more like:
SELECT * FROM t1 JOIN t2 ON (t1.i = t2.i);
with the same result set as you listed (t2.i isn't suppressed).
This would have a difference in approach from the above.

If I wanted

to join on columns with different names I couldn't use your

syntax (as

one example).

The standard allows both syntaxes; USING is simpler to type, and ON is
more general, as you point out.

In fact, the standard is annoyingly helpful in allowing
multiple ways to
write the same query. Makes the parsing and parse tree transformation
more complicated :(

Sorry for the extra work load, but hey that's cool.

- Tom

-DEJ