Thread: Current initdb broken.
Hi, I know it doesn't show in a patch, but.. there are some rogue spaces at the end of the line containing "usecreatetable". Keith. *** pgsql/src/bin/initdb/initdb.sh Fri Jun 9 18:09:51 2000 --- /usr/local/pgsql/src/bin/initdb/initdb.sh Sat Jun 10 00:07:07 2000 *************** *** 523,529 **** usename, \ usesysid, \ usecreatedb, \ ! \ uselocktable, \ usetrace, \ usesuper, \ --- 523,529 ---- usename, \ usesysid, \ usecreatedb, \ ! usecreatetable, \ uselocktable, \ usetrace, \ usesuper, \
THanks. Fixed. > Hi, > > I know it doesn't show in a patch, but.. there are some > rogue spaces at the end of the line containing "usecreatetable". > > Keith. > > *** pgsql/src/bin/initdb/initdb.sh Fri Jun 9 18:09:51 2000 > --- /usr/local/pgsql/src/bin/initdb/initdb.sh Sat Jun 10 00:07:07 2000 > *************** > *** 523,529 **** > usename, \ > usesysid, \ > usecreatedb, \ > ! \ > uselocktable, \ > usetrace, \ > usesuper, \ > --- 523,529 ---- > usename, \ > usesysid, \ > usecreatedb, \ > ! usecreatetable, \ > uselocktable, \ > usetrace, \ > usesuper, \ > > -- Bruce Momjian | http://www.op.net/~candle 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, Pennsylvania19026
Um, excuse me. Any changes to the format of pg_shadow will break pg_dumpall, therefore this needs to be hold back until next release. Bruce Momjian writes: > THanks. Fixed. > > > > Hi, > > > > I know it doesn't show in a patch, but.. there are some > > rogue spaces at the end of the line containing "usecreatetable". > > > > Keith. > > > > *** pgsql/src/bin/initdb/initdb.sh Fri Jun 9 18:09:51 2000 > > --- /usr/local/pgsql/src/bin/initdb/initdb.sh Sat Jun 10 00:07:07 2000 > > *************** > > *** 523,529 **** > > usename, \ > > usesysid, \ > > usecreatedb, \ > > ! \ > > uselocktable, \ > > usetrace, \ > > usesuper, \ > > --- 523,529 ---- > > usename, \ > > usesysid, \ > > usecreatedb, \ > > ! usecreatetable, \ > > uselocktable, \ > > usetrace, \ > > usesuper, \ > > > > > > > -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
[ Charset ISO-8859-1 unsupported, converting... ] > Um, excuse me. Any changes to the format of pg_shadow will break > pg_dumpall, therefore this needs to be hold back until next release. I see your point, and the comment in pg_dumpall: # load all the non-postgres users# XXX this breaks badly if the layout of pg_shadow ever changes.# It'd be better to convertthe data into CREATE USER commands. Well, seems there would be no good way to add columns using pg_dumpall, even if we waited until 7.1. The problem is that pg_dumpall assumes that the databases being dumped and loaded have a pg_shadow with exactly the same columns, as you noted in your comment. Well one solution is to have 7.1 use CREATE USER commands, then add the pg_shadow columns in 7.2. If we re-order the new columns to be at the end, those columns will load in with NULL's. We could then modify the user code to make default for NULL values in the new columns. Another answer is to add some code to COPY to supply default values for missing fields when loading pg_shadow. If we move the new columns to the end of pg_shadow, that should be only a few lines of C code which we can remove later. > > > Bruce Momjian writes: > > > THanks. Fixed. > > > > > > > Hi, > > > > > > I know it doesn't show in a patch, but.. there are some > > > rogue spaces at the end of the line containing "usecreatetable". > > > > > > Keith. > > > > > > *** pgsql/src/bin/initdb/initdb.sh Fri Jun 9 18:09:51 2000 > > > --- /usr/local/pgsql/src/bin/initdb/initdb.sh Sat Jun 10 00:07:07 2000 > > > *************** > > > *** 523,529 **** > > > usename, \ > > > usesysid, \ > > > usecreatedb, \ > > > ! \ > > > uselocktable, \ > > > usetrace, \ > > > usesuper, \ > > > --- 523,529 ---- > > > usename, \ > > > usesysid, \ > > > usecreatedb, \ > > > ! usecreatetable, \ > > > uselocktable, \ > > > usetrace, \ > > > usesuper, \ > > > > > > > > > > > > > > -- > Peter Eisentraut Sernanders v?g 10:115 > peter_e@gmx.net 75262 Uppsala > http://yi.org/peter-e/ Sweden > > -- Bruce Momjian | http://www.op.net/~candle 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, Pennsylvania19026
[ Charset ISO-8859-1 unsupported, converting... ] > Um, excuse me. Any changes to the format of pg_shadow will break > pg_dumpall, therefore this needs to be hold back until next release. > Woo, hoo. We have triggers and constraints on COPY. We could do the default values that way. Seems DEFAULT is not activated in COPY. I knew there was some limitation in COPY. test=> create table test(x int, y int default 5);CREATEtest=> copy test from '/tmp/x';COPYtest=> select * from test; x |y ---+--- 1 | (1 row) Can someone suggest a clean solution for COPY? Seems we have triggers and constraints. -- Bruce Momjian | http://www.op.net/~candle 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, Pennsylvania19026
Peter Eisentraut <peter_e@gmx.net> writes:
> Um, excuse me. Any changes to the format of pg_shadow will break
> pg_dumpall, therefore this needs to be hold back until next release.
We are going to have to improve pg_dumpall sooner or later, aren't we?
Loading pg_shadow and pg_group by direct COPY just won't do.
But you're right, this patch will have to be reversed out until a
more robust pg_dumpall has been out there for at least one release.
regards, tom lane
Bruce Momjian writes: > Well one solution is to have 7.1 use CREATE USER commands, then add the > pg_shadow columns in 7.2. That's the plan. > If we re-order the new columns to be at the end, those columns will load > in with NULL's. > > We could then modify the user code to make default for NULL values in > the new columns. I'm not sure, that would break the basic line of error checking in COPY. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
[ Charset ISO-8859-1 unsupported, converting... ] > Bruce Momjian writes: > > > Well one solution is to have 7.1 use CREATE USER commands, then add the > > pg_shadow columns in 7.2. > > That's the plan. > > > If we re-order the new columns to be at the end, those columns will load > > in with NULL's. > > > > We could then modify the user code to make default for NULL values in > > the new columns. > > I'm not sure, that would break the basic line of error checking in COPY. It would be active only for pg_shadow and no other table. However, I see that having not enough column in COPY fills the rest with NULL and does not report an error. -- Bruce Momjian | http://www.op.net/~candle 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, Pennsylvania19026
[ Charset ISO-8859-1 unsupported, converting... ] > Bruce Momjian writes: > > > > I'm not sure, that would break the basic line of error checking in COPY. > > > > It would be active only for pg_shadow and no other table. However, I > > see that having not enough column in COPY fills the rest with NULL and > > does not report an error. > > The problem remains that this change is conceptually questionable in the > first place. > OK, I have backed out the changes. We can always use them later if we wish. -- Bruce Momjian | http://www.op.net/~candle 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, Pennsylvania19026
Bruce Momjian writes: > > I'm not sure, that would break the basic line of error checking in COPY. > > It would be active only for pg_shadow and no other table. However, I > see that having not enough column in COPY fills the rest with NULL and > does not report an error. The problem remains that this change is conceptually questionable in the first place. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I'm not sure, that would break the basic line of error checking in COPY.
> It would be active only for pg_shadow and no other table. However, I
> see that having not enough column in COPY fills the rest with NULL and
> does not report an error.
I believe that's a bug in COPY, actually: it should complain if you
don't supply the right number of columns.
regards, tom lane