Message-ID: <138d50cd8d9617469922eb0017956a3610089064.camel@cybertec.at>
Subject: Re: proposal: schema variables
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Bruce Momjian <bruce@momjian.us>, Daniel Gustafsson <daniel@yesql.se>
Cc: Marcos Pegoraro <marcos@f10.com.br>, Pavel Stehule
 <pavel.stehule@gmail.com>,  jian he <jian.universality@gmail.com>, Dmitry
 Dolgov <9erthalion6@gmail.com>, Erik Rijkers	 <er@xs4all.nl>, Michael
 Paquier <michael@paquier.xyz>, Amit Kapila	 <amit.kapila16@gmail.com>,
 DUVAL REMI <REMI.DUVAL@cheops.fr>, PostgreSQL Hackers
 <pgsql-hackers@lists.postgresql.org>
Date: Tue, 20 May 2025 22:36:54 +0200
In-Reply-To: <aCzl0SQYGTBJfdtY@momjian.us>
References: 
	<CAFj8pRC_2tHski1K4hUMZm0+T4y7na4d8hwgMMF7Y0MXhfUhbg@mail.gmail.com>
	 <CAB-JLwaOdMQN838Fy2r2qZLTExfJp0zcjQjmOFVRXhW_-uDNVw@mail.gmail.com>
	 <CAFj8pRArtw+Qqzk+Zf2NxjgO=paCBdc54eEma+MsVwtx3j7Atg@mail.gmail.com>
	 <CAFj8pRAK_8ym1J=SAdin-vtL0PAachXgjWgU3QrhzinRdBX2sw@mail.gmail.com>
	 <CAFj8pRAx-Gb9Ux825cxGNm38qQUOrij1GY6erPRaQ=cpqfiX7g@mail.gmail.com>
	 <CAFj8pRCEjG005L=1vGbir-odYdcYxByOAeFVJ_K9eRcRF=MbNQ@mail.gmail.com>
	 <aCyYHXhAjXOUPvLO@momjian.us>
	 <CAB-JLwY2-Hm_SYbj2td_VKuU8awCwgDr-sOtjHRE2C-Sgg_pFg@mail.gmail.com>
	 <aCywNzDx2J3jrY1-@momjian.us>
	 <41D2EE98-224D-4B43-9F8B-127525A99CD7@yesql.se>
	 <aCzl0SQYGTBJfdtY@momjian.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.1 (3.56.1-1.fc42) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/138d50cd8d9617469922eb0017956a3610089064.camel%40cybertec.at>
Precedence: bulk

On Tue, 2025-05-20 at 16:28 -0400, Bruce Momjian wrote:
> On Tue, May 20, 2025 at 08:47:36PM +0200, Daniel Gustafsson wrote:
> > > On 20 May 2025, at 18:39, Bruce Momjian <bruce@momjian.us> wrote:
> > > My only point is that we should only be using email lists for work th=
at
> > > is being actively worked on to be added to community Postgres.  There
> > > has been talk of a trimmed-down version of this being applied, but I
> > > don't see any work in that direction.
> > >=20
> > > This patch should be moved to a separate location where perhaps peopl=
e
> > > can subscribe to updates when they are posted, perhaps github.
> >=20
> > As a project with no roadmap governed by open forum consensus I don't t=
hink we
> > have any right to tell community members what they can or cannot work o=
n here,
> > any technical discussion which conforms with our published policies sho=
uld be
> > welcome.  If Pavel want's to continue rebasing his patchset here then h=
e has,
> > IMHO, every right to do so.
> >=20
> > Whether or not a committer will show interest at some point is another =
thing,
> > but we are seeing a very good role-model for taking responsibility for =
ones
> > work here at the very least =3D)
>=20
> Well, we do have a right, e.g., we would not allow someone to repeatedly
> post patches for a Postgres extension we don't manage, or the jdbc
> driver.  I also don't think we would allow someone to continue posting
> patches for a feature we have decided to reject, and I think we have
> decided to reject the patch in in its current form.  I think we might
> accept a trimmed-down version, but I don't see the patch moving in that
> direction.
>=20
> Now, of course, if I am the only one who feels this way, I can suppress
> these emails on my end.

In my opinion, this patch set is adding something that would be valuable to
have in core.

If no committer intends to pick it up and commit it, I think the proper
action would be to step up and reject the patch set, not complain about the
insistence of the author.

Yours,
Laurenz Albe