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, Pennsylvania 19026
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 convert the 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, Pennsylvania 19026[ 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);
CREATE
test=> copy test from '/tmp/x';
COPY
test=> 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, Pennsylvania 19026
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, Pennsylvania 19026Bruce 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
[ 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, Pennsylvania 19026Bruce 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