Simon, On 10/17/2012 10:34 AM, Simon Riggs wrote: > IMHO an API is required for "give me the next allocation of numbers", > essentially a bulk equivalent of nextval().
Agreed. That pretty exactly matches what I described (and what's implemented in Postgres-R). The API then only needs to be called every N invocations of nextval(), because otherwise nextval() can simply return a cached number previously allocated in a single step, eliminating a lot of the communication overhead. You realize an API at that level doesn't allow for an implementation of options 1 and 2? (Which I'm convinced we don't need, so that's fine with me). > Anything lower level is going to depend upon implementation details > that I don't think we should expose. Exactly. Just like we shouldn't expose other implementation details, like writing to system catalogs or WAL. > 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. Agreed. Let me add, that modularity only serves a purpose, if the boundaries between the modules are chosen wisely. It sounds like we are on the same page, though. To testify this: IMHO an API for setval() is required to invalidate all node's caches and re-set an initial value, as a starting point for the next bulk of numbers that nextval() will return. currval() doesn't need to be changed or "hooked" at all, because it's a read-only operation. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
