Re: pg_upgrade test for binary compatibility of core data types
От | Peter Eisentraut |
---|---|
Тема | Re: pg_upgrade test for binary compatibility of core data types |
Дата | |
Msg-id | [email protected] обсуждение исходный текст |
Ответ на | Re: pg_upgrade test for binary compatibility of core data types (Justin Pryzby <[email protected]>) |
Ответы |
Re: pg_upgrade test for binary compatibility of core data types
Re: pg_upgrade test for binary compatibility of core data types |
Список | pgsql-hackers |
On 2020-12-27 20:07, Justin Pryzby wrote: > On Wed, Dec 16, 2020 at 11:22:23AM -0600, Justin Pryzby wrote: >> On Sun, Dec 06, 2020 at 12:02:48PM -0600, Justin Pryzby wrote: >>> I meant to notice if the binary format is accidentally changed again, which was >>> what happened here: >>> 7c15cef86 Base information_schema.sql_identifier domain on name, not varchar. >>> >>> I added a table to the regression tests so it's processed by pg_upgrade tests, >>> run like: >>> >>> | time make -C src/bin/pg_upgrade check oldsrc=`pwd`/11 oldbindir=`pwd`/11/tmp_install/usr/local/pgsql/bin >> >> Per cfbot, this avoids testing ::xml (support for which may not be enabled) >> And also now tests oid types. >> >> I think the per-version hacks should be grouped by logical change, rather than >> by version. Which I've started doing here. > > rebased on 6df7a9698bb036610c1e8c6d375e1be38cb26d5f I think these patches could use some in-place documentation of what they are trying to achieve and how they do it. The required information is spread over a lengthy thread. No one wants to read that. Add commit messages to the patches.
В списке pgsql-hackers по дате отправления: