Re: pg_tablespace_location() failure with allow_in_place_tablespaces - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Date
Msg-id YjBct+3THwDVMeO6@paquier.xyz
Whole thread Raw
In response to Re: pg_tablespace_location() failure with allow_in_place_tablespaces  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: pg_tablespace_location() failure with allow_in_place_tablespaces
List pgsql-hackers
On Tue, Mar 15, 2022 at 03:55:56PM +1300, Thomas Munro wrote:
> 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.

So, which one of a relative path or an absolute path do you think
would be better for the user?  My preference tends toward the relative
path, as we know that all those tablespaces stay in pg_tblspc/ so one
can make the difference with normal tablespaces more easily.  The
barrier is thin, though :p
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Add checkpoint and redo LSN to LogCheckpointEnd log message
Next
From: Michael Paquier
Date:
Subject: Re: Assert in pageinspect with NULL pages