Re: GetRelationPath() vs critical sections

Hi,

On 2025-02-20 14:00:10 +1300, Thomas Munro wrote:
> On Wed, Feb 19, 2025 at 3:35 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > After thinking about this for an embarassingly long time, I think there's
> > actually a considerably better answer for a case like this: A function that
> > returns a fixed-length string by value:
> >
> > - Compilers can fairly easily warn about on-stack values that goes out of
> > scope
> >
> > - Because we don't need to free the memory anymore, some code that that
> > previously needed to explicitly free the memory doesn't need to anymore
> > (c.f. AbortBufferIO()).
> >
> > - The max lenght isn't that long, so it's actually reasonably efficient,
> > likely commonly cheaper than psprintf.
>
> I like it!

Does anybody have opinions about whether we should keep a backward compatible
interface in place or not?

Via https://codesearch.debian.net/ I tried to look for
references.

Unfortunately I had to exclude "relpath" as there are just too many
independent hits, due to the python function of the same name. For
relpathperm(), relpathbackend(), GetRelationPath() there looks to be just
fincore. There also are two copies of our code, but those we don't need to
care about (libpg-query and ruby-pg-query), since they're just going to copy
the new code when updating.

I also looked for matches including relpath that had "fork" elsewhere in the
file, it's hard to see a potential use of relpath() not using fork in the
arguments or such.

Which makes me think it's not worth having a backward compatible interface?

Greetings,

Andres Freund