On Tue, Apr 1, 2014 at 2:46 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Apr 1, 2014 at 10:03 AM, Tom Lane <t...@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 >> Timbira: http://www.timbira.com.br >> Blog sobre TI: http://fabriziomello.blogspot.com >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello
