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:
http://www.postgresql.org/mailpref/pgsql-hackers
