| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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 19:38:33 |
| Message-ID: | 26456.1520278713@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Mon, Mar 05, 2018 at 12:44:32AM -0500, Tom Lane wrote:
>> 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?
int32 might be less work to make fully portable. I don't recall exactly
what-all we do with T_Integer, but if we try to do sscanf() to produce the
value for instance, that's a problem. (Note that configure's tests for
64-bit support only cover sprintf, not sscanf.)
Certainly int64 would be a more forward-looking choice, it just seems
like possibly more work.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bossart, Nathan | 2018-03-05 21:55:13 | Re: BUG #14941: Vacuum crashes |
| Previous Message | Greg Clough | 2018-03-05 11:34:47 | RE: BUG #15067: Documentation or behaviour bug with autovacuum thresholds? |