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

From Thomas Munro
Subject Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Date
Msg-id CA+hUKGKjZbAg3U8EMPR7dn3oF6LQbXVV28mMe4JvFJy5uVbssw@mail.gmail.com
Whole thread Raw
In response to Re: pg_tablespace_location() failure with allow_in_place_tablespaces  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_tablespace_location() failure with allow_in_place_tablespaces  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Thu, Mar 17, 2022 at 7:18 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Thu, Mar 17, 2022 at 04:34:30PM +1300, Thomas Munro wrote:
> > I think what Horiguchi-san was pointing out above is that you need to
> > enable the GUC *and* say LOCATION '', which the new paragraph doesn't
> > capture.  What do you think about this:
> >
> > A path relative to the data directory is returned for in-place
> > tablespaces (see <xref ...>).
>
> An issue I have with this wording is that we give nowhere in the docs
> an explanation of about the term "in-place tablespace", even if it can
> be guessed from the name of the GUC.

Maybe we don't need this paragraph at all.  Who is it aimed at?

> Another idea would be something like that:
> "A relative path to the data directory is returned for tablespaces
> created with an empty location string specified in the CREATE
> TABLESPACE query when allow_in_place_tablespaces is enabled (see link
> blah)."
>
> But perhaps that's just me being overly pedantic :p

I don't really want to spill details of this developer-only stuff onto
more manual sections...  It's not really helping users if we confuse
them with irrelevant details of a feature they shouldn't be using, is
it?  And the existing treatment "Returns the file system path that
this tablespace is located in" is not invalidated by this special
case, so maybe we shouldn't mention it?



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Unhyphenation of crash-recovery
Next
From: Amit Kapila
Date:
Subject: Re: Logical replication timeout problem