database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-02 09:02:37 +03:00
Code Activity

ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne,

Browse Source 
code review by Tom Lane.  Remaining issues: functions that take or
return tuple types are likely to break if one drops (or adds!)
a column in the table defining the type.  Need to think about what
to do here.

Along the way: some code review for recent COPY changes; mark system
columns attnotnull = true where appropriate, per discussion a month ago.
This commit is contained in:
Tom Lane
2002-08-02 18:15:10 +00:00
parent 5e6528adf7
commit 38bb77a5d1
44 changed files with 1823 additions and 891 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
src/backend/rewrite/rewriteDefine.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/rewrite/rewriteDefine.c,v 1.75 2002/07/16 05:53:34 tgl Exp $
* $Header: /cvsroot/pgsql/src/backend/rewrite/rewriteDefine.c,v 1.76 2002/08/02 18:15:07 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -257,6 +257,16 @@ DefineQueryRewrite(RuleStmt *stmt)
attr = event_relation->rd_att->attrs[i - 1];
attname = NameStr(attr->attname);
/*
* Disallow dropped columns in the relation. This won't happen
* in the cases we actually care about (namely creating a view
* via CREATE TABLE then CREATE RULE). Trying to cope with it
* is much more trouble than it's worth, because we'd have to
* modify the rule to insert dummy NULLs at the right positions.
*/
if (attr->attisdropped)
elog(ERROR, "cannot convert relation containing dropped columns to view");
if (strcmp(resdom->resname, attname) != 0)
elog(ERROR, "select rule's target entry %d has different column name from %s", i, attname);