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

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
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-12 17:45:26
Message-ID: ad522dc9-bbcd-3567-d64e-d4f261b68b08@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 3/8/18 03:08, Michael Paquier wrote:
> 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?

Fixed in the attached next version.

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

Right, but the compiler can optimize it away then. No need to have #ifdefs.

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

done

> If you care about those, you
> could also remove the ones in interval.c and datetime.c...

Actually, we could just use the strtoint() defined there and apply it
everywhere, so avoid repeating these patterns. Done so in an additional
patch.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
v2-0001-Fix-CREATE-TABLE-LIKE-with-bigint-identity-column.patch text/plain 6.0 KB
v2-0002-Change-internal-integer-representation-of-Value-n.patch text/plain 5.4 KB
v2-0003-Move-strtoint-to-common.patch text/plain 7.3 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2018-03-12 20:27:33 Re: BUG #15106: The AFTER trigger is created separately on view, and the DML operation can not trigger the trigger
Previous Message Félix GERZAGUET 2018-03-12 10:51:28 Re: BUG #15107: No good plans when row-level security is enabled