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)