| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: identity columns |
| Date: | 2017-04-04 17:28:44 |
| Message-ID: | 19455.1491326924@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 4/3/17 14:19, Andres Freund wrote:
> + *op->resvalue = Int64GetDatum(nextval_internal(op->d.nextvalueexpr.seqid, false));
>> Is it guaranteed that the caller expects an int64? I saw that
>> nextvalueexpr's have a typeid field.
> It expects one of the integer types. We could cast the result of
> Int64GetDatum() to the appropriate type, but that wouldn't actually do
> anything.
Uh, really? On 32-bit platforms, int64 and int32 datums have entirely
different representations.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-04-04 17:31:33 | Re: logical decoding of two-phase transactions |
| Previous Message | Masahiko Sawada | 2017-04-04 17:13:00 | Re: logical decoding of two-phase transactions |