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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pg_ugprade test failure on data set with column with defaultvalue with type bit/varbit
Дата
Msg-id CA+TgmoaDOLJaKvKbQWkHM18yFwZGdEmjvnvQHu0=_vBg0oitaA@mail.gmail.com
обсуждение исходный текст
Ответ на pg_ugprade test failure on data set with column with default valuewith type bit/varbit  (Paul Guo <paulguo@gmail.com>)
Ответы Re: pg_ugprade test failure on data set with column with defaultvalue with type bit/varbit  (Paul Guo <paulguo@gmail.com>)
Список pgsql-hackers
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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Transactions involving multiple postgres foreign servers
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)