Re: Re: [COMMITTERS] pgsql: Make initdb's suggested "pg_ctl start" command line more reliabl
От | Peter Eisentraut |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Make initdb's suggested "pg_ctl start" command line more reliabl |
Дата | |
Msg-id | c7a3faee-aede-1d7a-808d-491244a8ba7f@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Make initdb's suggested "pg_ctl start" command line more reliabl (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Make initdb's suggested "pg_ctl start" command line more reliabl
|
Список | pgsql-hackers |
On 9/6/16 1:08 PM, Tom Lane wrote: >> As just mentioned elsewhere, this accidentally introduces a failure if >> > the PostgreSQL installation path contains LF/CR, because of the use of >> > appendShellString(). > I think that's intentional, not accidental. What actual use case is > there for allowing such paths? There probably isn't one. But we ought to be introducing this change in a more intentional and consistent way. For example, pg_basebackup has no such restriction. So using pg_basebackup, then promote, then pg_upgrade will (probably) fail now for some paths. More generally, I'm concerned that appendShellString() looks pretty attractive for future use. It's not inconceivable that someone will want to use it for say calling pg_dump from pg_dumpall or pg_upgrade at some point, and then maybe we'll accidentally disallow LF/CR in tablespace names, say. Also, if we're concerned about the potential for confusion that these characters can cause, maybe we should be disallowing more control characters in similar places. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: