Thread: Bugs with like_option in CREATE TABLE
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 Keys
2. INCLUDING ALL does not work and generates an ERROR;
--
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.
>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.
My apologies.
I made a test case but this time it worked. I must have had a brain fart while I was working on this yesterday. Well, at least I am getting used to the taste of eating crow. :)On Thu, Sep 10, 2015 at 5:56 AM, hubert depesz lubaczewski <depesz@depesz.com> wrote:
On Wed, Sep 09, 2015 at 07:51:48PM -0400, Melvin Davidson wrote:
> *O/S = Windows 10PostgreSQL 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 Keys
Of course it doesn't. It's documented in the page you linked:
"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"
> 2. INCLUDING ALL does not work and generates an ERROR;*
Works for me. Please provide a test case that can be used to see the
error.
Best regards,
depesz
--
The best thing about modern society is how easy it is to avoid contact with it.
http://depesz.com/
--
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.