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
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 |