Re: Lets prohibit predicting the future in the documentation.
On Monday, August 4, 2025, Álvaro Herrera wrote: > On 2025-Jul-31, David G. Johnston wrote: > > > > On Thu, Jul 31, 2025 at 8:05 PM Magnus Hagander > > > wrote: > > > > > I can agree that the "will likely be removed" is a bad wording, and > > > > clearly it was wrong :) > > I disagree that this was clearly wrong -- you just haven't seen that > future yet. I’m not saying it is wrong because it is impossible this will ever be implemented. It’s wrong because after 7 years the probability of this being removed are somewhere near 5% which is “unlikely”. Had it been truly likely it would have been done within a few years at worse, IMO. > We could change "will" to "might" or "may" or "could", but I think we > could also leave it well enough alone. It doesn't actually hurt > anything, does it? I just don’t like giving out false hope. I’m unable to judge how much that harms people in this situation though. And given how nitpicky we tend to get on clarity and succinctness in other aspects of the documentation having this seeming surpurflous and misleading sentence present seem to go against the grain. David J.
Re: further clarification: alter table alter column set not null - table scan is skipped
On 2025-Jul-31, Shuyu Pan wrote: > I like your versions that emphasize: don’t drop the constraint in the > same alter table set no null command. Similar to David’s point, I > spent some time trying to figure out a simple refactoring to carry the > optimization all the way to the end but it might require executing > “set not null” sooner which has a big impact. Another option is only > implement a special treatment for this specific use case but it is a > code smell to me. Oh yeah, delaying the drop is much more likely to break other things. I was more thinking along the lines of maintaining a list of columns that are known non-null at the start of the command (a bitmapset actually). This could be computed in ALTER TABLE phase 1, and used later to determine that no scans are needed. But this is a lot of mechanism which is useless 99% of the time, and moreso now that you can directly add the NOT NULL constraints as NOT VALID to start with, which saves having to mess with a separate CHECK constraint. > I believe a small clarification for the doc entry is the most efficient thing. Okay, I've pushed the change to all branches using David Johnston's suggested wording. Thank you all! -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
Re: further clarification: alter table alter column set not null - table scan is skipped
Thanks a lot Álvaro for preparing the clarification so quickly. Looking forward to the release. If we mark a column to skip table scan during drop (phase 0) and later skip the table scan when setting attributes (phase 7), we will not risk data corruption if the Access Exclusive lock is never released between phase 0 and 7. Sent from Yahoo Mail for iPhone On Monday, August 4, 2025, 04:32, Álvaro Herrera wrote: On 2025-Jul-31, Shuyu Pan wrote: > I like your versions that emphasize: don’t drop the constraint in the > same alter table set no null command. Similar to David’s point, I > spent some time trying to figure out a simple refactoring to carry the > optimization all the way to the end but it might require executing > “set not null” sooner which has a big impact. Another option is only > implement a special treatment for this specific use case but it is a > code smell to me. Oh yeah, delaying the drop is much more likely to break other things. I was more thinking along the lines of maintaining a list of columns that are known non-null at the start of the command (a bitmapset actually). This could be computed in ALTER TABLE phase 1, and used later to determine that no scans are needed. But this is a lot of mechanism which is useless 99% of the time, and moreso now that you can directly add the NOT NULL constraints as NOT VALID to start with, which saves having to mess with a separate CHECK constraint. > I believe a small clarification for the doc entry is the most efficient thing. Okay, I've pushed the change to all branches using David Johnston's suggested wording. Thank you all! -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Re: Initcap works differently with different locale providers
On Mon, 2025-08-04 at 12:30 +0700, Oleg Tselebrovskiy wrote: > First patch just adds this warning about not relying on initcap() > exact > result. The second one is the same, but removes the part "what is a > word" > since it's could be moot because we recommend writing custom > functions, > so understanding what is a word is not exactly needed. Still on the > fence > about which patch is better, though One more thing: we should also change it to "... to upper case (or title case) and the rest to lower case...". Title case is for scripts that have characters like 'Dž' (U+01C5). Other than that I like the second version, which un-documents the specific word boundary rules. I'll admit I'm not quite sure how people use this function in practice, but I expect that it's mostly convenient (or lazy) display. Alexander, is there a reason you backported this change? I don't normally backport doc improvements like this, but I'm not sure what standard others use. The fact that it's on 7 branches makes me more reluctant to commit these extra improvements on top. Can you take care of these follow-up patches? Or, just revert the change and I can make the improvements in master. Regards, Jeff Davis
Re: Lets prohibit predicting the future in the documentation.
On 2025-Jul-31, David G. Johnston wrote: > > On Thu, Jul 31, 2025 at 8:05 PM Magnus Hagander > > wrote: > > > I can agree that the "will likely be removed" is a bad wording, and > > > clearly it was wrong :) I disagree that this was clearly wrong -- you just haven't seen that future yet. It doesn't say "it will be removed before Postgres 20" or "it will be removed by 2025", or "it will be removed before David Johnston comes across this documentation again". It says "will be removed in an unspecified future version", which seems sufficiently open-ended to me. > > > But something like "could be removed" would convey the important > > > message that it is not a limitation of the concept itself, it's > > > just something that hasn't been done yet -- and would perhaps > > > encourage exactly the sort of thing yuo'r suggesting. Where as > > > "will likely be removed" almost sounds like someone is already > > > working on it. We could change "will" to "might" or "may" or "could", but I think we could also leave it well enough alone. It doesn't actually hurt anything, does it? > There is no good way to extract all these "TODO" items from the HTML docs > and seems like a non-optimal method for transferring knowledge to potential > developers who may choose to try and remove such limitations. You could add a bullet point to the TODO page in the wiki to complement it, but I don't think you would remove the doc paragraph while it at; instead it'd probably remain redundant until we actually implemented extended stats on joins, and then we'd remove both. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
