Re: Use T_IntList for uint32

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Subject: Re: Use T_IntList for uint32
Date: 2020-09-01 05:27:15
Message-ID: 26536.1598938035@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Mon, Aug 31, 2020 at 5:44 PM Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>> May be we should have separate list APIs for XID like OID, in case we
>> change underlying datatype of XID in future (unlikely but we have had
>> discussion about 64bit XIDs in the past). Apart from that it helps us
>> track code which deals with XID lists.

> This is a valid point but I think for now I will go with Tom's
> suggestion as the demand for this seems low at this stage. I don't
> want to introduce a new set of APIs just for one use case especially
> when we can work with existing APIs.

I've occasionally wondered about having exactly two physical List
implementations, one for 32-bit payloads and one for 64-bit payloads, and
then putting a trivial macros-or-static-inlines layer in front of that
that uses casts to supply variants for pointers, signed ints, unsigned
ints, etc etc. There hasn't yet been enough reason to pursue doing it
though.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-09-01 05:41:09 Re: Remove line length restriction in passwordFromFile()
Previous Message Kyotaro Horiguchi 2020-09-01 04:59:25 Re: "cert" + clientcert=verify-ca in pg_hba.conf?