On 01/07/2017 11:05 PM, Tom Lane wrote: > Vik Fearing <v...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
