From: | Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_get_triggerdef in pg_dump |
Date: | 2003-06-19 10:17:20 |
Message-ID: | 3EF18DB0.6090408@web.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>>Yes, you can check if they're binary compatible from the pg_cast table....
>>
>>
>
>But nearly all of the interesting cases require you to understand the
>type's interpretation of typmod, and you can't learn that from a table.
>How many cases are there where blindly looking for a binary-compatible
>cast in pg_cast will really do you much good? AFAICS you'd have to set
>atttypmod to -1 if you change atttypid without knowing very specifically
>what you are changing from and to.
>
>
>
AFAICS there's few interpretation about atttypmod necessary because only
few datatypes binary convertible (castfunc=0) do use atttypmod at all.
Most special case is varchar<->text, one supporting length, the other
not; both need atttypmod=-1. bpchar<->varchar both allow typmod in a
similar fashion.
It's already implemented in pgAdmin3 this way.
Regards,
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2003-06-19 10:32:07 | Re: allowed user/db variables |
Previous Message | Andrew Dunstan | 2003-06-19 10:12:36 | Re: Two weeks to feature freeze |