Re: fairywren is generating bogus BASE_BACKUP commands

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: fairywren is generating bogus BASE_BACKUP commands
Дата
Msg-id CA+TgmobX4Yvc8eV+N3MAc7nMyQ102sgcu=WpD0wr93mx6Gdd8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: fairywren is generating bogus BASE_BACKUP commands  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: fairywren is generating bogus BASE_BACKUP commands  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, Jan 23, 2022 at 12:20 PM Andrew Dunstan <andrew@dunslane.net> wrote:

> It's not as simple as that :-(  But you're on the right track. My
> suggestion above doesn't work.
>
> The rule for paths is: when you're passing a path to an external program
> that's not msys aware (typically, one of our build artefacts like psql
> or pg_basebackup) it needs to be a native path. But when you're passing
> it to a perl function (e.g. mkdir) or to an external program that's msys
> aware it needs to be a virtual path, i.e. one not mangled by perl2host.
>
> Some recent commits to this file especially have not obeyed this rule.
> Here's a patch that does it consistently for the whole file. I have
> tested it on a system very like fairywren, and the test passes.

I can't understand how this would prevent server:/what/ever from
getting turned into server;c:\what\ever. But if it does, great!

Maybe we need to have a README in the tree somewhere that tries to
explain this. Or maybe we should make our build artifacts msys-aware,
if that's possible, so that this just works. Or maybe supporting msys
is not worth the trouble.

--
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Bogus duplicate command issued in pg_dump
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bogus duplicate command issued in pg_dump