Re: Bugs with like_option in CREATE TABLE - Mailing list pgsql-general
>1. INCLUDING CONSTRAINTS does not bring over the Foreign Keys
>Not a bug since the documentation states that the only additional constraints that are brought over are check constraints. Not Null constraints are always brought
>over.
Hmmm, The document would be a lot clearly if it simply stated Foreign Keys are NOT brought over.
Anyhow, I've found a work around for that,
>2. INCLUDING ALL does not work and generates an ERROR;
>For kicks does writing it out in long form work?
No. I tried INCLUDING ALL and just ALL by itself, both create a syntax error.
On Wed, Sep 9, 2015 at 8:51 PM, David G. Johnston <david.g.johnston@gmail.com> wrote:
O/S = Windows 10
PostgreSQL 9.2.10, compiled by Visual C++ build 1600, 32-bit
http://www.postgresql.org/docs/9.1/interactive/sql-createtable.html
and like_option is:
{ INCLUDING | EXCLUDING } { DEFAULTS | CONSTRAINTS | INDEXES | STORAGE | COMMENTS | ALL }
1. INCLUDING CONSTRAINTS does not bring over the Foreign KeysNot a bug since the documentation states that the only additional constraints that are brought over are check constraints. Not Null constraints are always brought over."""Not-null constraints are always copied to the new table. CHECK constraints will only be copied if INCLUDING CONSTRAINTS is specified; other types of constraints will never be copied. Also, no distinction is made between column constraints and table constraints — when constraints are requested, all check constraints are copied."""
2. INCLUDING ALL does not work and generates an ERROR;For kicks does writing it out in long form work?"""INCLUDING ALL is an abbreviated form of INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING COMMENTS."""David J.
--
Melvin Davidson
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
pgsql-general by date: