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

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(at)gmail(dot)com>:

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