On 17 October 2012 09:10, Markus Wanner <mar...@bluegap.ch> wrote: > Simon, > > On 10/16/2012 02:36 PM, Simon Riggs wrote: >> Where else would you put the hook? The hook's location as described >> won't change whether you decide you want 1, 2 or 3. > > You assume we want an API that supports all three options. In that case, > yes, the hooks need to be very general.
I'm not assuming that, so much of what you say is moot, though it is good and welcome input. > Given that option 3 got by far the most support, I question whether we > need such a highly general API. I envision an API that keeps the > bookkeeping and cache lookup functionality within Postgres. So we have a > single, combined-effort, known working implementation for that. IMHO an API is required for "give me the next allocation of numbers", essentially a bulk equivalent of nextval(). Anything lower level is going to depend upon implementation details that I don't think we should expose. I'm sure there will be much commonality between 2 similar implementations, just as there is similar code in each index type. But maintaining modularity is important and ahead of us actually seeing 2 implementations, trying to prejudge that is going to slow us all down and likely screw us up. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
