Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identitycolumn - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identitycolumn
Date
Msg-id 20180308080858.GE1788@paquier.xyz
Whole thread Raw
In response to Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identitycolumn  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identitycolumn  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List 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

Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15101: function set search_path = '' breaks dump/restore
Next
From: Michael Paquier
Date:
Subject: Re: BUG #15101: function set search_path = '' breaks dump/restore