On Tue, Apr 1, 2014 at 10:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'm willing to bend that to the extent of saying that COR leaves in place > subsidiary properties that you might add *with additional statements* --- > for example, foreign keys for a table, or privilege grants for a role. > But the properties of the role itself have to be predictable from the COR > statement, or it's useless.
+1.
>> Where this is a bit more interesting is in the case of sequences, where >> resetting the sequence to zero may cause further inserts into an >> existing table to fail. > > Yeah. Sequences do have contained data, which makes COR harder to define > --- that's part of the reason why we have CINE not COR for tables, and > maybe we have to do the same for sequences. The point being exactly > that if you use CINE, you're implicitly accepting that you don't know > the ensuing state fully.
Yeah. I think CINE is more sensible than COR for sequences, for precisely the reason that they do have contained data (even if it's basically only one value).
Well then I'll separate CINE for sequences for the previous rejected... is this a material for 9.5?
Regards,
--
Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL
