Tom Lane wrote:
> 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
> AFAICS, what Ryan is after would be better served by a separate tool that
> would produce a "diff" of the two tables' schemas.
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
> 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)?
>
>
I'm open to this option as well. The only parts I really care about are
the type and the NOT NULL, since those are the ones that will give you an
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
On 01/07/2017 11:05 PM, Tom Lane wrote:
> 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
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 ---
On 01/07/2017 08:15 PM, Tom Lane wrote:
> Ryan Murphy writes:
>> I was hoping for
>> user=# alter table temp inherit entity;
>> ERROR: child table is missing column "id" uuid default uuid_generate_v1mc()
>> Is there an easy way to get the string that includes all those
> 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
Ryan Murphy writes:
> So I tried using format_type_with_typemod() thinking that the "typemod
> info" meant things like NOT NULL, DEFAULT etc.
No, it means atttypmod, which stores info like the max length for
varchar(n).
> when I was hoping for
> user=# alter table temp
> Thanks Tom, I'll redo the patch using one of those, and get back to you
> guys.
>
>
So I tried using format_type_with_typemod() thinking that the "typemod
info" meant things like NOT NULL, DEFAULT etc. It builds and includes the
plain type but not all that stuff. E.g.
user=# alter table temp
> The approved way to do this is with format_type_be(), or
> format_type_with_typemod() if you want to include typmod info, which
> I think you probably do for the intended use-case.
>
> regards, tom lane
>
Thanks Tom, I'll redo the patch using one of those, and get back
Ryan Murphy writes:
> The attached patch is my initial attempt at adding the type, making the
> error message read e.g.:
> ERROR: child table is missing column "name" text
"... column "name" of type text", perhaps? Does not read very nicely
as is.
> I'm sure it needs
12 matches
Mail list logo