| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 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 05:44:32 |
| Message-ID: | 21016.1520228672@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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. That's not a
workable solution for back-patching into v10, though (and neither is
T_Integer64, really).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-03-05 06:13:25 | Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identity column |
| Previous Message | Andrew Gierth | 2018-03-05 00:16:03 | Re: BUG #15096: Unable to CREATE TABLE LIKE with bigint identity column |