Thread: pg_dumpall

pg_dumpall

From
"Kardos, Dr. Andreas"
Date:
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

Re: [BUGS] pg_dumpall

From
Peter Eisentraut
Date:
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

Re: [BUGS] pg_dumpall

From
Peter Eisentraut
Date:
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

Re: [BUGS] pg_dumpall

From
"Kardos, Dr. Andreas"
Date:
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

Re: [BUGS] pg_dumpall

From
Bruce Momjian
Date:
[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

Re: [BUGS] pg_dumpall

From
Bruce Momjian
Date:
[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

Re: [BUGS] pg_dumpall

From
Peter Eisentraut
Date:
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

Re: [BUGS] pg_dumpall

From
Peter Eisentraut
Date:
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