Re: Initcap works differently with different locale providers
On Mon, 2025-07-28 at 13:20 +0300, Alexander Korotkov wrote: > I can confirm inicap works with libc and libicu as you stated. The > documentation patch looks good to me. I’ve written a commit message. > The REL_12_STABLE branch is not relevant anymore as it’s out of > support. I’m going to push this if no objections. Apologies for the late review. First, it doesn't mention the "builtin" provider, which uses the same word break rules as libc. Second, word boundaries can be complex, and I'm wondering if we should not be so precise about what ICU does or doesn't do. For instance, ICU has options like U_TITLECASE_ADJUST_TO_CASED, U_TITLECASE_NO_BREAK_ADJUSTMENT, etc.[1], and I'm not sure exactly which one of those we use. I'd prefer that we try to explain that INITCAP() is intended for convenient display, and the specific result should not be relied upon (at least for ICU; maybe for all providers). If you want specific word boundary rules, write your own function. Regards, Jeff Davis [1] https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/stringoptions_8h.html#a4975f537b9960f0330b233061ef0608d
Re: Lets prohibit predicting the future in the documentation.
On Thu, 31 Jul 2025 at 14:17, David G. Johnston wrote: > > Came across this again today...we added, way back in v11: > > "This limitation will likely be removed in a future version of > PostgreSQL." > > https://www.postgresql.org/docs/18/sql-createstatistics.html This sort of thing doesn't particularly upset me. I don't believe we should hide the fact that certain features might need more work. If it inspires someone to work on making improvements, wouldn't it be worthwhile keeping these? A huge amount of stuff gets done around here because people find some inspiration to make things better. I don't believe all those people need to experience the problems first-hand to be able to fix them. Plenty of people arrive here just looking to get involved and make a difference. I presume that something like this being mentioned in the docs likely has a much better "we actually want this feature" ratio than the TODO list does. I also imagine it's more likely to inspire users of PostgreSQL to get involved in developing than the TODO list is. -1 from me. David
Re: Lets prohibit predicting the future in the documentation.
On Wed, Jul 30, 2025 at 7:17 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > Came across this again today...we added, way back in v11: > > "This limitation will likely be removed in a future version of > PostgreSQL." > > Or, maybe phrase it: "Patches are welcomed." David J.
Re: further clarification: alter table alter column set not null - table scan is skipped
On Wed, Jul 30, 2025, 13:55 PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/17/docguide.html > Description: > > Hello there, > I like PostgreSQL a lot so this is my way of giving back. > > The "table scan is skipped" optimization can use some clarification > > https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-DESC-SET-DROP-NOT-NULL > My proposal is "then the table scan is skipped if the alter statement > doesn't drop the constraint." > > The reason behind the proposal is documented here > https://dev.to/andrewpsy/the-set-not-null-downtime-trap-in-postgresql-1o71 > > Thank you for working on such an awesome project. > Cheers, > Andrew > I'm kinda hoping this is actually just a fixable bug... Otherwise I'd probably go for a parenthetical: (however, the constraint used must not be dropped in the same alter table command). David J.
further clarification: alter table alter column set not null - table scan is skipped
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/17/docguide.html Description: Hello there, I like PostgreSQL a lot so this is my way of giving back. The "table scan is skipped" optimization can use some clarification https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-DESC-SET-DROP-NOT-NULL My proposal is "then the table scan is skipped if the alter statement doesn't drop the constraint." The reason behind the proposal is documented here https://dev.to/andrewpsy/the-set-not-null-downtime-trap-in-postgresql-1o71 Thank you for working on such an awesome project. Cheers, Andrew
Lets prohibit predicting the future in the documentation.
Came across this again today...we added, way back in v11: "This limitation will likely be removed in a future version of PostgreSQL." https://www.postgresql.org/docs/18/sql-createstatistics.html David J.
