Re: pgsql/src/bin/pg_dump pg_dumpall.sh
От | Bruce Momjian |
---|---|
Тема | Re: pgsql/src/bin/pg_dump pg_dumpall.sh |
Дата | |
Msg-id | 200204112103.g3BL31A03332@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql/src/bin/pg_dump pg_dumpall.sh (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql/src/bin/pg_dump pg_dumpall.sh
|
Список | pgsql-committers |
Tom Lane wrote: > momjian@postgresql.org (Bruce Momjian - CVS) writes: > > Modified files: > > src/bin/pg_dump: pg_dumpall.sh > > > Log message: > > Fix pg_upgrade to handle dbnames, user/group names with spaces. > > I think it's illusory to imagine that this fixes the issue. Unless > "read"'s behavior is more tightly specified than I think, you are still > gonna have trouble with leading, trailing, or consecutive blanks. Yes, it does fail on leading/trailing spaces, but it is better than it was before. > I'm also concerned that you've opened up portability issues concerning > newlines embedded in shell literals (eg, does that sed command portably > do what you think?). I certainly think so. It is: echo "a b c" | sed 's/ /\ /g' outputs: a b c Embedding backslash-n in 'sed' is a portability problem. Clearly read has problems: #$ read X a b #$ echo $X a b I could so IFS="newline" to handle the space issue. Let me try that. -- Bruce Momjian | http://candle.pha.pa.us 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
В списке pgsql-committers по дате отправления: