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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Paul Guo <paulguo(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Richard Guo <guofenglinux(at)gmail(dot)com>
Subject: Re: pg_ugprade test failure on data set with column with default value with type bit/varbit
Date: 2018-05-10 19:08:31
Message-ID: CA+TgmoaDOLJaKvKbQWkHM18yFwZGdEmjvnvQHu0=_vBg0oitaA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 30, 2018 at 5:36 AM, Paul Guo <paulguo(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-05-10 19:37:04 Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Previous Message Robert Haas 2018-05-10 18:57:56 Re: [HACKERS] Transactions involving multiple postgres foreign servers