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