From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Markus Wanner <markus(at)bluegap(dot)ch> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Global Sequences |
Date: | 2012-10-17 08:34:12 |
Message-ID: | CA+U5nM+kE0bds+WSyXxKLh0U3JojsQ2cEepMv7P9i+yCz=2moA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 17 October 2012 09:10, Markus Wanner <markus(at)bluegap(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wanner | 2012-10-17 09:19:12 | Re: Global Sequences |
Previous Message | Markus Wanner | 2012-10-17 08:20:58 | Re: Global Sequences |