Обсуждение: pg_dumpall
The pg_dumpall script is not compatible with 7.0 psql and createdb. 1. pgsql -l delivers a different output (Owner instead of User ID). Therefore in the following command "usesysid" has to be replaced by "usename": POSTGRES_USER="`echo \" \ select usename \ from pg_shadow \ where usesysid = $DBUSERID; \" | \ psql -A -q -t template1`" 2. createdb -help in the following line tries to connect the host "elp". if createdb -help|grep encoding >/dev/null then echo "create database $DATABASE with encoding='`pg_encoding $ENCODING`';" else echo "create database $DATABASE;" fi Unfortunately it is not sufficient to use createdb --help|grep encoding because the word "encoding" is always present in the usage message now. 3. QNX4 only: The double quotes in POSTGRES_USER="`echo \" \ etc. must not be escaped with a backslash. Unfortunately I haven't found a simple solution working on all platforms. Thats why I am not sending a patch. Andreas Kardos
Kardos, Dr. Andreas writes: > The pg_dumpall script is not compatible with 7.0 psql and createdb. Darn me! I'll look into this. Some of the stuff in pg_dumpall can be solved more elegantly by now. > 1. pgsql -l delivers a different output (Owner instead of User ID). > Therefore in the following command "usesysid" has to be replaced by > "usename": > > POSTGRES_USER="`echo \" \ > select usename \ > from pg_shadow \ > where usesysid = $DBUSERID; \" | \ > psql -A -q -t template1`" Huh? Doesn't it look like that now? > 2. createdb -help in the following line tries to connect the host "elp". > > if createdb -help|grep encoding >/dev/null > then > echo "create database $DATABASE with encoding='`pg_encoding $ENCODING`';" > else > echo "create database $DATABASE;" > fi I'd be inclined to say that you can leave off the encoding phrase if the encoding is 'SQL_ASCII' (or 0). That is always the case if you don't use multibyte. > 3. QNX4 only: The double quotes in > > POSTGRES_USER="`echo \" \ > > etc. must not be escaped with a backslash. Technically, it should just work without them (the backslash, that is). Then again, I'm not the greatest portable shell programmer. I'll see what I can do. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Kardos, Dr. Andreas writes:
> The pg_dumpall script is not compatible with 7.0 psql and createdb.
I've fixed up the logic and it seems to work but I attach it here so you
can try it because I don't have a reasonably-sized database around right
now.
Regarding the quoting, I'm inclined to say that
FOO="`echo "$BAR"`"
style constructs are okay but I'd like to hear from anyone that thinks (or
knows) otherwise. At first I thought
echo "$BAR" | read FOO
might do the trick but for some reason I couldn't get it to work.
I'd be interested in a definite solution to this because it seems some
other shell scripts in the tree suffer from similar problems.
> 1. pgsql -l delivers a different output (Owner instead of User ID).
> 2. createdb -help in the following line tries to connect the host "elp".
> 3. QNX4 only: The double quotes in
>
> POSTGRES_USER="`echo \" \
>
> etc. must not be escaped with a backslash. Unfortunately I haven't found a
> simple solution working on all platforms. Thats why I am not sending a
> patch.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
1. The version of pg_dumpall you have mailed works fine under QNX4.
I see only one minor matter which could be improved:
Since PATHNAME contains already a slash at the end a construct like
${PATHNAME}/psql
expands to
/usr/local/pgsql/bin//psql
but the unnecessary slash doesn't disturb of course.
2. FOO="`echo "$BAR"`"
This construct I have found working on QNX4, Digital Unix, SunOS and Linux.
But the problem seems not to be so simple. After removing the backslashes
from the old pg_dumpall it didn't work any more on Digital Unix! So the
escaped double quotes make sense somewhere in some context.
The new pg_dumpall should be tested on some more platforms. QNX4 is rather
an exotic one. Unfortunately I have an 7.0 installation only on QNX4 here.
Andreas Kardos
-----Ursprüngliche Nachricht-----
Von: Peter Eisentraut <peter_e@gmx.net>
An: Kardos, Dr. Andreas <kardos@repas-aeg.de>
Cc: <pgsql-bugs@postgreSQL.org>
Gesendet: Sonntag, 5. März 2000 00:00
Betreff: Re: [BUGS] pg_dumpall
Kardos, Dr. Andreas writes:
> The pg_dumpall script is not compatible with 7.0 psql and createdb.
I've fixed up the logic and it seems to work but I attach it here so you
can try it because I don't have a reasonably-sized database around right
now.
Regarding the quoting, I'm inclined to say that
FOO="`echo "$BAR"`"
style constructs are okay but I'd like to hear from anyone that thinks (or
knows) otherwise. At first I thought
echo "$BAR" | read FOO
might do the trick but for some reason I couldn't get it to work.
I'd be interested in a definite solution to this because it seems some
other shell scripts in the tree suffer from similar problems.
> 1. pgsql -l delivers a different output (Owner instead of User ID).
> 2. createdb -help in the following line tries to connect the host "elp".
> 3. QNX4 only: The double quotes in
>
> POSTGRES_USER="`echo \" \
>
> etc. must not be escaped with a backslash. Unfortunately I haven't found a
> simple solution working on all platforms. Thats why I am not sending a
> patch.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
[Charset iso-8859-1 unsupported, filtering to ASCII...] > The pg_dumpall script is not compatible with 7.0 psql and createdb. > > 1. pgsql -l delivers a different output (Owner instead of User ID). > Therefore in the following command "usesysid" has to be replaced by > "usename": > > POSTGRES_USER="`echo \" \ > select usename \ > from pg_shadow \ > where usesysid = $DBUSERID; \" | \ > psql -A -q -t template1`" Fixed. > > 2. createdb -help in the following line tries to connect the host "elp". > > if createdb -help|grep encoding >/dev/null > then > echo "create database $DATABASE with encoding='`pg_encoding $ENCODING`';" > else > echo "create database $DATABASE;" > fi Thanks. I changed it to run pg_encoding and see if it existed. Patch applied. > > Unfortunately it is not sufficient to use > > createdb --help|grep encoding > > because the word "encoding" is always present in the usage message now. > > 3. QNX4 only: The double quotes in > > POSTGRES_USER="`echo \" \ > > etc. must not be escaped with a backslash. Unfortunately I haven't found a > simple solution working on all platforms. Thats why I am not sending a > patch. Wow, that is pretty broken if it can't handle that. -- 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, filtering to ASCII...] > Kardos, Dr. Andreas writes: > > > The pg_dumpall script is not compatible with 7.0 psql and createdb. > > Darn me! I'll look into this. Some of the stuff in pg_dumpall can be > solved more elegantly by now. > > > 1. pgsql -l delivers a different output (Owner instead of User ID). > > Therefore in the following command "usesysid" has to be replaced by > > "usename": > > > > POSTGRES_USER="`echo \" \ > > select usename \ > > from pg_shadow \ > > where usesysid = $DBUSERID; \" | \ > > psql -A -q -t template1`" > > Huh? Doesn't it look like that now? He wants it to be usename. > > > > 2. createdb -help in the following line tries to connect the host "elp". > > > > if createdb -help|grep encoding >/dev/null > > then > > echo "create database $DATABASE with encoding='`pg_encoding $ENCODING`';" > > else > > echo "create database $DATABASE;" > > fi > > I'd be inclined to say that you can leave off the encoding phrase if the > encoding is 'SQL_ASCII' (or 0). That is always the case if you don't use > multibyte. I fixed that. pg_encoding is only installed if multibyte is enabled. > > > > 3. QNX4 only: The double quotes in > > > > POSTGRES_USER="`echo \" \ > > > > etc. must not be escaped with a backslash. > > Technically, it should just work without them (the backslash, that is). > Then again, I'm not the greatest portable shell programmer. > > I'll see what I can do. His end sounds pretty broken. May not be worth a fix. -- 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
Bruce Momjian writes: > > > 3. QNX4 only: The double quotes in > > > > > > POSTGRES_USER="`echo \" \ > > > > > > etc. must not be escaped with a backslash. > > > > Technically, it should just work without them (the backslash, that is). > > Then again, I'm not the greatest portable shell programmer. > > > > I'll see what I can do. > > His end sounds pretty broken. May not be worth a fix. Actually his end is right according to my reading of the manual. Of course that's the bash manual. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Kardos, Dr. Andreas writes:
> 2. FOO="`echo "$BAR"`"
>
> This construct I have found working on QNX4, Digital Unix, SunOS and Linux.
> But the problem seems not to be so simple. After removing the backslashes
> from the old pg_dumpall it didn't work any more on Digital Unix! So the
> escaped double quotes make sense somewhere in some context.
I'm inclined to say that it should work but probably doesn't everywhere.
But I need to fix this because all the scripts currently contain ``
sequences that need to be double-quoted because otherwise they will fail
if the installation path contains whitespace. (See those ${PATHNAME}
things.)
For now I might have to resort to yanking that PATHNAME logic again and
use the new pg_dumpall since it appears to magically work.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden