On 1/7/17 1:16 PM, Ryan Murphy wrote:

    No, and TBH I would vote strongly against including that much detail in
    this error message anyway.  That info could be indefinitely long,
    and it's
    not especially relevant to the stated error condition --- for
    example, the
    presence of a default is *not* relevant to whether the column
    matches the
    parent.  I'm okay with shoehorning column type into this message,
    but not
    much more than that.

                            regards, tom lane

Ok, that makes sense.  How about things like NOT NULL? you get an error
if your column doesn't have that.

Yeah, anything that we're explicitly testing for needs to be mentioned in an error message, otherwise users will be very confused if the column *is* in the parent but is failing some other test. Perhaps it would be better for each test to spit out a different error message making it clear what exactly was wrong.

Related to the other idea of seeing the problems that exist in all the columns (instead of one column at a time), I think it'd be reasonable to have a SRF that spit out everything you'd need to fix to allow inheritance to be added. A schema diff won't know what specifically has to match, but our code does.
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to