Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements
Date
Msg-id CA+TgmoZCxOzXEPNJYU8=j0BGNKX2gBx1JMvpd5-THxUuOJy3kA@mail.gmail.com
Whole thread Raw
In response to Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements
Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements
List pgsql-hackers
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).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: psql \d+ and oid display
Next
From: Robert Haas
Date:
Subject: Re: PQputCopyData dont signal error