On Tue, Aug 26, 2014 at 10:20 AM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote:
> On 04/14/2014 10:31 PM, Fabrízio de Royes Mello wrote: > >> On Tue, Apr 1, 2014 at 2:46 PM, Robert Haas <robertmh...@gmail.com> >> wrote: >> >>> >>> 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). >>> >>> >> The attached patch contains CINE for sequences. >> >> I just strip this code from the patch rejected before. >> > > Committed with minor changes: > > * The documentation promised too much. It said that it would not throw an > error "if a sequence with the same name exists". In fact, it will not throw > an error if any relation with the same name exists. I rewrote that > paragraph to emphasize that more, re-using the phrases from the CREATE > TABLE manual page. > > * don't call RangeVarGetAndCheckCreationNamespace unnecessarily when IF > NOT EXISTS is not used. > > Thanks! -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog: http://fabriziomello.github.io >> Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello >> Github: http://github.com/fabriziomello
