Thread
-
Outstanding patches
Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-07T03:11:47Z
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. -- 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
-
Re: Outstanding patches
Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-07T05:27:05Z
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
-
Re: Outstanding patches
Neil Conway <neilc@samurai.com> — 2002-11-07T06:03:17Z
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
-
Re: Outstanding patches
Alvaro Herrera <alvherre@dcc.uchile.cl> — 2002-11-07T18:32:03Z
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)
-
Re: Outstanding patches
Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-07T18:44:21Z
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
-
Re: Outstanding patches
Alvaro Herrera <alvherre@dcc.uchile.cl> — 2002-11-07T18:47:23Z
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)
-
Re: Outstanding patches
Peter Eisentraut <peter_e@gmx.net> — 2002-11-07T21:21:25Z
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
-
Re: Outstanding patches
Neil Conway <neilc@samurai.com> — 2002-11-07T21:51:04Z
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
-
Re: Outstanding patches
lockhart@fourpalms.org — 2002-11-08T00:16:18Z
>>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 -
Re: Outstanding patches
Neil Conway <neilc@samurai.com> — 2002-11-08T00:24:41Z
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
-
Re: Outstanding patches
Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-10T00:31:40Z
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