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
|
Список | 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 по дате отправления: