Horton

Re: Schema variables - new implementation for Postgres 15 (typo)

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Erik Rijkers <er@xs4all.nl>, Sergey Shinderuk <s.shinderuk@postgrespro.ru>, Tomas Vondra <tomas.vondra@enterprisedb.com>, dean.a.rasheed@gmail.com, joel@compiler.org, pgsql-hackers@lists.postgresql.org
Date: 2023-01-07T07:09:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow underscores in integer and numeric constants.

  2. Remove special outfuncs/readfuncs handling of RangeVar.catalogname.

  3. Remove extra space from dumped ALTER DEFAULT PRIVILEGES.

  4. Create FKs properly when attaching table as partition

  5. psql: improve tab-complete's handling of variant SQL names.

Attachments

> > It can be used only
> > from extensions, where is ensured so a) the value is not changed, b) and
> in
> > a lifetime of returned value is not called any query or any expression
> that
> > can change the value of this variable. I fixed this code and I enhanced
> > comments. I am not sure if this function should not be removed. It is not
> > used by backend, but it can be handy for extensions - it reduces possible
> > useless copy.
>
> Hmm, how safe is it for third-party code to access the stored data directly
> rather than a copy?  If it makes extension fragile if they're not careful
> enough with cache invalidation, or even give them a way to mess up with the
> data directly, it's probably not a good idea to provide such an API.
>

ok, I removed it






>
>
> > > I'm also wondering if there should be additional tests based on the
> last
> > > scenario reported by Dmitry? (I don't see any new or similar test, but
> I
> > > may
> > > have missed it).
> > >
> >
> > The scenario reported by Dmitry is in tests already.
>
> Oh, so I missed it sorry about that.  I did some testing using
> debug_discard_cache in the past and didn't run into this issue, so it's
> probably due to a more recent changes or before such a test was added.
>
> > I am not sure if I
> > have to repeat it with active debug_discard_cache. I expect this mode
> will
> > be activated in some testing environments.
>
> Yes, some buildfarm animal are configured to run with various
> debug_discard_caches setting so it's not needed to override it in some
> tests
> (it makes testing time really slow, which will be annoying for everyone
> including old/slow buildfarm animals).
>
> > I have no idea how to simply emulate this issue without
> > debug_discard_caches on 1. It is necessary to raise the sinval message
> > exactly when the variable is checked against system catalogue.
>
> Manually testing while setting locally debug_discard_cache should be
> enough.
>
> > updated patches attached
>
> Thanks!
>

I thank you

Pavel