>> 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

Attachment: 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

Reply via email to