Thread: Outstanding patches
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, Pennsylvania19073
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
The major thing you can do, besides using a prepare, is to not bother
splitting 502 times, but only enough times so that the last field you
are going to use is included. In this case, the highest element you are
using is [25], which is actually the 26th element to be split. Add one
more and 0-25 will be split, while 26 will be one giant field:
my @line = split(/\|/, $_, 27);
Since you already know exactly which fields you want from the split
result, we can specify those directly like this:
my @line = (split(/\|/, $_, 27))[0,4,5,6,10,11,14,18,22,25];
The parenthesis around the split call force it to be evaluated first,
and then we slice out the values we need. Now @line holds exactly the
elements you want to add in. Just pass that in to a prepared statement.
You can also remove the chomp and the chop, as the ends of the line are
being discarded anyways. Moving the commit outside of the loop should
help too. Here's the final result:
my $SQL = "INSERT INTO cdl_16master VALUES(nextval('cdl_16_seq'),?,?,?,?,?,?,?,?,?,?";
my $sth = $dbh->prepare($SQL);
while(<FHD>) {
my @line = (split(/\|/, $_, 27))[0,4,5,6,10,11,14,18,22,25];
$sth->execute(@line);
}
$dbh->commit();
On a final note, you may want to create tables in the future that
automagically populate columns with sequences like this:
CREATE TABLE cdl_16master (
myid INTEGER NOT NULL DEFAULT nextval('cd_16_seq'),
...
);
The drawback is that you will need to specify the exact columns to be
filled in the INSERT command, but this is really a good practice to
get into anyway.
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200210291455
-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html
iD8DBQE9vunyvJuQZxSWSsgRAnFKAKD5Fkyl9TzEaRwrNTuX8dqvRa6SCACg3Bzd
pgaJNkoGC2hXvpE23Ko9CaE=
=wtsO
-----END PGP SIGNATURE-----
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 transactionsCLUSTER table -- recluster a table, does not hack
transactionsCLUSTER-- 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 Index: doc/src/sgml/array.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/array.sgml,v retrieving revision 1.22 diff -c -c -r1.22 array.sgml *** doc/src/sgml/array.sgml 21 Sep 2002 18:32:52 -0000 1.22 --- doc/src/sgml/array.sgml 10 Nov 2002 00:30:01 -0000 *************** *** 195,201 **** <function>array_dims</function> produces a <type>text</type> result, which is convenient for people to read but perhaps not so convenient ! for programs. </para> <para> --- 195,203 ---- <function>array_dims</function> produces a <type>text</type> result, which is convenient for people to read but perhaps not so convenient ! for programs. <function>array_upper</function> and <function> ! array_lower</function> return the upper/lower bound of the ! given array dimension, respectively. </para> <para>