| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RelationGetIndexAttrBitmap() small deviation between comment and code |
| Date: | 2019-01-21 23:03:10 |
| Message-ID: | CAKJS1f95Dyf8Qkdz4W+PbCmT-HTb54tkqUCC8isa2RVgSJ_pXQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
(This is pretty minor, but I struggled to ignore it)
In RelationGetIndexAttrBitmap() a comment claims /* We return our
original working copy for caller to play with */. 3 of the 4 possible
Bitmapsets follow that comment but for some reason, we make a copy of
the primary key attrs before returning. This seems both unnecessary
and also quite out of sync to what all the other Bitmapsets do. I
don't quite see any reason for doing it so I assume there's none.
The attached removes the bms_copy() and just returns the set that's
already been built in the same memory context.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| relationgetindexattrbitmap_fix.patch | application/octet-stream | 472 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-01-21 23:10:53 | Re: Allowing extensions to find out the OIDs of their member objects |
| Previous Message | Andres Freund | 2019-01-21 22:42:02 | Re: should ConstraintRelationId ins/upd cause relcache invals? |