Thread: Re: proposal: schema variables

Re: proposal: schema variables

From
Laurenz Albe
Date:
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 that
> > > 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.
> > >
> > > This patch should be moved to a separate location where perhaps people
> > > can subscribe to updates when they are posted, perhaps github.
> >
> > As a project with no roadmap governed by open forum consensus I don't think we
> > have any right to tell community members what they can or cannot work on here,
> > any technical discussion which conforms with our published policies should be
> > welcome.  If Pavel want's to continue rebasing his patchset here then he has,
> > IMHO, every right to do so.
> >
> > 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 =)
>
> 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.
>
> 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



Re: proposal: schema variables

From
Bruce Momjian
Date:
On Tue, May 20, 2025 at 10:36:54PM +0200, Laurenz Albe wrote:
> On Tue, 2025-05-20 at 16:28 -0400, Bruce Momjian wrote:
> > 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.
> > 
> > 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.

Are you saying I should not complain until we have officially rejected
the patch set?  If we officially reject it, the patch author would no
longer post it?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.



Re: proposal: schema variables

From
Pavel Stehule
Date:


út 20. 5. 2025 v 23:07 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
On Tue, May 20, 2025 at 10:36:54PM +0200, Laurenz Albe wrote:
> On Tue, 2025-05-20 at 16:28 -0400, Bruce Momjian wrote:
> > 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.
> >
> > 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.

Are you saying I should not complain until we have officially rejected
the patch set?  If we officially reject it, the patch author would no
longer post it?

I'll respect committers. I really don't want to worry people in the community. It is not my way, and I am sorry.

I think this is an important feature - for some group of developers, and then I push my energy and time for this.
On the other hand, I accept that there is a lot of work that is important for a wider group of users. So it is. Unfortunately,
without parser's hooks this feature cannot be implemented as an extension. But parser's hooks was proposed,
and rejected, so there is no other possibility, how to do it. More - implementation of this feature as an extension is not
best way.

regards

Pavel






 

--
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Re: proposal: schema variables

From
Laurenz Albe
Date:
On Tue, 2025-05-20 at 17:06 -0400, Bruce Momjian wrote:
> f 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.
>
> Are you saying I should not complain until we have officially rejected
> the patch set?  If we officially reject it, the patch author would no
> longer post it?

No, you are free to complain, just as Pavel is free to keep his patch
set from rotting.  What I am trying to say is that rejecting the patch
set is the most effective way to complain.

The current state is that Pavel keeps the patch set alive, and occasionally
people review it or parts of it.  But no committer is accepting or rejecting
it, so the patch set remains in limbo.  This annoys you, and it is certainly
not a happy experience for the author.  Rejection is not nice, but at least
it would make it easier for Pavel to move on and spend his energy elsewhere.

Yours,
Laurenz Albe



Re: proposal: schema variables

From
Pavel Stehule
Date:


st 21. 5. 2025 v 8:27 odesílatel Laurenz Albe <laurenz.albe@cybertec.at> napsal:
On Tue, 2025-05-20 at 17:06 -0400, Bruce Momjian wrote:
> f 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.
>
> Are you saying I should not complain until we have officially rejected
> the patch set?  If we officially reject it, the patch author would no
> longer post it?

No, you are free to complain, just as Pavel is free to keep his patch
set from rotting.  What I am trying to say is that rejecting the patch
set is the most effective way to complain.

The current state is that Pavel keeps the patch set alive, and occasionally
people review it or parts of it.  But no committer is accepting or rejecting
it, so the patch set remains in limbo.  This annoys you, and it is certainly
not a happy experience for the author.  Rejection is not nice, but at least
it would make it easier for Pavel to move on and spend his energy elsewhere.

Rejection is not nice, but it can be, and if it will be, I hope, there will be more cleaner
status if we want this feature or not, and if possibly want this feature, what we expect.

This feature can be designed differently in respect to some priorities. But without known
priorities, any patch, proposal can end in the same state.

Regards

Pavel

 

Yours,
Laurenz Albe

Re: proposal: schema variables

From
Bruce Momjian
Date:
On Wed, May 21, 2025 at 07:15:27AM +0200, Pavel Stehule wrote:
> út 20. 5. 2025 v 23:07 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
>     > 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.
> 
>     Are you saying I should not complain until we have officially rejected
>     the patch set?  If we officially reject it, the patch author would no
>     longer post it?
> 
> I'll respect committers. I really don't want to worry people in the community.
> It is not my way, and I am sorry.

I realize I am being the bad guy by asking these questions, but I don't
think it is good for the project to get distracted with a feature that
isn't progressing, and it is unpleasant for an author to keep working on
something with no clear direction from the community.  I am happy to
learn that progress is being made.

I see this feature being first proposed in 2012:

    https://www.postgresql.org/message-id/flat/CAFj8pRDdk_4E8HiffbVOfk97iR%2BSLFoZpRT4D2nTE89YU-hQrg%40mail.gmail.com

and the first question was:

    I don't really see what we can do with this that we can't do
    without this.

Now, I think we have answered that question, and gotten closer to seeing
the complexities of adding this feature.

I am asking that, given its age, we more clearly direct this patch,
either toward completion or rejection.

> I think this is an important feature - for some group of developers, and then I
> push my energy and time for this.
> On the other hand, I accept that there is a lot of work that is important for a
> wider group of users. So it is. Unfortunately,
> without parser's hooks this feature cannot be implemented as an extension. But
> parser's hooks was proposed,
> and rejected, so there is no other possibility, how to do it. More -
> implementation of this feature as an extension is not
> best way.

I will reply to this in my next email.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.