Re: pg_tablespace_location() failure with allow_in_place_tablespaces
От | Thomas Munro |
---|---|
Тема | Re: pg_tablespace_location() failure with allow_in_place_tablespaces |
Дата | |
Msg-id | CA+hUKG+LyP3paszHv-a2FCH_fOPgO+eLtahwwrCD0fgkfPqMVA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_tablespace_location() failure with allow_in_place_tablespaces (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pg_tablespace_location() failure with allow_in_place_tablespaces
|
Список | pgsql-hackers |
On Tue, Mar 15, 2022 at 2:50 PM Michael Paquier <michael@paquier.xyz> wrote: > On Tue, Mar 15, 2022 at 02:33:17PM +1300, Thomas Munro wrote: > > As for the complaint about pg_tablespace_location() failing, would it > > be better to return an empty string? That's what was passed in as > > LOCATION. Something like the attached. > > Hmm, I don't think so. The point of the function is to be able to > know the location of a tablespace at SQL level so as we don't have any > need to hardcode its location within any external tests (be it a > pg_regress test or a TAP test) based on how in-place tablespace paths > are built in the backend, so I think that we'd better report either a > relative path from data_directory or an absolute path, but not an > empty string. > > In any case, I'd suggest to add a regression test. What I have sent > upthread would be portable enough. Fair enough. No objections here.
В списке pgsql-hackers по дате отправления: