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 20180305061325.GF2266@paquier.xyz
Whole thread Raw
In response to Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identity column  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identity column  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Mon, Mar 05, 2018 at 12:44:32AM -0500, Tom Lane wrote:
> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>> "Michael" == Michael Paquier <michael@paquier.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

Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identity column
Next
From: Michael Paquier
Date:
Subject: Re: BUG #14999: pg_rewind corrupts control file global/pg_control