| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] A design for amcheck heapam verification |
| Date: | 2017-11-29 05:54:39 |
| Message-ID: | CAH2-Wzne=DYx5UoRFwB_+-cJKPAn3XB4-5s5BP7=Wg0jkgDjbQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 28, 2017 at 9:50 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
>> Would that address your concern? There would be an SQL interface, but
>> it would be trivial.
>
> That's exactly what I think you should do, and mentioned so upthread.
> A SQL interface can also show a good example of how developers can use
> this API.
My understanding of your earlier remarks, rightly or wrongly, was that
you wanted me to adopt the Bloom filter to actually be usable from SQL
in some kind of general way. As opposed to what I just said -- adding
a stub SQL interface that simply invokes the test harness, with all
the heavy lifting taking place in C code.
Obviously these are two very different things. I'm quite happy to add
the test harness.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2017-11-29 06:03:21 | Re: [HACKERS] A design for amcheck heapam verification |
| Previous Message | Michael Paquier | 2017-11-29 05:50:41 | Re: [HACKERS] A design for amcheck heapam verification |