agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Noah Misch <noah@leadboat.com>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Andy Fan <zhihuifan1213@163.com>
Cc: pgsql-hackers@postgresql.org, Michael Paquier <michael.paquier@gmail.com>
Subject: Re: GetRelationPath() vs critical sections
Date: Thu, 20 Feb 2025 11:03:15 -0800
Message-ID: <20250220190315.ad.nmisch@google.com> (raw)
In-Reply-To: <ci7okfz2v5cxnkmwfuixspmdu37swyr54xakqnkat7yweqkkhy@sw6rj32l6rz4>
References: <h3a7ftrxypgxbw6ukcrrkspjon5dlninedwb5udkrase3rgqvn@3cokde6btlrl>
<CA+hUKGLAznzOPc34+qYAumJz+P66sc58XkM+68NO=xstoVwQ6A@mail.gmail.com>
<874j5plwdk.fsf@163.com>
<xeri5mla4b5syjd5a25nok5iez2kr3bm26j2qn4u7okzof2bmf@kwdh2vf7npra>
<CA+hUKGLNk5ambjhaPo_BhT3x=6-ykdamVA3CZ+i06gNXH6++sQ@mail.gmail.com>
<ci7okfz2v5cxnkmwfuixspmdu37swyr54xakqnkat7yweqkkhy@sw6rj32l6rz4>
On Thu, Feb 20, 2025 at 12:40:57PM -0500, Andres Freund wrote:
> On 2025-02-20 14:00:10 +1300, Thomas Munro wrote:
> > On Wed, Feb 19, 2025 at 3:35 PM Andres Freund <andres@anarazel.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!
Works for me.
> 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.
PGXN has few hits, and some of these are false positives or otherwise
irrelevant:
$ grep -re '[^.]\(relpath[a-z]*\|GetRelationPath\)(' | sed 's/-[^:]*/:/'|sort -u
db2_fdw::extern char *GetRelationPath(Oid dbNode, Oid spcNode, Oid relNode,
jsoncdc:: pub fn GetRelationPath(dbNode: Oid, spcNode: Oid, relNode: Oid,
openbarter:: path = relpath(frame.f_code.co_filename, refdir) # relative to refdir
pg_bulkload::#define relpath(rnode, forknum) relpath((rnode))
pg_bulkload:: fname = relpath(bknode, MAIN_FORKNUM);
pg_bulkload:: fname = relpath(rnode, MAIN_FORKNUM);
pg_repack::#define relpath(rnode, forknum) relpath((rnode))
plv8:: def _to_relpath(self, abspath, _):
plv8:: def _to_relpath(self, abspath, test_root):
plv8:: yield self._to_relpath(abspath, test_root)
tblsize_nolock:: relationpath = relpath(*rfn);
> Which makes me think it's not worth having a backward compatible interface?
Agreed. Even if 100% of those matches had to change, that's below standard
level of breakage for a major release.
view thread (19+ messages) latest in thread
Message-ID: <20250220190315.ad.nmisch@google.com>
Permalink: ../20250220190315.ad.nmisch@google.com/
Also on: postgresql.org/message-id/20250220190315.ad.nmisch@google.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, andres@anarazel.de, thomas.munro@gmail.com, zhihuifan1213@163.com, michael.paquier@gmail.com
Subject: Re: GetRelationPath() vs critical sections
In-Reply-To: <20250220190315.ad.nmisch@google.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox