Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identitycolumn

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identitycolumn
Дата
Msg-id 20180308080858.GE1788@paquier.xyz
обсуждение исходный текст
Ответ на Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identitycolumn  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identitycolumn
Список pgsql-bugs
On Wed, Mar 07, 2018 at 03:16:44PM -0500, Peter Eisentraut wrote:
> Here is a patch that fixes this bug, and a second patch (not for
> backpatching) that changes the Value node to use int instead of long.

Thanks Peter for diving in.  Patch 1 looks fine to me.

Here are some comments for patch 2.

+       if (endptr != token + length || errno == ERANGE ||
+           /* check for overflow of int4 */
+           val != (long) ((int32) val))
            return T_Float;
It would be nice to have this check be consistent with the new
definition of ival and int32, One suggestion is to use directly int32 or
just have a static assertion that sizeof(int) == sizeof(int32)?  Or
that's too much nannyism?

By the way, why do you remove HAVE_LONG_INT_64?  On platforms where long
is 4 bytes this would still be a no-op.  If you care about those, you
could also remove the ones in interval.c and datetime.c...

The comment block on top of the definition of Value in value.h still
mentions "long", while it should mention "int" per your patch.
--
Michael

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15101: function set search_path = '' breaks dump/restore
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #15101: function set search_path = '' breaks dump/restore