Vik Fearing <> writes:
> On 01/07/2017 08:15 PM, Tom Lane 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.

> I agree.

> Perhaps the ERROR message should remain as is, and a DETAIL or HINT line
> could be emitted with the entire column definition (or close to it)?

AFAICS, what Ryan is after would be better served by a separate tool that
would produce a "diff" of the two tables' schemas.  Even if we were
willing to overload this error message with everything we know about the
parent column, do you really want to fix discrepancies one column at a
time?  And what about properties that can't be uniquely associated with a
single column, such as constraints covering multiple columns?

Also, I have a feeling that a suitable tool is already out there.  A
moment's digging in the list archives found this thread with links to
several candidates:

and I'm pretty sure there have been other such discussions.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to