Re: PATCH proposed with new features for CREATE TABLE - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: PATCH proposed with new features for CREATE TABLE
Date
Msg-id 200109072013.f87KD9I21181@candle.pha.pa.us
Whole thread Raw
In response to PATCH proposed with new features for CREATE TABLE  (jozzano <jozzano@exa.unicen.edu.ar>)
List pgsql-hackers
To get this applied, we will need to hear from people who want this
functionality.  Sorry.


> Hi people!.I  developed a work for an university course, which I wish to share with you.
> 
> I extended the foreign key clause in the create table in order to permit insertions and updates on a referencing
table(a table with foreign key
 
> attributes) with all kind of actions (the existing ones plus CASCADE, SET NULL and SET DEFAULT).
> 
> I think it is important to handle situations where the referencing data is available but it cannot be inserted due to
thelack of the referenced
 
> tuple. It is ugly, for example, to request the user to create a dummy referenced entry previous to the insertion
sinceit can be done
 
> automatically with the proposed functionality.
> Applying it in the context of a product with a well-defined execution model of triggers, like PostgreSQL, I do not
introduceany kind of
 
> indetermination in the sequence of verification of the referential constraints, because we know beforehand, depending
onthe order of creation of
 
> the tables and constraints, which will be the resulting order of the chain of verifications. So, when a referencing
tableis updated or tuples
 
> are added to it, even when this table is the origin of various referential chains of verifications, the resulting
behavioronly depends on the
 
> order of creation mentioned above. (I insist with the theme of determinism because I think this is the main problem
forwhich no database product
 
> includes this characteristic). I tested the code with examples of such cases (taking modified problematical examples
froma text of Markowitz)
 
> and it works well.
> 
> The new syntax for the column_constraint_clause (and table_constraint_clause) of the CREATE TABLE statement that I
propose(and implement) is:
 
> 
>      ...
>      [ ON INSERT action ]
>      [ ON DELETE action ]
>      [ ON UPDATE_LEFT action ]
>      [ ON UPDATE_RIGHT action ]
>      ...
> where
> 
> "ON DELETE action"
>    stays the same as before (it refers to deletes in the referenced table),
> 
> "ON UPDATE_RIGHT action"
>    is the original ON UPDATE action (like before, it refers to modifications in the referenced table),
> 
> "ON UPDATE_LEFT action"
>    specifies the action to do when a referencing column (a FK_column) in the referencing table is being updated to a
newvalue, and this new
 
> value do not exist like pk_value in the pk_table. If the row is updated, but the referencing column is not changed,
noaction is done. There are
 
> the following actions.
> 
>    NO ACTION
>           Disallows update of row.
> 
>    RESTRICT
>           Disallows update of row.
> 
>    CASCADE
>           Updates the value of the referenced column (the pk_column) to the new value of the
>           referencing column (the fk_column).
> 
>    SET NULL
>           Sets the referencing column values to NULL.
> 
>    SET DEFAULT
>           Sets the referencing column values to their default value.
> 
> "ON INSERT action"
>    specifies the action to do when a referencing row (a FK_row) in the referencing table is being inserted, and the
newfk_values do not exist
 
> like pk_values in the referenced table (pk_table). There are the following actions.
> 
>    NO ACTION
>           Disallows insert of row.
> 
>    RESTRICT
>           Disallows insert of row.
> 
>    CASCADE
>           Inserts a new row into the referenced table which pk_columns take the values of the new fk_columns, and the
otherattributes are set to
 
> NULL values (if it is allowed).
> 
>    SET NULL
>           Sets the referencing column values to NULL.
> 
>    SET DEFAULT
>           Sets the referencing column values to their default value.
> 
> I have not added new files, just modified the existing ones (so the makefiles stay like before). I  send a diff (-c)
againstthe version 7.0.2
 
> (the one I worked with).
> 
> In summary, the patch contains:
> 
> * modifications to the grammar to include the new syntax of the CREATE TABLE statement (to recognize the new tokens
anddo the appropriate
 
> stuff).
> 
> * Addition of definitions of flags and masks for FOREIGN KEY constraints in CreateStmt.
> 
> * the new generic trigger procedures for referential integrity constraint checks.
> 
> * modifications to the parser stage to accept them (in procedures transformCreateStmt() and
>    transformAlterTableStmt() ).
> 
> * update to declarations for operations on built-in types.
> 
> * extension of the definition of the system "procedure" relation (pg_proc) along with the
>    relation's initial contents.
> 
> * modifications to the TRIGGERs support code to accept the new characteristics.
> 
> Many thanks in advance to those who read and (maybe) consider all this, regards
> 
>                                         Jose Luis Ozzano  (jozzano@exa.unicen.edu.ar)
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://www.postgresql.org/search.mpl
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: Escaping strings for inclusion into SQL queries
Next
From: Tom Lane
Date:
Subject: Re: Re: Escaping strings for inclusion into SQL queries