On Mon, Mar 24, 2025 at 9:00 AM Álvaro Herrera
wrote:
> Hello
>
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
> no new mechanism.
>
>
That reloption is already an enum and there is no GUC to defer to when the
va
В письме от понедельник, 24 марта 2025 г. 22:11:19 MSK пользователь Robert
Haas написал:
> I think that the answer here might be that Nikolay doesn't like this
> because it interacts badly with his "New [relation] options engine,"
There is no problem with adding isset_offset into "New [relation]
В письме от среда, 26 марта 2025 г. 17:42:23 MSK пользователь Robert Haas
написал:
> 1. We're talking about a minor deviation resulting in a very small
> amount of additional code. It's entirely unclear to me why anyone
> thinks this is a big deal either way, even if one accepts that the
> patch
On Mon, Mar 24, 2025 at 11:27:15PM +0300, Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 23:04:39 MSK пользователь Nathan
> Bossart написал:
>> But again, I don't see any strong reason why we must change all such
>> reloptions.
>
> Because code of the engine should be consiste
On Mon, Mar 24, 2025 at 10:12:05PM +0300, Nikolay Shaplov wrote:
> And second general idea: changing engine is bad, at least when you can manage
> without changing it.
You have asserted this a couple of times without providing any reasons why.
I know of no general project policy about changing th
On Mon, Mar 24, 2025 at 10:27 AM Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 20:09:23 MSK пользователь Nathan
> Bossart написал:
>
> > > You've just changed the whole engine, for what is seems to be an
> > > exceptional case, that can be solved via existing means.
> > I hav
On 2025-Mar-26, Nikolay Shaplov wrote:
> git blame reloptions.c | grep "Robert Haas" | wc -l
> 112
>
> git blame reloptions.c | grep Álvaro | wc -l
> 792
>
> For me Alvary is the keeper of the concept of reloption. And he sees
> difference. If he would said isset_offset is good, I will follow.
В письме от среда, 26 марта 2025 г. 21:43:42 MSK пользователь Robert Haas
написал:
> why is it worth arguing about?
I have full model of current reloptions and my patch unrolled in my head. They
have some harmony. (Mine has more harmony, but it is not the case).
isset_offset the way it is intr
On Wed, Mar 26, 2025 at 2:34 PM Nikolay Shaplov wrote:
> В письме от среда, 26 марта 2025 г. 21:16:20 MSK пользователь Robert Haas
> написал:
> > The reason why I felt that way is
> > because you were using what seemed to me to be very strong language
> > over what seemed to me to be a very minor
В письме от среда, 26 марта 2025 г. 21:16:20 MSK пользователь Robert Haas
написал:
> The reason why I felt that way is
> because you were using what seemed to me to be very strong language
> over what seemed to me to be a very minor issue.
Being not native speaker has it's own difficulties. Plus
On Wed, Mar 26, 2025 at 1:29 PM Nikolay Shaplov wrote:
> > What I'm upset about is that it feels to me like Nikolay is trying to
> > win the argument by yelling.
>
> I do not think it is fair. When votes are against you (and I did not ask
> anybody else's help for it) it turned out, that I am yell
On Wed, Mar 26, 2025 at 10:29 AM Nikolay Shaplov wrote:
> The only thing I am asking for: please keep code consistent. Better keep
> reloption core the way it was, but if it is not possible, then keep it
> consistent then.
>
Consistency at the expense of all else is a debatable position that wil
В письме от среда, 26 марта 2025 г. 18:41:13 MSK пользователь Robert Haas
написал:
> What I'm upset about is that it feels to me like Nikolay is trying to
> win the argument by yelling.
I do not think it is fair. When votes are against you (and I did not ask
anybody else's help for it) it turne
On Wed, Mar 26, 2025 at 08:09:53AM -0700, David G. Johnston wrote:
> I'm willing to say "I don't know why this is so very important to Nikolay,
> but I trust him that it is, and since my opinion isn't that strong and this
> isn't a big deal, so I will accommodate the person screaming that adding
>
On Wed, Mar 26, 2025 at 9:14 AM Nathan Bossart
wrote:
> FWIW one of the big reasons I didn't proceed with the enum approach
initially is because I worried that I'd end up in a similar discussion
> about how terrible _that_ approach is. When I look at that patch [0], I
> genuinely wonder if folk
On Wed, Mar 26, 2025 at 11:41:13AM -0400, Robert Haas wrote:
> What I'm upset about is that it feels to me like Nikolay is trying to
> win the argument by yelling. I don't want that to be the way we do
> things around here. I admit that sometimes it is, and I think that is
> bad, no matter who the
On Wed, Mar 26, 2025 at 8:41 AM Robert Haas wrote:
> Nathan has already had to spend a significant amount of time engaging
with this thread over what I think should be a complete non-event, and
> will probably have to spend more, and all that takes away from time
> that could, for example, be sp
On Wed, Mar 26, 2025 at 10:40 AM Nikolay Shaplov wrote:
> Then please, listen to a reason. If we add isset_offset, it will make code
> inconsistent, because it follow same purpose as unreachable default_value in
> other non boolean options. Having two conflicting ways to do same thing is a
> bad d
On Wed, Mar 26, 2025 at 11:10 AM David G. Johnston
wrote:
> I'm willing to say "I don't know why this is so very important to Nikolay,
> but I trust him that it is, and since my opinion isn't that strong and this
> isn't a big deal, so I will accommodate the person screaming that adding this
>
On Wed, Mar 26, 2025 at 7:42 AM Robert Haas wrote:
> On Wed, Mar 26, 2025 at 10:17 AM David G. Johnston
> wrote:
> > The argument being made is that the enum patch adheres to established
> practices; and when adding new code that new code is encouraged to adhere
> to how existing code is written
On Wed, Mar 26, 2025 at 10:17 AM David G. Johnston
wrote:
> The argument being made is that the enum patch adheres to established
> practices; and when adding new code that new code is encouraged to adhere to
> how existing code is written. A vote to keep to such guidelines seems
> reasonable
On Wed, Mar 26, 2025 at 03:30:49PM +0100, Álvaro Herrera wrote:
> On 2025-Mar-26, David G. Johnston wrote:
>> The argument being made is that the enum patch adheres to established
>> practices; and when adding new code that new code is encouraged to adhere
>> to how existing code is written. A vot
В письме от среда, 26 марта 2025 г. 16:52:09 MSK пользователь Robert Haas
написал:
> But we also decide things by providing reasons that other people can
> engage with intellectually, and I still say you're not really doing
> that. You're just saying you like X better than Y, but without really
>
On 2025-Mar-26, David G. Johnston wrote:
> The argument being made is that the enum patch adheres to established
> practices; and when adding new code that new code is encouraged to adhere
> to how existing code is written. A vote to keep to such guidelines seems
> reasonable and sufficient; and
On Wednesday, March 26, 2025, Robert Haas wrote:
>
> But we also decide things by providing reasons that other people can
> engage with intellectually, and I still say you're not really doing
> that. You're just saying you like X better than Y, but without really
> giving any reason that anybody
On Tue, Mar 25, 2025 at 12:35 PM Nikolay Shaplov wrote:
> This is not about democracy, this is about who will deal with that part of the
> code later. I guess it will be me and Alvaro, not you. Please let us have the
> code the way we like it, since we support it most of the time.
Actually, we de
On Mon, Mar 24, 2025 at 08:57:27PM -0700, David G. Johnston wrote:
> On Mon, Mar 24, 2025 at 11:45 AM Nathan Bossart
> wrote:
>> * I don't think this matches the parse_bool() behavior exactly. For
>> example, parse_bool() appears to accept inputs like "t" to mean "true".
>> This is also proba
В письме от вторник, 25 марта 2025 г. 17:57:46 MSK пользователь Nathan Bossart
написал:
> In any case, AFAICT the votes are somewhat evenly divided at the moment, so
> I do not intend to proceed with this patch for now.
Counting votes does not lead anywhere, as I can ask friends and colleagues t
On Mon, Mar 24, 2025 at 11:45 AM Nathan Bossart
wrote:
> On Mon, Mar 24, 2025 at 09:03:11PM +0300, Nikolay Shaplov wrote:
> > В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь
> Nathan
> > Bossart написал:
> >
> >> For the sake of discussion, here is what the enum approach would
On Mon, Mar 24, 2025 at 11:12 AM Nikolay Shaplov wrote:
> Nobody would guess that
>
> ALTER TABLE test SET (vacuum_truncate=false);
> means "off"
>
> and
> ALTER TABLE test RESET (vacuum_truncate);
> means "system_default"
>
> This will lead to a lot of confusion.
I agree that this confuses peopl
В письме от понедельник, 24 марта 2025 г. 23:04:39 MSK пользователь Nathan
Bossart написал:
> > We can have isset_offset, but then we have redesign all options with
> > custom unset behavior to use it, instead of unreachable default value.
> > This will make it consistent then.
>
> I don't see an
On Mon, Mar 24, 2025 at 10:35:41PM +0300, Nikolay Shaplov wrote:
> We can have isset_offset, but then we have redesign all options with
> custom unset behavior to use it, instead of unreachable default value.
> This will make it consistent then.
I don't see any reason why we are compelled to redes
В письме от понедельник, 24 марта 2025 г. 22:26:17 MSK пользователь Nathan
Bossart написал:
> > And second general idea: changing engine is bad, at least when you can
> > manage without changing it.
>
> You have asserted this a couple of times without providing any reasons why.
> I know of no ge
В письме от понедельник, 24 марта 2025 г. 21:45:27 MSK пользователь Nathan
Bossart написал:
> * We'd need to decide what to say on the documentation side. My first
> instinct is that we should just leave it as "boolean" because otherwise
> we're going to describe something that sounds an awfu
On Mon, Mar 24, 2025 at 2:45 PM Nathan Bossart wrote:
> * I don't think this matches the parse_bool() behavior exactly. For
> example, parse_bool() appears to accept inputs like "t" to mean "true".
> This is also probably not a huge deal.
It's not great. We allow t/f in most places and some
On Mon, Mar 24, 2025 at 09:03:11PM +0300, Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь Nathan
> Bossart написал:
>
>> For the sake of discussion, here is what the enum approach would look like.
>
> In my point of view this solution is much-much bet
В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь Nathan
Bossart написал:
> For the sake of discussion, here is what the enum approach would look like.
In my point of view this solution is much-much better: it achieves all goals,
has no drawbacks, and do not change reloption e
On Mon, Mar 24, 2025 at 9:41 AM Nathan Bossart
wrote:
> TBH I'm not understanding the pushback for adding a way to determine
> whether the storage parameter is actually set. It's very simple, and it
> seems like it could be useful elsewhere.
IMO this is superior to using sentinel values for th
В письме от понедельник, 24 марта 2025 г. 20:37:50 MSK пользователь David G.
Johnston написал:
> My main concern when first seeing this was adding an integer to every
> single option in the entire system for something that is going to be zero
> 99.9% of the time. A bit bloated but not directly i
For the sake of discussion, here is what the enum approach would look like.
--
nathan
>From f108e6c7e07c4148f097fbfd612cf79db60c5acd Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 24 Mar 2025 12:46:26 -0500
Subject: [PATCH 1/1] change vacuum_truncate relopt to enum
---
src/backend/ac
On Mon, Mar 24, 2025 at 1:27 PM Nikolay Shaplov wrote:
> > > You've just changed the whole engine, for what is seems to be an
> > > exceptional case, that can be solved via existing means.
> > I have not changed the whole engine. I have added an optional integer
> > field to a single struct.
>
>
В письме от понедельник, 24 марта 2025 г. 15:27:35 MSK пользователь Nikolay
Shaplov написал:
> PS. I've just looked at code for vacuum_index_cleanup it has very same
> logic, just replace "auto" with anything you like, and uses enum.
> Grep for StdRdOptIndexCleanupValues for more info
I thought
В письме от понедельник, 24 марта 2025 г. 20:09:23 MSK пользователь Nathan
Bossart написал:
> > You've just changed the whole engine, for what is seems to be an
> > exceptional case, that can be solved via existing means.
> I have not changed the whole engine. I have added an optional integer
>
On Mon, Mar 24, 2025 at 07:53:43PM +0300, Nikolay Shaplov wrote:
> You've just changed the whole engine, for what is seems to be an exceptional
> case, that can be solved via existing means.
I have not changed the whole engine. I have added an optional integer
field to a single struct.
--
nath
В письме от понедельник, 24 марта 2025 г. 19:58:38 MSK пользователь Nathan
Bossart написал:
> On Mon, Mar 24, 2025 at 09:40:24AM -0700, David G. Johnston wrote:
> > So, given the precedent of vacuum_index_cleanup and the above, we should
> > turn this into an enum that accepts all existing boolean
On Mon, Mar 24, 2025 at 09:40:24AM -0700, David G. Johnston wrote:
> So, given the precedent of vacuum_index_cleanup and the above, we should
> turn this into an enum that accepts all existing boolean literal inputs and
> also has a undocumented "unset" default value that the user is not allowed
>
В письме от понедельник, 24 марта 2025 г. 19:41:27 MSK пользователь Nathan
Bossart написал:
> But more importantly, it allows
> us to more closely match the behavior of the existing reloptions with GUCs,
> and it prevents type mismatches (e.g., the reloption is an enum but the GUC
> is a Boolean).
В письме от понедельник, 24 марта 2025 г. 19:00:51 MSK пользователь Álvaro
Herrera написал:
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
> no new mechanism.
In my opinion it should.
"no new mechanism" is goo
Hello
I don't understand why this shouldn't work exactly like
vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
no new mechanism.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming" (A.
On Mon, Mar 24, 2025 at 05:00:51PM +0100, Álvaro Herrera wrote:
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
> no new mechanism.
I explained my reasons for not proceeding with that approach upthread [0].
I don'
On Mon, Mar 24, 2025 at 5:42 AM Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 15:27:35 MSK пользователь
> Nikolay
> Shaplov написал:
>
> > PS. I've just looked at code for vacuum_index_cleanup it has very same
> > logic, just replace "auto" with anything you like, and uses en
On Mon, Mar 24, 2025 at 9:08 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Mar 24, 2025 at 9:00 AM Álvaro Herrera
> wrote:
>
>> Hello
>>
>> I don't understand why this shouldn't work exactly like
>> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
>> n
On Mon, Mar 24, 2025 at 8:45 AM Nikolay Shaplov wrote:
> > but I don't think it's more
> > confusing here than for other vacuum reloptions. I have seen people
> > try to unset vacuum reloptions by using SET to configure them to the
> > default value rather than by using RESET to remove them. But
В письме от понедельник, 24 марта 2025 г. 18:25:44 MSK пользователь Robert
Haas написал:
> > and
> > ALTER TABLE test RESET (vacuum_truncate);
> > means "system_default"
> >
> > This will lead to a lot of confusion.
>
> I agree that this confuses people,
Though a bit more, I think that as a use
On Mon, Mar 24, 2025 at 8:26 AM Robert Haas wrote:
> On Mon, Mar 24, 2025 at 11:12 AM Nikolay Shaplov wrote:
> > Nobody would guess that
> >
> > ALTER TABLE test SET (vacuum_truncate=false);
> > means "off"
> >
> > and
> > ALTER TABLE test RESET (vacuum_truncate);
> > means "system_default"
> >
В письме от понедельник, 24 марта 2025 г. 17:48:25 MSK пользователь Robert
Haas написал:
> On Mon, Mar 24, 2025 at 10:43 AM Nathan Bossart
>
> wrote:
> > Overall, the biggest reason I didn't proceed with the enum is because it
> > felt like it was making it the user's problem. Rather than just
В письме от понедельник, 24 марта 2025 г. 17:43:38 MSK пользователь Nathan
Bossart написал:
> * vacuum_truncate is already a Boolean reloption,
Yes, I guess schema update would be best solution here.
> so switching it to an
> enum would require enumerating all possible values accepted by
>
On Mon, Mar 24, 2025 at 03:27:35PM +0300, Nikolay Shaplov wrote:
> I would suggest to use enum here to achieve same goal, or add some "trilean"
> data type that can be "true/false/unset"
I did first try making the vacuum_truncate reloption an enum, but I didn't
proceed with that approach for a co
On Mon, Mar 24, 2025 at 10:43 AM Nathan Bossart
wrote:
> Overall, the biggest reason I didn't proceed with the enum is because it
> felt like it was making it the user's problem. Rather than just teaching
> our code how to determine if a reloption was explicitly set, we'd be
> introducing unneces
59 matches
Mail list logo
