Outstanding patches

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

I will be applying outstanding 7.4 patches on Friday:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
If anyone wants those rejected/modified, please let me know.

array upper/lower bound: missing doc updates, otherwise seems okay.

\pset pager always: I thought we had rejected that idea in favor of
making the whether-to-use-pager decision pay attention to width as
well as number of lines.

temp tables: difficult to comment on a message that does not include the
proposed patch.

CLUSTER ALL patch: I have a problem with this, specifically the fact
that it changes CLUSTER into a multi-transaction operation. That
renders CLUSTER non-rollbackable and not callable from functions.
After all the work we went to to make CLUSTER rollbackable, this seems
like a giant step backward.

CREATE SEQUENCE syntax changes: did we decide whether SQL99's notion of
a sequence is close enough to ours that migrating to their syntax would
be a good idea, and not just a source of confusion? I seem to recall
some doubts being voiced about this (by Peter?), and I'm not sure we
resolved them.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

CREATE SEQUENCE syntax changes: did we decide whether SQL99's notion of
a sequence is close enough to ours that migrating to their syntax would
be a good idea, and not just a source of confusion? I seem to recall
some doubts being voiced about this (by Peter?), and I'm not sure we
resolved them.

Last I heard, we had concluded that SQL2003's notion of a sequence is
sufficiently close to ours that the differences are mostly syntax.

(Note that SQL99 does not define sequences.)

Cheers,

Neil

--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

On Thu, Nov 07, 2002 at 12:27:05AM -0500, Tom Lane wrote:

CLUSTER ALL patch: I have a problem with this, specifically the fact
that it changes CLUSTER into a multi-transaction operation.

That was your suggestion...

That renders CLUSTER non-rollbackable and not callable from functions.
After all the work we went to to make CLUSTER rollbackable, this seems
like a giant step backward.

Well, CLUSTER ALL is now non-rollbackable. But why is it useful to
rollback a CLUSTER operation?

I think I can make the one-table-only version rollbackable again (and
keep the ALL version multitransaction). Is that a good tradeoff? Note
that the clusterdb script to appear in 7.3 is horribly broken for
concurrent cases, and is much worse than the outstanding CLUSTER ALL
patch.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Saca el libro que tu religion considere como el indicado para encontrar la
oracion que traiga paz a tu alma. Luego rebootea el computador
y ve si funciona" (Carlos Duclos)

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

On Thu, Nov 07, 2002 at 12:27:05AM -0500, Tom Lane wrote:

CLUSTER ALL patch: I have a problem with this, specifically the fact
that it changes CLUSTER into a multi-transaction operation.

That was your suggestion...

Well, it'd be okay (IMHO anyway) if it only happened for CLUSTER ALL.
You've built it in a way that the restriction applies to single-table
CLUSTERs, which is an unnecessary step backwards.

What I think I'd like to see is

CLUSTER index ON table -- does not hack transactions
CLUSTER table -- recluster a table, does not hack transactions
CLUSTER -- recluster all tables, works like VACUUM

This would allow people to build functions that do selective CLUSTERing,
at the price of holding more exclusive locks.

regards, tom lane

On Thu, Nov 07, 2002 at 01:44:21PM -0500, Tom Lane wrote:

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

On Thu, Nov 07, 2002 at 12:27:05AM -0500, Tom Lane wrote:

CLUSTER ALL patch: I have a problem with this, specifically the fact
that it changes CLUSTER into a multi-transaction operation.

That was your suggestion...

Well, it'd be okay (IMHO anyway) if it only happened for CLUSTER ALL.
You've built it in a way that the restriction applies to single-table
CLUSTERs, which is an unnecessary step backwards.

Ok, I'll rework the patch. It never ocurred to me that it'd be an
issue.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Crear es tan dificil como ser libre" (Elsa Triolet)

Neil Conway writes:

Last I heard, we had concluded that SQL2003's notion of a sequence is
sufficiently close to ours that the differences are mostly syntax.

I concur, but do we have some sort of commitment that the rest of
the SQL200x sequence machinery will be supported eventually? Otherwise,
adding some irrelevant syntax variations in limited places doesn't seem
fruitful.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

I concur, but do we have some sort of commitment that the rest of
the SQL200x sequence machinery will be supported eventually? Otherwise,
adding some irrelevant syntax variations in limited places doesn't seem
fruitful.

Yes, I'll implement the rest of the SQL200x sequence stuff
eventually. However, if you'd rather wait for me to finish it all and
then commit it at that point, that's fine with me.

Cheers,

Neil

--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

I concur, but do we have some sort of commitment that the rest of
the SQL200x sequence machinery will be supported eventually? Otherwise,
adding some irrelevant syntax variations in limited places doesn't seem
fruitful.

Yes, I'll implement the rest of the SQL200x sequence stuff
eventually. However, if you'd rather wait for me to finish it all and
then commit it at that point, that's fine with me.

I'd suggest contributing what you have now. Waiting just keeps others
from contributing to the topic (which is not your intention certainly,
but it would have that effect).

- Thomas

Thomas Lockhart <lockhart@fourpalms.org> writes:

I'd suggest contributing what you have now. Waiting just keeps others
from contributing to the topic (which is not your intention certainly,
but it would have that effect).

Right -- all the work I've done on the topic has been submitted to
Bruce. I'm fine with it being committed as is (as you suggest), or
waiting until there is more substantial work done on the topic.

Cheers,

Neil

--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

I have applied the following doc patch for array_upper/lower(). The
other issues have already been addressed.

---------------------------------------------------------------------------

Tom Lane wrote:

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

I will be applying outstanding 7.4 patches on Friday:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
If anyone wants those rejected/modified, please let me know.

array upper/lower bound: missing doc updates, otherwise seems okay.

\pset pager always: I thought we had rejected that idea in favor of
making the whether-to-use-pager decision pay attention to width as
well as number of lines.

temp tables: difficult to comment on a message that does not include the
proposed patch.

CLUSTER ALL patch: I have a problem with this, specifically the fact
that it changes CLUSTER into a multi-transaction operation. That
renders CLUSTER non-rollbackable and not callable from functions.
After all the work we went to to make CLUSTER rollbackable, this seems
like a giant step backward.

CREATE SEQUENCE syntax changes: did we decide whether SQL99's notion of
a sequence is close enough to ours that migrating to their syntax would
be a good idea, and not just a source of confusion? I seem to recall
some doubts being voiced about this (by Peter?), and I'm not sure we
resolved them.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073