It's been a bunch of years since I worked with ICU, so anything I say below
may have changed in their code or be subject to mental bit rot.
On Sun, Sep 23, 2018 at 2:48 PM Thomas Munro
wrote:
> Considering that to handle this we'd need to figure out
> how link libicu.so.55, libicu.so.56, ... etc
>
> The CHECK constraint doesn't need to directly track that information-
> it should have a dependency on the column in the table and that's where
> the information would be recorded about the current collation version.
>
Just to have fun throwing odd cases out, how would something like this be
r
On Mon, Sep 17, 2018 at 12:32 PM Greg Stark wrote:
> This seems like a terrible idea in the open source world. Surely collation
> versioning means new ICU libraries can still provide the old collation
> rules so even if you update the library you can request the old version? We
> shouldn't need t
On Sun, Sep 16, 2018 at 1:14 PM Thomas Munro
wrote:
> We have to start somewhere and indexes are the first thing that people
> notice, and are much likely to actually be a problem (personally I've
> encountered many cases of index corruption due to collation changes in
> the wild, but never a con
t;>>> "Douglas" == Douglas Doole writes:
>
> Douglas> And constraints problems are even easier than triggers.
> Douglas> Consider a database with complex BI rules that are implemented
> Douglas> through triggers that fire when values are/are not equal. If
> Do
On Sun, Sep 16, 2018 at 1:20 AM Thomas Munro
wrote:
> 3. Fix the tracking of when reindexes need to be rebuilt, so that you
> can't get it wrong (as you're alluding to above).
>
I've mentioned this in the past, but didn't seem to get any traction, so
I'll try it again ;-)
The focus on indexes
>
> I think we're going to have to continue showing the tree plan. I think
> the linear version is far too hard to understand for anything
> nontrivial.
>
Hey Andres, what you're pitching here is very similar to the way DB2 works.
It actually has two different explain tools that dumps the two diff
As I was double checking that the new function marking from 10.4 merged
correctly to our fork, I noticed that one of the ts_rewrite entries looks
wrong.
The release notes say:
ALTER FUNCTION pg_catalog.ts_rewrite(tsquery, tsquery, tsquery) PARALLEL
UNSAFE;
But when I pull pg_proc.h from 10.4, I f
>
> At the top-level, it's even more dubious. In DB2, apparently you write
>>
>> CALL foo(123, ?);
>>
>> with a literal ? for the OUT parameters.
>>
>
That's not actually as scary as it seems.
DB2 has two cases where you can use a ? like that:
1) In CLP (DB2's equivalent to psql)
DB2 draws a di
