On Tue, 2024-05-21 at 13:57 -0400, Robert Haas wrote:
> What I think is less clear is what that means for temporal primary
> keys.
Right.
My message was specifically a response to the concern that there was
some kind of design flaw in the range types or exclusion constraints
mechanisms.
I don't
On Tue, 21 May 2024 at 13:57, Robert Haas wrote:
What I think is less clear is what that means for temporal primary
> keys. As Paul pointed out upthread, in every other case, a temporal
> primary key is at least as unique as a regular primary key, but in
> this case, it isn't. And someone might
On Thu, May 16, 2024 at 7:22 PM Jeff Davis wrote:
> An empty range does not "bypass" the an exclusion constraint. The
> exclusion constraint has a documented meaning and it's enforced.
>
> Of course there are situations where an empty range doesn't make a lot
> of sense. For many domains zero
On Mon, 2024-05-13 at 12:11 +0200, Peter Eisentraut wrote:
> Some of these issues might be design flaws in the underlying
> mechanisms,
> like range types and exclusion constraints. Like, if you're supposed
> to
> use this for scheduling but you can use empty ranges to bypass
> exclusion
>
On 15.05.24 11:39, Peter Eisentraut wrote:
Attached are the individual revert patches. I'm supplying these here
mainly so that future efforts can use those instead of the original
patches, since that would have to redo all the conflict resolution and
also miss various typo fixes etc. that
On Tue, May 14, 2024 at 01:33:46PM +0800, jian he wrote:
> thanks for the idea, I roughly played around with it, seems doable.
> but the timing seems not good, reverting is a good idea.
Please note that this is still an open item, and that time is running
short until beta1. A revert seems to be
On Tue, May 14, 2024 at 7:30 AM Paul Jungwirth
wrote:
>
> On 5/13/24 03:11, Peter Eisentraut wrote:
> > It looks like we missed some of these fundamental design questions early
> > on, and it might be too
> > late now to fix them for PG17.
> >
> > For example, the discussion on unique
On 5/13/24 03:11, Peter Eisentraut wrote:
It looks like we missed some of these fundamental design questions early on, and it might be too
late now to fix them for PG17.
For example, the discussion on unique constraints misses that the question of null values in unique
constraints itself is
On 03.04.24 07:30, Paul Jungwirth wrote:
But is it *literally* unique? Well two identical keys, e.g. (5,
'[Jan24,Mar24)') and (5, '[Jan24,Mar24)'), do have overlapping ranges,
so the second is excluded. Normally a temporal unique index is *more*
restrictive than a standard one, since it
On 5/12/24 08:51, Paul Jungwirth wrote:
On 5/12/24 05:55, Matthias van de Meent wrote:
> pg=# CREATE UNIQUE INDEX ON temporal_testing USING gist (id, valid_during);
> ERROR: access method "gist" does not support unique indexes
To me that error message seems correct. The programmer hasn't
On 5/5/24 20:01, jian he wrote:
hi.
I hope I understand the problem correctly.
my understanding is that we are trying to solve a corner case:
create table t(a int4range, b int4range, primary key(a, b WITHOUT OVERLAPS));
insert into t values ('[1,2]','empty'), ('[1,2]','empty');
I think the
On 5/12/24 05:55, Matthias van de Meent wrote:
> pg=# CREATE UNIQUE INDEX ON temporal_testing USING gist (id, valid_during);
> ERROR: access method "gist" does not support unique indexes
To me that error message seems correct. The programmer hasn't said anything
about the special
temporal
On Sun, 12 May 2024 at 05:26, Paul Jungwirth
wrote:
> On 5/9/24 17:44, Matthias van de Meent wrote:
> > I haven't really been following this thread, but after playing around
> > a bit with the feature I feel there are new gaps in error messages. I
> > also think there are gaps in the
On 5/9/24 17:44, Matthias van de Meent wrote:
I haven't really been following this thread, but after playing around
a bit with the feature I feel there are new gaps in error messages. I
also think there are gaps in the functionality regarding the (lack of)
support for CREATE UNIQUE INDEX, and
On 5/11/24 17:00, jian he wrote:
I hope I understand the problem correctly.
my understanding is that we are trying to solve a corner case:
create table t(a int4range, b int4range, primary key(a, b WITHOUT OVERLAPS));
insert into t values ('[1,2]','empty'), ('[1,2]','empty');
but we still not
On Mon, May 6, 2024 at 11:01 AM jian he wrote:
>
> On Wed, May 1, 2024 at 12:39 AM Paul Jungwirth
> wrote:
> >
> > On 4/30/24 09:24, Robert Haas wrote:
> > > Peter, could you have a look at
> > > http://postgr.es/m/47550967-260b-4180-9791-b224859fe...@illuminatedcomputing.com
> > > and express
I have committed the
v2-0001-Fix-ON-CONFLICT-DO-NOTHING-UPDATE-for-temporal-in.patch from
this (confusingly, there was also a v2 earlier in this thread), and I'll
continue working on the remaining items.
On 09.05.24 06:24, Paul Jungwirth wrote:
Here are a couple new patches, rebased to
Hi,
I haven't really been following this thread, but after playing around
a bit with the feature I feel there are new gaps in error messages. I
also think there are gaps in the functionality regarding the (lack of)
support for CREATE UNIQUE INDEX, and attaching these indexes to
constraints.
pg=#
Here are a couple new patches, rebased to e305f715, addressing Peter's feedback. I'm still working
on integrating jian he's suggestions for the last patch, so I've omitted that one here.
On 5/8/24 06:51, Peter Eisentraut wrote:
About
On 30.04.24 18:39, Paul Jungwirth wrote:
On 4/30/24 09:24, Robert Haas wrote:
Peter, could you have a look at
http://postgr.es/m/47550967-260b-4180-9791-b224859fe...@illuminatedcomputing.com
and express an opinion about whether each of those proposals are (a)
good or bad ideas and (b) whether
On Wed, May 1, 2024 at 12:39 AM Paul Jungwirth
wrote:
>
> On 4/30/24 09:24, Robert Haas wrote:
> > Peter, could you have a look at
> > http://postgr.es/m/47550967-260b-4180-9791-b224859fe...@illuminatedcomputing.com
> > and express an opinion about whether each of those proposals are (a)
> > good
On Wed, May 1, 2024 at 12:39 AM Paul Jungwirth
wrote:
>
> On 4/30/24 09:24, Robert Haas wrote:
> > Peter, could you have a look at
> > http://postgr.es/m/47550967-260b-4180-9791-b224859fe...@illuminatedcomputing.com
> > and express an opinion about whether each of those proposals are (a)
> > good
On 4/30/24 09:24, Robert Haas wrote:
Peter, could you have a look at
http://postgr.es/m/47550967-260b-4180-9791-b224859fe...@illuminatedcomputing.com
and express an opinion about whether each of those proposals are (a)
good or bad ideas and (b) whether they need to be fixed for the
current
On Fri, Apr 26, 2024 at 3:41 PM Paul Jungwirth
wrote:
> On 4/26/24 12:25, Robert Haas wrote:
> > I think this thread should be added to the open items list.
>
> Thanks! I sent a request to pgsql-www to get edit permission. I didn't
> realize there was a wiki page
> tracking things like this. I
On 4/26/24 12:25, Robert Haas wrote:
I think this thread should be added to the open items list.
Thanks! I sent a request to pgsql-www to get edit permission. I didn't realize there was a wiki page
tracking things like this. I agree it needs to be fixed if we want to include the feature.
On Wed, Apr 3, 2024 at 1:30 AM Paul Jungwirth
wrote:
> I found some problems with temporal primary keys and the idea of uniqueness,
> especially around the
> indisunique column. Here are some small fixes and a proposal for a larger
> fix, which I think we need
> but I'd like some feedback on.
On Wed, Apr 3, 2024 at 1:30 PM Paul Jungwirth
wrote:
>
> On 3/24/24 00:38, Peter Eisentraut wrote:> I have committed the patches
> > v33-0001-Add-temporal-FOREIGN-KEYs.patch and
> > v33-0002-Support-multiranges-in-temporal-FKs.patch
> > (together).
>
> Hi Hackers,
>
> I found some problems with
On 3/24/24 00:38, Peter Eisentraut wrote:> I have committed the patches
v33-0001-Add-temporal-FOREIGN-KEYs.patch and v33-0002-Support-multiranges-in-temporal-FKs.patch
(together).
Hi Hackers,
I found some problems with temporal primary keys and the idea of uniqueness, especially around the
On Sun, Mar 24, 2024 at 1:42 AM Paul Jungwirth
wrote:
>
> v33 attached with minor changes.
>
> Okay, added those tests too. Thanks!
>
> Rebased to 697f8d266c.
>
hi.
minor issues I found in v33-0003.
there are 29 of {check_amproc_signature?.*false}
only one
On 23.03.24 18:42, Paul Jungwirth wrote:
Now this is a long chain of reasoning to say rangetypes are safe. I
added a comment. Note it doesn't apply to arbitrary types, so if we
support those eventually we should just require a recheck always, or
alternately use equals, not containedby. (That
On Fri, Mar 22, 2024 at 11:49 PM Peter Eisentraut wrote:
>
> On 22.03.24 01:35, Paul Jungwirth wrote:
> > > 1. In ri_triggers.c ri_KeysEqual, you swap the order of arguments to
> > ri_AttributesEqual():
> > >
> > > - if (!ri_AttributesEqual(riinfo->ff_eq_oprs[i],
> > RIAttType(rel,
On 22.03.24 01:35, Paul Jungwirth wrote:
> 1. In ri_triggers.c ri_KeysEqual, you swap the order of arguments to
ri_AttributesEqual():
>
> - if (!ri_AttributesEqual(riinfo->ff_eq_oprs[i],
RIAttType(rel, attnums[i]),
> - oldvalue, newvalue))
> +
On Fri, Mar 22, 2024 at 8:35 AM Paul Jungwirth
wrote:
>
> Your patch had a lot of other noisy changes, e.g.
> whitespace and reordering lines. If there are other things you intended to
> add to the tests, can you
> describe them?
i think on update restrict, on delete restrict cannot be
On 20.03.24 17:21, Paul Jungwirth wrote:
On 3/20/24 03:55, jian he wrote:
hi.
minor cosmetic issues, other than that, looks good.
*pk_period = (indexStruct->indisexclusion);
to
*pk_period = indexStruct->indisexclusion;
... >
if (with_period && !fkconstraint->fk_with_period)
ereport(ERROR,
with foreign key "no action",
in a transaction, we can first insert foreign key data, then primary key data.
also the update/delete can fail at the end of transaction.
based on [1] explanation about the difference between "no action" and
"restrict".
I only refactor the
hi.
minor cosmetic issues, other than that, looks good.
*pk_period = (indexStruct->indisexclusion);
to
*pk_period = indexStruct->indisexclusion;
if (with_period)
{
if (!fkconstraint->fk_with_period)
ereport(ERROR,
(errcode(ERRCODE_INVALID_FOREIGN_KEY),
errmsg("foreign key uses PERIOD on the
On 16.03.24 22:37, Paul A Jungwirth wrote:
Here is a new patch series addressing the last few feedback emails
from Peter & Jian He. It mostly focuses on the FKs patch, trying to
get it really ready to commit,
I have committed the test changes (range and date format etc.).
The FOREIGN KEY
On Tue, Mar 19, 2024 at 6:49 AM Paul Jungwirth
wrote:
>
> Rebased to 846311051e.
>
Hi, I just found out some minor issues.
+ * types matching the PERIOD element. periodprocoid is a GiST support
function to
+ * aggregate multiple PERIOD element values into a single value
+ * (whose return type
one more minor issue related to error reporting.
I've only applied v28, 0001 to 0005.
-- (parent_id, valid_at) REFERENCES [implicit]
-- FOREIGN KEY part should specify PERIOD
CREATE TABLE temporal_fk_rng2rng (
id int4range,
valid_at daterange,
parent_id int4range,
CONSTRAINT
Hi, minor issues from 1 to 0005.
+
+ referencedagg
+ aggregates referenced rows' WITHOUT OVERLAPS
+part
+ 13
+
comparing with surrounding items, maybe need to add `(optional)`?
I think the explanation is not good as explained in referencedagg entry below:
in GetOperatorFromWellKnownStrategy:
*strat = GistTranslateStratnum(opclass, instrat);
if (*strat == InvalidStrategy)
{
HeapTuple tuple;
tuple = SearchSysCache1(CLAOID, ObjectIdGetDatum(opclass));
if (!HeapTupleIsValid(tuple))
elog(ERROR, "cache lookup failed for operator class %u", opclass);
On Mon, Mar 11, 2024 at 3:46 PM Peter Eisentraut wrote:
>
> A few general comments on the tests:
>
> - In the INSERT commands, specify the column names explicitly. This
> makes the tests easier to read (especially since the column order
> between the PK and the FK table is sometimes different).
+
+ If the last column is marked with PERIOD,
+ it is treated in a special way.
+ While the non-PERIOD columns are treated normally
+ (and there must be at least one of them),
+ the PERIOD column is not compared for equality.
+ Instead the constraint is
On 01.03.24 22:56, Paul Jungwirth wrote:
On 3/1/24 12:38, Paul Jungwirth wrote:
On 2/29/24 13:16, Paul Jungwirth wrote:
Here is a v26 patch series to fix a cfbot failure in sepgsql. Rebased
to 655dc31046.
v27 attached, fixing some cfbot failures from
headerscheck+cpluspluscheck. Sorry for
On 2/13/24 21:00, jian he wrote:
Hi
more minor issues.
+ FindFKComparisonOperators(
+ fkconstraint, tab, i, fkattnum,
+ _check_ok, _pfeqop_item,
+ pktypoid[i], fktypoid[i], opclasses[i],
+ is_temporal, false,
+ [i], [i], [i]);
+ }
+ if (is_temporal) {
+ pkattnum[numpks] = pkperiodattnum;
+
Hi
more minor issues.
+ FindFKComparisonOperators(
+ fkconstraint, tab, i, fkattnum,
+ _check_ok, _pfeqop_item,
+ pktypoid[i], fktypoid[i], opclasses[i],
+ is_temporal, false,
+ [i], [i], [i]);
+ }
+ if (is_temporal) {
+ pkattnum[numpks] = pkperiodattnum;
+ pktypoid[numpks] = pkperiodtypoid;
+
I have done a review of the temporal foreign key patches in this patch
series (0002 and 0003, v24).
The patch set needs a rebase across c85977d8fef. I was able to do it
manually, but it's a bit tricky, so perhaps you can post a new set to
help future reviews.
(Also, the last (0007) patch has
On Mon, Jan 29, 2024 at 8:00 AM jian he wrote:
>
> I fixed your tests, some of your tests can be simplified, (mainly
> primary key constraint is unnecessary for the failed tests)
> also your foreign key patch test table, temporal_rng is created at
> line 141, and we use it at around line 320.
>
I fixed your tests, some of your tests can be simplified, (mainly
primary key constraint is unnecessary for the failed tests)
also your foreign key patch test table, temporal_rng is created at
line 141, and we use it at around line 320.
it's hard to get the definition of temporal_rng. I drop the
On 24.01.24 23:06, Paul Jungwirth wrote:
On 1/24/24 08:32, Peter Eisentraut wrote:
> On 18.01.24 04:59, Paul Jungwirth wrote:
>> Here are new patches consolidating feedback from several emails.
>
> I have committed 0001 and 0002 (the primary key support).
Thanks Peter! I noticed the comment
On 18.01.24 04:59, Paul Jungwirth wrote:
Here are new patches consolidating feedback from several emails.
I have committed 0001 and 0002 (the primary key support).
The only significant tweak I did was the error messages in
GetOperatorFromWellKnownStrategy(), to make the messages translatable
2024-01 Commitfest.
Hi, This patch has a CF status of "Needs Review" [1], but it seems
there were CFbot test failures last time it was run [2]. Please have a
look and post an updated version if necessary.
==
[1] https://commitfest.postgresql.org/46/4308/
[2]
On Thu, Jan 11, 2024 at 10:44 PM Peter Eisentraut wrote:
>
> On 31.12.23 09:51, Paul Jungwirth wrote:
> > On Wed, Dec 6, 2023 at 12:59 AM Peter Eisentraut
> > wrote:
> > >
> > > On 02.12.23 19:41, Paul Jungwirth wrote:
> > > > So what do you think of this idea instead?:
> > > >
> > > > We
On 31.12.23 09:51, Paul Jungwirth wrote:
On Wed, Dec 6, 2023 at 12:59 AM Peter Eisentraut
wrote:
>
> On 02.12.23 19:41, Paul Jungwirth wrote:
> > So what do you think of this idea instead?:
> >
> > We could add a new (optional) support function to GiST that translates
> > "well-known"
On Sat, 6 Jan 2024 at 05:50, Paul Jungwirth
wrote:
>
> Getting caught up on reviews from November and December:
>
> On 11/19/23 22:57, jian he wrote:
> >
> > I believe the following part should fail. Similar tests on
> > src/test/regress/sql/generated.sql. line begin 347.
> >
> > drop table
On Tue, Jan 9, 2024 at 2:54 AM Paul Jungwirth
wrote:
>
> On 1/8/24 06:54, jian he wrote:
> > On Fri, Jan 5, 2024 at 1:06 PM jian he wrote:
> >
> > range_intersect returns the intersection of two ranges.
> > I think here we are doing the opposite.
> > names the main SQL function
On 1/8/24 06:54, jian he wrote:
> On Fri, Jan 5, 2024 at 1:06 PM jian he wrote:
>
> range_intersect returns the intersection of two ranges.
> I think here we are doing the opposite.
> names the main SQL function "range_not_intersect" and the internal
> function as "range_not_intersect_internal"
On Fri, Jan 5, 2024 at 1:06 PM jian he wrote:
>
> On Tue, Jan 2, 2024 at 9:59 AM Paul Jungwirth
> wrote:
> >
> > On 12/31/23 00:51, Paul Jungwirth wrote:
> > > That's it for now.
> >
> > Here is another update. I fixed FOR PORTION OF on partitioned tables, in
> > particular when the attnums
> >
On Tue, Jan 2, 2024 at 9:59 AM Paul Jungwirth
wrote:
>
> On 12/31/23 00:51, Paul Jungwirth wrote:
> > That's it for now.
>
> Here is another update. I fixed FOR PORTION OF on partitioned tables, in
> particular when the attnums
> are different from the root partition.
>
> Rebased to cea89c93a1.
hi. some small issues
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index e3ccf6c7f7..6781e55020 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -1560,7 +1560,7 @@ ProcessUtilitySlow(ParseState *pstate,
true, /* check_rights */
true, /*
On Sun, Dec 3, 2023 at 2:11 AM Paul Jungwirth
wrote:
>
> v19 patch series attached, rebased to a11c9c42ea.
>
this TODO:
* TODO: It sounds like FOR PORTION OF might need to do something here too?
based on comments on ExprContext. I refactor a bit, and solved this TODO.
tring to the following
On 02.12.23 19:41, Paul Jungwirth wrote:
So what do you think of this idea instead?:
We could add a new (optional) support function to GiST that translates
"well-known" strategy numbers into the opclass's own strategy numbers.
This would be support function 12. Then we can say
On 12/2/23 19:11, Paul Jungwirth wrote:
Thank you again for such thorough reviews!
On Thu, Nov 16, 2023 at 11:12 PM jian he
wrote:
> UPDATE FOR PORTION OF, may need insert privilege. We also need to
document this.
> Similarly, we also need to apply the above logic to DELETE FOR
PORTION
On Thu, Nov 23, 2023 at 1:08 AM Peter Eisentraut wrote:
> After further thought, I think the right solution is to change
> btree_gist (and probably also btree_gin) to use the common RT* strategy
> numbers.
Okay. That will mean bumping the version of btree_gist, and you must be running that
On 20.11.23 08:58, Peter Eisentraut wrote:
On 17.11.23 19:39, Paul Jungwirth wrote:
But I feel the overall approach is wrong: originally I used hardcoded
"=" and "&&" operators, and you asked me to look them up by strategy
number instead. But that leads to trouble with core gist types vs
On 17.11.23 19:39, Paul Jungwirth wrote:
But I feel the overall approach is wrong: originally I used hardcoded
"=" and "&&" operators, and you asked me to look them up by strategy
number instead. But that leads to trouble with core gist types vs
btree_gist types. The core gist opclasses use
On Sun, Nov 19, 2023 at 1:24 PM Paul A Jungwirth
wrote:
>
> Thank you for continuing to review this submission! My changes are in
> the v18 patch I sent a few days ago. Details below.
>
> On Sun, Oct 29, 2023 at 5:01 PM jian he wrote:
> > * The attached patch makes foreign keys with PERIOD fail
On Mon, Nov 6, 2023 at 11:07 PM jian he wrote:
> +
> + In a temporal foreign key, the delete/update will use
> + FOR PORTION OF semantics to constrain the
> + effect to the bounds being deleted/updated in the referenced row.
> +
>
> The first "para"
Thank you for continuing to review this submission! My changes are in
the v18 patch I sent a few days ago. Details below.
On Sun, Oct 29, 2023 at 5:01 PM jian he wrote:
> * The attached patch makes foreign keys with PERIOD fail if any of the
> foreign key columns is "generated columns".
I don't
based on v17.
begin;
drop table if exists s1;
CREATE TABLE s1 (id numrange, misc int, misc1 text);
create role test101 login;
grant update, select on s1 to test101;
insert into s1 VALUES ('[1,1000]',2);
set session authorization test101;
update s1 set id = '[1,1000]';
savepoint sp1;
update s1
On 11/9/23 05:47, Peter Eisentraut wrote:
I went over the patch
v17-0001-Add-temporal-PRIMARY-KEY-and-UNIQUE-constraints.patch in more
detail
Thanks Peter!
I'm about halfway through jian he's last two emails. I'll address your
feedback also. I wanted to reply to this without waiting though:
On 02.11.23 21:21, Paul Jungwirth wrote:
New patches attached (rebased to 0bc726d9).
I went over the patch
v17-0001-Add-temporal-PRIMARY-KEY-and-UNIQUE-constraints.patch in more
detail. Attached is a fixup patch that addresses a variety of cosmetic
issues.
Some details:
- Renamed
hi. based on v17. I found several doc related issues. previously I
didn't look closely
+
+ In a temporal foreign key, the delete/update will use
+ FOR PORTION OF semantics to constrain the
+ effect to the bounds being deleted/updated in the referenced row.
hi.
* The attached patch makes foreign keys with PERIOD fail if any of the
foreign key columns is "generated columns".
* The following queries will cause segmentation fault. not sure the
best way to fix it. the reason
in LINE: numpks = transformColumnNameList(RelationGetRelid(pkrel),
V16 patch doc/src/sgml/html/sql-createtable.html doc SET NULL description:
`
SET NULL [ ( column_name [, ... ] ) ]
Set all of the referencing columns, or a specified subset of the
referencing columns, to null. A subset of columns can only be
specified for ON DELETE actions.
In a temporal foreign
On Wed, Oct 11, 2023 at 12:47 PM Paul Jungwirth
wrote:
>
> On 9/25/23 14:00, Peter Eisentraut wrote:
> > Looking through the tests in v16-0001:
> >
> > +-- PK with no columns just WITHOUT OVERLAPS:
> > +CREATE TABLE temporal_rng (
> > + valid_at tsrange,
> > + CONSTRAINT
hi. also based on v16.
-tests.
drop table if exists for_portion_of_test1;
CREATE unlogged TABLE for_portion_of_test1 (id int4range, valid_at
tsrange,name text );
INSERT INTO for_portion_of_test1 VALUES ('[1,1]', NULL,
'[1,1]_NULL'),('[1,1]', '(,)', '()_[1,]')
,('[1,1]', 'empty',
Hi.
based on v16.
/* Look up the FOR PORTION OF name requested. */
range_attno = attnameAttNum(targetrel, range_name, false);
if (range_attno == InvalidAttrNumber)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("column or period \"%s\" of relation \"%s\" does not exist",
range_name,
On Tue, Sep 26, 2023 at 4:21 AM Paul Jungwirth
wrote:
>
> On 9/24/23 21:52, jian he wrote:
> > On Wed, Sep 20, 2023 at 10:50 AM Paul Jungwirth
> > wrote:
> >>
> >> On 9/17/23 20:11, jian he wrote:
> >>> small issues so far I found, v14.
> >>
> >> Thank you again for the review! v15 is attached.
On 10/11/23 05:47, Paul Jungwirth wrote:
+SELECT pg_get_indexdef(conindid, 0, true) FROM pg_constraint WHERE
conname = 'temporal_rng_pk';
+ pg_get_indexdef
+---
+ CREATE UNIQUE INDEX
On 9/25/23 14:00, Peter Eisentraut wrote:
Looking through the tests in v16-0001:
+-- PK with no columns just WITHOUT OVERLAPS:
+CREATE TABLE temporal_rng (
+ valid_at tsrange,
+ CONSTRAINT temporal_rng_pk PRIMARY KEY (valid_at WITHOUT OVERLAPS)
+);
+ERROR: syntax error at or near
Hi Peter et al,
On 9/1/23 12:56, Paul Jungwirth wrote:
On 9/1/23 11:30, Peter Eisentraut wrote:
I think the WITHOUT OVERLAPS clause should be per-column, so that
something like UNIQUE (a WITHOUT OVERLAPS, b, c WITHOUT OVERLAPS)
would be possible. Then the WITHOUT OVERLAPS clause would
On 25.09.23 21:20, Paul Jungwirth wrote:
On 9/24/23 21:52, jian he wrote:
On Wed, Sep 20, 2023 at 10:50 AM Paul Jungwirth
wrote:
On 9/17/23 20:11, jian he wrote:
small issues so far I found, v14.
Thank you again for the review! v15 is attached.
hi. some tiny issues.
Rebased v16
On Wed, Sep 20, 2023 at 10:50 AM Paul Jungwirth
wrote:
>
> On 9/17/23 20:11, jian he wrote:
> > small issues so far I found, v14.
>
> Thank you again for the review! v15 is attached.
>
hi. some tiny issues.
IN src/backend/utils/adt/ri_triggers.c
else {
appendStringInfo(, "SELECT 1 FROM %s%s x",
On Fri, Sep 15, 2023 at 12:11 AM Paul Jungwirth
wrote:
>
> Thanks for the thorough review and testing!
>
> Here is a v14 patch with the segfault and incorrect handling of NO
> ACTION and RESTRICT fixed (and reproductions added to the test suite).
>
another case:
BEGIN;
DROP TABLE IF EXISTS
On Fri, Sep 15, 2023 at 12:11 AM Paul Jungwirth
wrote:
>
>
> I'll keep working on a patch to support multiple range keys, but I
> wanted to work through the rest of the feedback first. Also there is
> some fixing to do with partitions I believe, and then I'll finish the
> PERIOD support. So this
On 9/7/23 18:24, jian he wrote:
for a range primary key, is it fine to expect it to be unique, not
null and also not overlap? (i am not sure how hard to implement it).
-
quote from 7IWD2-02-Foundation-2011-12.pdf. 4.18.3.2 Unique
hi. some trivial issue:
in src/backend/catalog/index.c
/* * System attributes are never null, so no need to check. */
if (attnum <= 0)
since you already checked attnum == 0
so here you can just attnum < 0?
-
ERROR: column "valid_at" named in
hi
I am confused by (pk,fk) on delete on update (restriction and no
action) result based on v13.
related post:
https://stackoverflow.com/questions/14921668/difference-between-restrict-and-no-action
Please check the following test and comments.
---common setup for test0, test1,test2,test3
BEGIN;
On Fri, Sep 8, 2023 at 2:35 AM jian he wrote:
>
> hi.
> the following script makes the server crash (Segmentation fault).
> [snip]
>
> ALTER TABLE temporal_fk_rng2rng
> ADD CONSTRAINT temporal_fk_rng2rng_fk
> FOREIGN KEY (parent_id, PERIOD valid_at)
> REFERENCES temporal_rng
> on update
hi.
the following script makes the server crash (Segmentation fault).
create schema test;
set search_path to test;
DROP TABLE IF EXISTS temporal_rng;
CREATE TABLE temporal_rng (id int4range, valid_at daterange);
ALTER TABLE temporal_rng
ADD CONSTRAINT temporal_rng_pk
PRIMARY KEY (id, valid_at
On Sat, Sep 2, 2023 at 5:58 AM Paul Jungwirth
wrote:
>
>
> I don't quite understand this part:
>
> >> Also, your implementation
> >> requires at least one non-overlaps column, which also seems like a
> >> confusing restriction.
>
> That's just a regular non-temporal constraint. Right? If I'm
On 9/1/23 21:56, Paul Jungwirth wrote:
On 9/1/23 03:50, Vik Fearing wrote:
On 9/1/23 11:30, Peter Eisentraut wrote:
1) If I write UNIQUE (a, b, c WITHOUT OVERLAPS), does the WITHOUT
OVERLAPS clause attach to the last column, or to the whole column
list? In the SQL standard, you can only have
On 9/1/23 03:50, Vik Fearing wrote:
On 9/1/23 11:30, Peter Eisentraut wrote:
1) If I write UNIQUE (a, b, c WITHOUT OVERLAPS), does the WITHOUT
OVERLAPS clause attach to the last column, or to the whole column
list? In the SQL standard, you can only have one period and it has to
be listed
On 9/1/23 11:30, Peter Eisentraut wrote:
1) If I write UNIQUE (a, b, c WITHOUT OVERLAPS), does the WITHOUT
OVERLAPS clause attach to the last column, or to the whole column list?
In the SQL standard, you can only have one period and it has to be
listed last, so this question does not arise.
On 31.08.23 23:26, Paul Jungwirth wrote:
I've tried to clean up the first four patches to get them ready for
committing, since they could get committed before the PERIOD patch. I
think there is a little more cleanup needed but they should be ready for
a review.
Looking at the patch 0001 "Add
>
> The PERIOD patch is not finished and includes some deliberately-failing
> tests. I did make some progress here finishing ALTER TABLE ADD PERIOD.
>
If it's ok with you, I need PERIODs for System Versioning, and planned on
developing a highly similar version, albeit closer to the standard. It
On Fri, Jul 7, 2023 at 9:04 AM Paul A Jungwirth
wrote:
>
> On Thu, Jul 6, 2023 at 1:13 AM Peter Eisentraut
> wrote:
> >
> > I had talked to Paul about this offline a while ago. btree_gist to core
> > is no longer considered a prerequisite. But Paul was planning to
> > produce a new patch set
On 07.07.23 03:03, Paul A Jungwirth wrote:
Here are some new patch files based on discussions from PGCon.
Here are a few fixup patches to get things building without warnings and
errors.
The last patch (your 0005) fails the regression test for me and it
didn't appear to be a trivial
> On 6 Jul 2023, at 10:12, Peter Eisentraut
> wrote:
> it would make sense to either close this entry as returned with feedback, or
> move it to the next commit fest as waiting on author.
Fair enough, done.
--
Daniel Gustafsson
1 - 100 of 119 matches
Mail list logo
