pg_dumpall

Started by Kardos, Dr. Andreasabout 26 years ago8 messagesbugs
Jump to latest
#1Kardos, Dr. Andreas
kardos@repas-aeg.de

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

#2Peter Eisentraut
peter_e@gmx.net
In reply to: Kardos, Dr. Andreas (#1)
Re: [BUGS] pg_dumpall

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

#3Peter Eisentraut
peter_e@gmx.net
In reply to: Kardos, Dr. Andreas (#1)
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

Attachments:

pg_dumpalltext/plain; CHARSET=US-ASCII; NAME=pg_dumpallDownload
#4Kardos, Dr. Andreas
kardos@repas-aeg.de
In reply to: Peter Eisentraut (#3)
Re: [BUGS] pg_dumpall

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

#5Bruce Momjian
bruce@momjian.us
In reply to: Kardos, Dr. Andreas (#1)
Re: [BUGS] pg_dumpall

[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
#6Bruce Momjian
bruce@momjian.us
In reply to: Peter Eisentraut (#2)
Re: [BUGS] pg_dumpall

[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
#7Peter Eisentraut
peter_e@gmx.net
In reply to: Bruce Momjian (#6)
Re: [BUGS] pg_dumpall

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

#8Peter Eisentraut
peter_e@gmx.net
In reply to: Kardos, Dr. Andreas (#4)
Re: [BUGS] pg_dumpall

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