Re: SQL:2011 application time
Paul A Jungwirth <pj@illuminatedcomputing.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rename gist stratnum support function
- 32edf732e8dc 18.0 landed
-
Remove support for temporal RESTRICT foreign keys
- b83e8a2ca2eb 18.0 landed
-
Cache NO ACTION foreign keys separately from RESTRICT foreign keys
- 9926f854d077 18.0 landed
-
Fix NO ACTION temporal foreign keys when the referenced endpoints change
- 1772d554b089 18.0 landed
-
Improve whitespace in without_overlaps test
- 888d4523f0c2 18.0 landed
-
Tests for logical replication with temporal keys
- 939b0908c87a 18.0 landed
-
Support for GiST in get_equal_strategy_number()
- 74edabce7a33 18.0 landed
-
Make the conditions in IsIndexUsableForReplicaIdentityFull() more explicit
- 13544e790ef8 18.0 landed
-
Replace get_equal_strategy_number_for_am() by get_equal_strategy_number()
- a2a475b011cf 18.0 landed
-
Improve internal logical replication error for missing equality strategy
- 321c287351f7 18.0 landed
-
Simplify IsIndexUsableForReplicaIdentityFull()
- 7727049e8f66 18.0 landed
-
Fix ALTER TABLE / REPLICA IDENTITY for temporal tables
- 79b575d3bc09 18.0 landed
-
doc: Update pg_constraint.conexclop docs for WITHOUT OVERLAPS
- f683ba0867da 18.0 landed
-
doc: Add PERIOD to ALTER TABLE reference docs
- d56af4c882e2 18.0 landed
-
doc: Add WITHOUT OVERLAPS to ALTER TABLE reference docs
- bf621059500b 18.0 landed
-
Add temporal FOREIGN KEY contraints
- 89f908a6d0ac 18.0 landed
- 34768ee36165 17.0 landed
-
Add temporal PRIMARY KEY and UNIQUE constraints
- fc0438b4e805 18.0 landed
- 46a0cd4cefb4 17.0 landed
-
Add stratnum GiST support function
- 7406ab623fee 18.0 landed
- 6db4598fcb82 17.0 landed
-
Avoid crashing when a JIT-inlined backend function throws an error.
- 5d6c64d29097 17.0 cited
-
Revert temporal primary keys and foreign keys
- 8aee330af55d 17.0 landed
-
Fix ON CONFLICT DO NOTHING/UPDATE for temporal indexes
- 144c2ce0cc75 17.0 landed
-
Add test for REPLICA IDENTITY with a temporal key
- 482e108cd38d 17.0 landed
-
Use half-open interval notation in without_overlaps tests
- 5577a71fb0cc 17.0 landed
-
Use daterange and YMD in without_overlaps tests instead of tsrange.
- a88c800deb6f 17.0 landed
-
Rename pg_constraint.conwithoutoverlaps to conperiod
- 030e10ff1a36 17.0 landed
-
Fix comment on gist_stratnum_btree
- 86232a49a437 17.0 landed
-
Add missing TAP test name
- 1ab763fc22ad 16.0 cited
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Rename functions to avoid future conflicts
- ee419607381d 15.0 landed
Attachments
- v19-0001-Add-temporal-PRIMARY-KEY-and-UNIQUE-constraints.patch (text/x-patch) patch v19-0001
- v19-0002-Add-temporal-FOREIGN-KEYs.patch (text/x-patch) patch v19-0002
- v19-0003-Add-UPDATE-DELETE-FOR-PORTION-OF.patch (text/x-patch) patch v19-0003
- v19-0004-Add-CASCADE-SET-NULL-SET-DEFAULT-for-temporal-fo.patch (text/x-patch) patch v19-0004
- v19-0005-Add-PERIODs.patch (text/x-patch) patch v19-0005
Thank you again for such thorough reviews!
On Thu, Nov 16, 2023 at 11:12 PM jian he <jian.universality@gmail.com> 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 OF.
I don't think UPDATE/DELETE FOR PORTION OF is supposed to require INSERT permission.
Notionally the INSERTs are just to preserve what was there already, not to add new data.
The idea is that a temporal table is equivalent to a table with one row for every "instant",
i.e. one row per microsecond/second/day/whatever-time-resolution. Of course that would be too slow,
so we use PERIODs/ranges instead, but the behavior should be the same. Date's book has a good
discussion of this idea.
I also checked the SQL:2011 draft standard, and there is a section called Access Rules in Part 2:
SQL/Foundation for UPDATE and DELETE statements. Those sections say you need UPDATE/DELETE
privileges, but say nothing about needing INSERT privileges. That is on page 949 and 972 of the PDFs
from the "SQL:20nn Working Draft Documents" link at [1]. If someone has a copy of SQL:2016 maybe
something was changed, but I would be surprised.
I also checked MariaDB and IBM DB2, the only two RDBMSes that implement FOR PORTION OF to my
knowledge. (It is not in Oracle or MSSQL.) I created a table with one row, then gave another user
privileges to SELECT & UPDATE, but not INSERT. In both cases, that user could execute an UPDATE FOR
PORTION OF that resulted in new rows, but could not INSERT genuinely new rows. [2,3]
So instead of changing this I've updated the documentation to make it explicit that you do not need
INSERT privilege to use FOR PORTION OF. I also documented which triggers will fire and in which order.
> + <para>
> + If the table has a <link
> linkend="ddl-periods-application-periods">range column
> + or <literal>PERIOD</literal></link>, you may supply a
>
> should be
>
> + <para>
> + If the table has a range column or <link
> linkend="ddl-periods-application-periods">
> + <literal>PERIOD</literal></link>, you may supply a
>
> similarly the doc/src/sgml/ref/delete.sgml the link reference also broken.
Okay, changed.
> "given interval", "cut off" these words, imho, feel not so clear.
> We also need a document that:
> "UPDATE FOR PORTION OF" is UPDATE and INSERT (if overlaps).
> If the "UPDATE FOR PORTION OF" range overlaps then
> It will invoke triggers in the following order: before row update,
> before row insert, after row insert. after row update.
Okay, reworked the docs for this.
> src/test/regress/sql/for_portion_of.sql
> You only need to create two triggers?
> since for_portion_of_trigger only raises notice to output the triggers
> meta info.
Changed.
v19 patch series attached, rebased to a11c9c42ea.
[1] https://web.archive.org/web/20230923221106/https://www.wiscorp.com/SQLStandards.html
[2] MariaDB test:
First create a table as the root user:
```
create table t (id int, ds date, de date, name text, period for valid_at (ds, de));
insert into t values (1, '2000-01-01', '2001-01-01', 'foo');
```
and give another user select & update privlege (but not insert):
```
create database paul;
use paul;
create user 'update_only'@'localhost' identified by 'test';
grant select, update on paul.t to 'update_only'@'localhost';
flush privileges;
```
Now as that user:
```
mysql -uupdate_only -p
use paul;
-- We can update the whole record:
update t for portion of valid_at from '2000-01-01' to '2001-01-01' set name = 'bar';
-- We can update a part of the record:
update t for portion of valid_at from '2000-01-01' to '2000-07-01' set name = 'baz';
select * from t;
+------+------------+------------+------+
| id | ds | de | name |
+------+------------+------------+------+
| 1 | 2000-01-01 | 2000-07-01 | baz |
| 1 | 2000-07-01 | 2001-01-01 | bar |
+------+------------+------------+------+
-- We cannot insert:
insert into t values (2, '2000-01-01', '2001-01-01' 'another');
ERROR 1142 (42000): INSERT command denied to user 'update_only'@'localhost' for table `paul`.`t`
```
[3] IBM DB2 test:
```
mkdir ~/local/db2
cd ~/local/db2
tar xzvf ~/Downloads/v11.5.9_linuxx64_server_dec.tar.gz
cd server_dev
./db2_install # should put something at ~/sqllib
source ~/sqllib/db2profile
db2start # but I got "The database manager is already active."
db2
create database paul -- first time only, note no semicolon
connect to paul
create table t (id integer, ds date not null, de date not null, name varchar(4000), period
business_time (ds, de));
insert into t values (1, '2000-01-01', '2001-01-01', 'foo');
grant connect on database to user james;
grant select, update on t to user james;
```
Now as james:
```
source ~paul/sqllib/db2profile
db2
connect to paul
select * from paul.t;
update paul.t for portion of business_time from '2000-01-01' to '2000-06-01' set name = 'bar';
DB20000I The SQL command completed successfully.
select * from paul.t;
insert into paul.t values (2, '2000-01-01', '2001-01-01', 'bar');
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0551N The statement failed because the authorization ID does not have the
required authorization or privilege to perform the operation. Authorization
ID: "JAMES". Operation: "INSERT". Object: "PAUL.T". SQLSTATE=42501
```
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com