| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Subject: | Re: pg_upgrade fails to detect unsupported arrays and ranges |
| Date: | 2019-11-10 22:26:09 |
| Message-ID: | 11F789E7-EEF1-40C6-97CF-1D8F3B4BB66F@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 10 Nov 2019, at 22:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>> + /* arrays over any type selected so far */
>>> + " SELECT t.oid FROM pg_catalog.pg_type t, x WHERE typelem = x.oid AND typtype = 'b' "
>
>> No need to check typlen?
>
> Yeah, that's intentional. A fixed-length array type over a problematic
> type would be just as much of a problem as a varlena array type.
> The case shouldn't apply to any of the existing problematic types,
> but I was striving for generality.
That makes a lot of sense, thanks for the explanation.
cheers ./daniel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2019-11-10 22:39:14 | Re: pg_upgrade fails to detect unsupported arrays and ranges |
| Previous Message | Justin Pryzby | 2019-11-10 21:29:28 | psql \d for wide tables / pattern for individual columns |