On 01/07/2017 11:05 PM, Tom Lane wrote:
> Vik Fearing <vik@2ndquadrant.fr> 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.
Well personally, if I were trying to attach one table to another and it
didn't work, I'd use good ol' \d. Maybe that's just me.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support