Peter Eisentraut writes:
>> Here is an updated patch that works as indicated above.
>>
>> The behavior if you try to create an index with mismatching collations
>> now is that it will skip over the column and complain at the end with
>> something like
>>
>> ERROR: 0A000: unique constraint on
On 23.11.23 11:01, Peter Eisentraut wrote:
On 20.11.23 17:25, Tom Lane wrote:
Peter Eisentraut writes:
On 14.11.23 17:15, Tom Lane wrote:
I don't love the patch details though. It seems entirely wrong to
check
this before we check the opclass match.
Not sure why? The order doesn't seem
On 20.11.23 17:25, Tom Lane wrote:
Peter Eisentraut writes:
On 14.11.23 17:15, Tom Lane wrote:
I don't love the patch details though. It seems entirely wrong to check
this before we check the opclass match.
Not sure why? The order doesn't seem to matter?
The case that was bothering me w
Peter Eisentraut writes:
> On 14.11.23 17:15, Tom Lane wrote:
>> I don't love the patch details though. It seems entirely wrong to check
>> this before we check the opclass match.
> Not sure why? The order doesn't seem to matter?
The case that was bothering me was if we had a non-collated type
On 14.11.23 17:15, Tom Lane wrote:
I don't love the patch details though. It seems entirely wrong to check
this before we check the opclass match.
Not sure why? The order doesn't seem to matter?
Also, in at least some cases
the code presses on looking for another match if the current opclas
On Fri, 2023-11-17 at 15:18 -0500, Tom Lane wrote:
> You keep harping on this idea that we are only concerned with
> equality,
> but I think you are wrong. We expect a btree index to provide
> ordering
> not only equality, and this example definitely is a btree index.
>
> Possibly, with a great d
Jeff Davis writes:
> In the patch, you check for an exact collation match. Considering this
> case only depends on equality, I think it would be correct if the
> requirement was that (a) both collations are deterministic; or (b) the
> collations match exactly.
You keep harping on this idea that w
On Mon, 2023-11-13 at 10:24 +0100, Peter Eisentraut wrote:
> create table t1 (a int, b text) partition by hash (b);
> create table t1a partition of t1 for values with (modulus 2,
> remainder 0);
> create table t1b partition of t1 for values with (modulus 2,
> remainder 1);
> create unique index i1
Peter Eisentraut writes:
> On 13.11.23 21:04, Laurenz Albe wrote:
>> This will be backpatched, right? What if somebody already created an index
>> like that?
>> Does this warrant an entry in the "however" for the release notes, or is the
>> case
>> exotic enough that we can assume that nobody i
On 13.11.23 21:04, Laurenz Albe wrote:
On Mon, 2023-11-13 at 10:24 +0100, Peter Eisentraut wrote:
* If this table is partitioned and we're creating a unique index, primary
* key, or exclusion constraint, make sure that the partition key is a
* subset of the index's columns.
On Mon, 2023-11-13 at 10:24 +0100, Peter Eisentraut wrote:
> * If this table is partitioned and we're creating a unique index,
> primary
> * key, or exclusion constraint, make sure that the partition key is a
> * subset of the index's columns. Otherwise it would be possible to
>
When creating a partitioned index, the partition key must be a subset of
the index's columns. DefineIndex() explains:
* If this table is partitioned and we're creating a unique index,
primary
* key, or exclusion constraint, make sure that the partition key is a
* subset of the
12 matches
Mail list logo
