On 19.11.24 17:27, Peter Eisentraut wrote:
On 14.11.24 09:04, Peter Eisentraut wrote:
You can also reproduce this with things that are not strings with
collations. You just need to find a type that has values that are
"equal" but "distinct", which is not common, but it exists, for
example 0.0
On 29.11.24 15:25, Marcos Pegoraro wrote:
Em ter., 19 de nov. de 2024 às 13:27, Peter Eisentraut
mailto:pe...@eisentraut.org>> escreveu:
3. Some documentation updates to explain some of the differences
between
NO ACTION and RESTRICT better.
There is a typo on your commit "doc: Imp
Em ter., 19 de nov. de 2024 às 13:27, Peter Eisentraut
escreveu:
> 3. Some documentation updates to explain some of the differences between
> NO ACTION and RESTRICT better.
>
There is a typo on your commit "doc: Improve description of referential
actions"
There is also a noticeable difference b
On 14.11.24 09:04, Peter Eisentraut wrote:
You can also reproduce this with things that are not strings with
collations. You just need to find a type that has values that are
"equal" but "distinct", which is not common, but it exists, for example
0.0 and -0.0 in floats. Example:
create
On 14.11.24 12:35, jian he wrote:
On Thu, Nov 14, 2024 at 4:04 PM Peter Eisentraut wrote:
I propose that I go ahead with committing the v7 patch (with your typo
fixes) and then we continue discussing these other issues afterwards in
a separate thread.
looks good to me.
done
but in create
On Thu, Nov 14, 2024 at 4:04 PM Peter Eisentraut wrote:
> I propose that I go ahead with committing the v7 patch (with your typo
> fixes) and then we continue discussing these other issues afterwards in
> a separate thread.
>
looks good to me.
but in create_table.sgml
In addition, wh
On 14.11.24 03:21, jian he wrote:
On Wed, Nov 13, 2024 at 8:56 PM jian he wrote:
https://stackoverflow.com/questions/14921668/difference-between-restrict-and-no-action
mentioned about the difference between "no action" and "restrict".
RI_FKey_restrict_upd comments also says:
* The SQL stan
On Wed, Nov 13, 2024 at 8:56 PM jian he wrote:
>
> https://stackoverflow.com/questions/14921668/difference-between-restrict-and-no-action
> mentioned about the difference between "no action" and "restrict".
>
> RI_FKey_restrict_upd comments also says:
>
> * The SQL standard intends that this refe
On Thu, Nov 7, 2024 at 8:15 PM Peter Eisentraut wrote:
>
> Apparently this is intentional. It's the difference between RESTRICT
> and NO ACTION. In ri_restrict(), there is a comment:
>
> /*
> * If another PK row now exists providing the old key values, we should
> * not do anyth
On 25.10.24 16:26, jian he wrote:
drop table if exists pktable, fktable;
CREATE TABLE pktable (x text COLLATE "POSIX" PRIMARY KEY);
CREATE TABLE fktable (x text COLLATE "C" REFERENCES pktable on update
cascade on delete cascade);
INSERT INTO pktable VALUES ('A'), ('Å');
INSERT INTO fktable VALUES
Here is a new patch that addresses all of your review comments. I also
added an example of a problem in the commit message.
On 25.10.24 08:27, jian he wrote:
+ * Note that we require that the collations of the referencing and the
+ * referenced column have the some notion of equality: Either
On 25.10.24 08:23, jian he wrote:
ri_KeysEqual definitely deserves some comments.
for rel_is_pk, the equality is collation agnostic;
for rel_is_pk is false, the equality is collation aware.
for example:
DROP TABLE IF EXISTS fktable, pktable;
CREATE TABLE pktable (x text COLLATE case_insensitive
On Fri, Oct 25, 2024 at 2:27 PM jian he wrote:
>
> /*
> * ri_GenerateQualCollation --- add a COLLATE spec to a WHERE clause
> *
> - * At present, we intentionally do not use this function for RI queries that
> - * compare a variable to a $n parameter. Since parameter symbols always have
> -
> So for the moment this is a master-only patch. I think once we have
> tied down the behavior we want for the future
/*
* ri_GenerateQualCollation --- add a COLLATE spec to a WHERE clause
*
- * At present, we intentionally do not use this function for RI queries that
- * compare a variable
On Thu, Oct 17, 2024 at 7:14 PM Peter Eisentraut wrote:
>
>
> So I took the v5 patch you had posted and started working from there.
> The rule that you had picked isn't quite what we want, I think. It's
> okay to have nondeterministic collations on foreign keys, as long as the
> collation is the
On 04.09.24 08:54, jian he wrote:
On Tue, Sep 3, 2024 at 5:41 PM Peter Eisentraut wrote:
I like this patch version (v4). It's the simplest, probably also
easiest to backpatch.
I am actually confused.
In this email thread [1], I listed 3 corn cases.
I thought all these 3 corner cases should
On Tue, Sep 3, 2024 at 5:41 PM Peter Eisentraut wrote:
>
>
> I like this patch version (v4). It's the simplest, probably also
> easiest to backpatch.
>
I am actually confused.
In this email thread [1], I listed 3 corn cases.
I thought all these 3 corner cases should not be allowed.
but V4 didn'
On 07.06.24 08:39, jian he wrote:
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 ti
On Tue, Jun 18, 2024 at 4:50 PM Peter Eisentraut wrote:
>
> 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
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 ignore_ac
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: w
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 collat
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
> b
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 perh
27 matches
Mail list logo
