Re: pg_upgrade fails to detect unsupported arrays and ranges
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade fails to detect unsupported arrays and ranges |
Дата | |
Msg-id | 4650.1573419943@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade fails to detect unsupported arrays and ranges (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: pg_upgrade fails to detect unsupported arrays and ranges
|
Список | pgsql-hackers |
Daniel Gustafsson <daniel@yesql.se> writes: > On 10 Nov 2019, at 20:07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Although this is a really straightforward patch and I've tested it >> against appropriate old versions (9.1 and 9.2), I'm very hesitant >> to shove it in so soon before a release wrap. Should I do that, or >> let it wait till after the wrap? > Having read the patch I agree that it's trivial enough that I wouldn't be > worried to let it slip through. However, given that we've lacked the check for > a few releases, is it worth rushing with the potential for a last-minute > "oh-shit"? Probably not, really --- the main argument for that is just that it'd fit well with the fixes Tomas already made. >> + /* 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. regards, tom lane
В списке pgsql-hackers по дате отправления: