>
> 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
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
>
> 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
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
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
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: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
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
>
> 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
>
> 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
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
>
> 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
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
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: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
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
>
> 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
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
18 matches
Mail list logo
