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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, evgeni-klimov(at)yandex(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identity column
Date: 2018-03-08 08:08:58
Message-ID: 20180308080858.GE1788@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2018-03-08 08:19:55 Re: BUG #15101: function set search_path = '' breaks dump/restore
Previous Message PG Bug reporting form 2018-03-08 06:59:21 BUG #15101: function set search_path = '' breaks dump/restore