On 08.06.24 06:14, jian he wrote:
if FK is nondeterministic, then it looks PK more like FK.
the following example, one FK row is referenced by two PK rows.
DROP TABLE IF EXISTS fktable, pktable;
CREATE TABLE pktable (x text COLLATE "C" PRIMARY KEY);
CREATE TABLE fktable (x text COLLATE
On Sat, Jun 8, 2024 at 4:12 AM Tom Lane wrote:
>
> jian he writes:
> >> * in TryReuseForeignKey, we can pass the information that our primary
> >> key old collation is nondeterministic
> >> and old collation != new collation to the foreign key constraint.
>
> I have a basic question about this:
jian he writes:
>> * in TryReuseForeignKey, we can pass the information that our primary
>> key old collation is nondeterministic
>> and old collation != new collation to the foreign key constraint.
I have a basic question about this: why are we allowing FKs to be
based on nondeterministic
On Sat, Apr 13, 2024 at 9:13 PM jian he wrote:
>
> > > > Here is a patch implementing this. It was a bit more fuss than I
> > > > expected, so maybe someone has a
> > > > better way.
> I think I found a simple way.
>
> the logic is:
> * ATExecAlterColumnType changes one column once at a time.
>
On Fri, Apr 12, 2024 at 5:06 PM jian he wrote:
>
> On Tue, Mar 26, 2024 at 1:00 PM jian he wrote:
> >
> > On Mon, Mar 25, 2024 at 2:47 PM Paul Jungwirth
> > wrote:
> > >
> > > On 3/23/24 10:04, Paul Jungwirth wrote:
> > > > Perhaps if the previous collation was nondeterministic we should force
On Tue, Mar 26, 2024 at 1:00 PM jian he wrote:
>
> On Mon, Mar 25, 2024 at 2:47 PM Paul Jungwirth
> wrote:
> >
> > On 3/23/24 10:04, Paul Jungwirth wrote:
> > > Perhaps if the previous collation was nondeterministic we should force a
> > > re-check.
> >
> > Here is a patch implementing this. It
On Mon, Mar 25, 2024 at 2:47 PM Paul Jungwirth
wrote:
>
> On 3/23/24 10:04, Paul Jungwirth wrote:
> > Perhaps if the previous collation was nondeterministic we should force a
> > re-check.
>
> Here is a patch implementing this. It was a bit more fuss than I expected, so
> maybe someone has a
>
On 3/23/24 10:04, Paul Jungwirth wrote:
Perhaps if the previous collation was nondeterministic we should force a
re-check.
Here is a patch implementing this. It was a bit more fuss than I expected, so maybe someone has a
better way.
We have had nondeterministic collations since v12, so
Dear hackers,
I was looking at how foreign keys deal with collations, and I came across this comment about not
re-checking a foreign key if the column type changes in a compatible way:
* Since we require that all collations share the same notion of
* equality (which they do, because
