Re: pg_ugprade test failure on data set with column with defaultvalue with type bit/varbit

Поиск
Список
Период
Сортировка
От Paul Guo
Тема Re: pg_ugprade test failure on data set with column with defaultvalue with type bit/varbit
Дата
Msg-id CABQrizc90sfkZgi4=+0Bbp1Zu3yEx9sM4rjBE1YNCvzf3qKHkA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_ugprade test failure on data set with column with defaultvalue with type bit/varbit  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pg_ugprade test failure on data set with column with defaultvalue with type bit/varbit  (Robert Haas <robertmhaas@gmail.com>)
Re: pg_ugprade test failure on data set with column with default valuewith type bit/varbit  (Davy Machado <machado.davy@gmail.com>)
Re: pg_ugprade test failure on data set with column with defaultvalue with type bit/varbit  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
Thanks. I tentatively submitted a patch (See the attachment).

By the way, current pg_upgrade test script depends on the left data on test database, but it seems that
a lot of tables are dropped in those test SQL files so this affects the pg_upgrade test coverage much.
Maybe this needs to be addressed in the future. (Maybe when anyone checks in test cases pg_upgrade
needs to be considered also?)


2018-05-11 3:08 GMT+08:00 Robert Haas <robertmhaas@gmail.com>:
On Fri, Mar 30, 2018 at 5:36 AM, Paul Guo <paulguo@gmail.com> wrote:
> There is no diff in functionality of the dump SQLs, but it is annoying. The
> simple patch below could fix this. Thanks.
>
> --- a/src/backend/utils/adt/ruleutils.c
> +++ b/src/backend/utils/adt/ruleutils.c
> @@ -9389,7 +9389,7 @@ get_const_expr(Const *constval, deparse_context
> *context, int showtype)
>
>         case BITOID:
>         case VARBITOID:
> -           appendStringInfo(buf, "B'%s'", extval);
> +           appendStringInfo(buf, "'%s'", extval);
>             break;
>
>         case BOOLOID:

My first reaction was to guess that this would be unsafe, but looking
it over I don't see a problem.  For the other types handled in that
switch statement, we rely on the custom representation to avoid
needing a typecast, but it seems that for BITOID and VARBITOID we
insert a typecast no matter what.  So maybe the presence of absence of
the "B" makes no difference.

This logic seems to have been added by commit
c828ec88205a232a9789f157d8cf9c3d82f85152, Peter Eisentraut, vintage
2002.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Infinite loop on master shutdown
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: inconsistency and inefficiency in setup_conversion()