On Fri, Jan 31, 2020 at 6:15 AM Mark Dilger
wrote:
> > On Jan 30, 2020, at 12:29 PM, Tom Lane wrote:
> > Mark Dilger writes:
> >> Would it make sense to catch a qual with unassigned collation
> >> somewhere in the planner, where the qual's operator family is
> >> estatblished, by checking if the
> On Jan 30, 2020, at 12:29 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Would it make sense to catch a qual with unassigned collation
>> somewhere in the planner, where the qual's operator family is
>> estatblished, by checking if the operator family behavior is sensitive
>> to collations?
Robert Haas writes:
> I assume that what would have to happen to implement this is that an
> SQL-callable function would be passed more than one collation OID,
> perhaps one per argument or something like that. Notice, however, that
> this would require changing the way that functions get called.
Mark Dilger writes:
> Would it make sense to catch a qual with unassigned collation
> somewhere in the planner, where the qual's operator family is
> estatblished, by checking if the operator family behavior is sensitive
> to collations?
> I’m not sure how to do that. pg_opfamily doesn’t seem to
> On Jan 30, 2020, at 12:02 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> According to Tom:
>>> (BTW, before v12 the text '=' operator indeed did not care for collation,
>>> so this example would've worked. But the change in behavior is a
>>> necessary consequence of having invented nondete
On Thu, Jan 30, 2020 at 2:44 PM Mark Dilger
wrote:
> 3) Extend the concept of collations to collation sets. Right now, I’m only
> thinking about a collation set as having two values, the lefthand and the
> righthand side, but maybe there are other cases like (Left, (Left,Right))
> that get bui
Mark Dilger writes:
> According to Tom:
>> (BTW, before v12 the text '=' operator indeed did not care for collation,
>> so this example would've worked. But the change in behavior is a
>> necessary consequence of having invented nondeterministic collations,
>> not a bug.)
> I’m still struggling
>> Would it make sense to catch a qual with unassigned collation
>> somewhere in the planner, where the qual's operator family is
>> estatblished, by checking if the operator family behavior is sensitive
>> to collations?
I’m not sure how to do that. pg_opfamily doesn’t seem to have a field fo
> On Jan 29, 2020, at 10:14 PM, Amit Langote wrote:
>
>
> SELECT t1.a, t2.a FROM alpha t1 INNER JOIN beta t2 ON (t1.a = t2.a)
> WHERE t1.a IN ('äbç', 'ὀδυσσεύς');
> ERROR: could not determine which collation to use for string comparison
> HINT: Use the COLLATE clause to set the collation ex
Hi Mark,
On Wed, Jan 29, 2020 at 1:03 PM Mark Dilger
wrote:
> > On Jan 28, 2020, at 7:38 PM, Mark Dilger
> > wrote:
> >> Mark Dilger writes:
> >>> While reviewing the partition-wise join patch, I ran into an issue that
> >>> exists in master, so rather than responding to that patch, I’m start
> On Jan 28, 2020, at 7:38 PM, Mark Dilger wrote:
>
>
>
>> On Jan 28, 2020, at 6:46 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> While reviewing the partition-wise join patch, I ran into an issue that
>>> exists in master, so rather than responding to that patch, I’m starting
>>> t
> On Jan 28, 2020, at 6:46 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> While reviewing the partition-wise join patch, I ran into an issue that
>> exists in master, so rather than responding to that patch, I’m starting this
>> new thread.
>> I noticed that this seems similar to the proble
Mark Dilger writes:
> While reviewing the partition-wise join patch, I ran into an issue that
> exists in master, so rather than responding to that patch, I’m starting this
> new thread.
> I noticed that this seems similar to the problem that was supposed to have
> been fixed in the "Re: COLLAT
13 matches
Mail list logo
