>> Marking this as Ready for committer. > > Thanks a ton for reviewing the patch.
I rewrote the comments for this patch and fixed the incorrect formatting in parse_relation.c. It used spaces instead of tabs, which is why if you look at the patch file you'll see that the alignment looked off. See new version, attached. However, I have a few residual questions: 1. Does copy.c also need to be fixed? I see that it also calls ExecConstraints(), and I don't see it setting tableOid anywhere. We certainly want COPY and INSERT to behave the same way. 2. Should constraints also allow access to the "oid" column? Right now you can do that but it doesn't seem to work, e.g.: rhaas=# create table foo (a int, check (oid::integer % 2 = 0)) with oids; CREATE TABLE rhaas=# insert into foo values (1); INSERT 16404 1 rhaas=# insert into foo values (1); INSERT 16405 1 rhaas=# insert into foo values (1); INSERT 16406 1 rhaas=# select oid, * from foo; oid | a -------+--- 16404 | 1 16405 | 1 16406 | 1 (3 rows) Just prohibiting that might be fine; it doesn't seem that useful anyway. But if we're setting the table OID, maybe we should set the OID too, and then just allow this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
sys_col_constr_v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers