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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Subject: Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identity column
Date: 2018-03-05 06:13:25
Message-ID: 20180305061325.GF2266@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Mar 05, 2018 at 12:44:32AM -0500, Tom Lane wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>> "Michael" == Michael Paquier <michael(at)paquier(dot)xyz> writes:
>> Michael> Perhaps it would be the occasion to introduce a T_Integer64
>> Michael> type for Value which gets stored as a string? And as far as I
>> Michael> can see defGetInt64 is only used by sequences.
>
>> The slightly misnamed T_Float is what's currently used for Value nodes
>> which contain numeric values as strings. So there'd be no point in a new
>> type tag if you're still going to store the value as a string.
>
> Going forward, maybe we should change the T_Integer case to either int64
> or int32, so that it's not got a platform-dependent range.

Serial columns using bigint as type would need int64 anyway, no? Why
int32?

> That's not a workable solution for back-patching into v10, though (and
> neither is T_Integer64, really).

Sure. For v10, using just T_Float should be doable at quick glance. I
have not checked though.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2018-03-05 07:54:31 Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Previous Message Tom Lane 2018-03-05 05:44:32 Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identity column