Re: SQL:2011 application time

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SQL:2011 application time
Date: 2023-11-09 13:47:12
Message-ID: fd41e772-296e-43e9-a70e-2e27bb8b1cd5@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 contemporal to conwithoutoverlaps, as previously discussed.
Also renamed various variables and function arguments similarly.

- Rearranged text in CREATE TABLE reference page so there are no forward
references. (Describe WITHOUT OVERLAPS under UNIQUE and then PRIMARY
KEy says "see above", rather than describe it under PRIMARY KEY and have
UNIQUE say "see below.)

- Removed various bits that related to temporal foreign keys, which
belong in a later patch.

- Reverted some apparently unrelated changes in src/backend/catalog/index.c.

- Removed the "temporal UNIQUE" constraint_type assignment in
DefineIndex(). This is meant to be used in error messages and should
refer to actual syntax. I think it's fine without it this change.

- Field contemporal in NewConstraint struct is not used by this patch.

- Rearrange the grammar so that the rule with WITHOUT OVERLAPS is just a
Boolean attribute rather than column name plus keywords. This was kind
of confusing earlier and led to weird error messages for invalid syntax.
I kept the restriction that you need at least one non-overlaps column,
but that is now enforced in parse analysis, not in the grammar. (But
maybe we don't need it?)

(After your earlier explanation, I'm content to just allow one WITHOUT
OVERLAPS column for now.)

- Some places looked at conexclop to check whether something is a
WITHOUT OVERLAPS constraint, instead of looking at conwithoutoverlaps
directly.

- Removed some redundant "unlike" entries in the pg_dump tests. (This
caused cfbot tests to fail.)

- Moved the "without_overlaps" test later in the schedule. It should at
least be after "constraints" so that normal constraints are tested first.

Two areas that could be improved:

1) In src/backend/commands/indexcmds.c,
get_index_attr_temporal_operator() has this comment:

+ * This seems like a hack
+ * but I can't find any existing lookup function
+ * that knows about pseudotypes.

This doesn't see very confident. ;-) I don't quite understand this. Is
this a gap in the currently available APIs, do we need to improve
something here, or does this need more research?

2) In src/backend/parser/parse_utilcmd.c, transformIndexConstraint(),
there is too much duplication between the normal and the if
(constraint->without_overlaps) case, like the whole not-null constraints
stuff at the end. This should be one code block with a few conditionals
inside. Also, the normal case deals with things like table inheritance,
which the added parts do not. Is this all complete?

I'm not sure the validateWithoutOverlaps() function is needed at this
point in the code. We just need to check that the column exists, which
the normal code path already does, and then have the index creation code
later check that an appropriate overlaps operator exists. We don't even
need to restrict this to range types. Consider for example, it's
possible that a type does not have a btree equality operator. We don't
check that here either, but let the index code later check it.

Overall, with these fixes, I think this patch is structurally okay. We
just need to make sure we have all the weird corner cases covered.

Attachment Content-Type Size
0001-fixup-Add-temporal-PRIMARY-KEY-and-UNIQUE-constraint.patch.nocfbot text/plain 49.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Maxim Orlov 2023-11-09 13:49:00 Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
Previous Message Amit Kapila 2023-11-09 13:28:28 Re: A recent message added to pg_upgade