Changes between Initial Version and Version 1 of Ticket #35194, comment 10


Ignore:
Timestamp:
Apr 18, 2024, 7:18:44 AM (7 months ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #35194, comment 10

    initial v1  
    11It is effectively a solution but I'm not convinced this will do more good than harm.
    22
    3 #3575 has been merged 16 years ago this means in between now and then thousands of projects were created and added a functional index on `UPPER("col")` to make `i(exact|contains|startwith)` use an index and the moment they upgrade to a minor version of 5.0 their database will start running slow queries as their indices will be unsuables.
     3#3575 has been merged 16 years ago this means in between now and then thousands of projects were created and added a functional index on `UPPER("col")` to have `i(exact|contains|startwith)` make use of it and the moment they upgrade to a minor version of 5.0 their database will start running slow queries as their indices will be unsuables.
    44
    55On the other hand we have a bug in a newly introduced feature for a very particular use case that might be affecting only a few users (must use generated field, must be on a latest version of Postgres, must use `i(exact|contains|startwith)`.
    66
    7 I appreciate the intent to solve this issue but I think we need to dig deeper to truly understand ''why'' this is happening before jumping to conclusions here as there are no true urgency to get things right here; the ''release blocker'' assignment is self-imposed and nothing prevents us from deferring a solution to this problem to a future 5.0 release if we can't understand why this is happening before the May release as for all we know if might be a bug in Postgres itself.
     7I appreciate the intent to solve this issue but I think we need to dig deeper to truly understand ''why'' this is happening before jumping to conclusion as there are no true urgency to get things right . The ''release blocker'' assignment is self-imposed and nothing prevents us from deferring a solution to this problem to a future 5.0 release if we can't understand why this is happening before the May release as for all we know if might be a bug in Postgres itself.
    88
    9 I tried reaching out on libera.chat#postgres IRC to get an answer but no one could answer me their (first time this happens) so I was planing to reach out to their mailing list this week but I might run out of time so if someone feels comfortable doing so please do.
     9I tried reaching out on libera.chat#postgres IRC to get an answer but no one could answer me there (first time this happens) so I was planing to reach out to their mailing list this week but I might run out of time so if someone feels comfortable doing so please do.
    1010
    11 To summarize I think we should understand why this is happening before taking any potential harmful action here. For all we know many other functions and lookups could be affected and this is just the tip of the iceberg.
     11To summarize I think we should understand why this is happening before taking any potential harmful action for the sake of marking this ticket resolved. For all we know many other functions and lookups could be affected and this is just the tip of the iceberg.
Back to Top