On 13/05/15 14:15, Heikki Linnakangas wrote:
>> I don't see what calamity will occur if we commit this. If you don't
>> want a
>> sequence AM, don't ever use this.
>
> I'd like the API to be good for its purpose. Also, I did mention that
> the the current patch makes the situation slightly worse for people who
> never use this: it makes the log_cnt field non human-readable. That's a
> really minor thing, but it shows that it *does* matter how this is
> implemented, even if you only ever use the local seq AM.
>
It definitely does matter.
I don't think we'll find perfect compromise here though, you can either
do it one way or the other. Trust me it does not make me happy either, I
like perfect solutions too, but when there is lack of perfect solution I
prefer the simpler one.
Both of the solutions have drawbacks - amdata has opaque blob which does not store data in user visible way
but that can be worked around by providing function that shows it in
human readable way (and the dump function for many sequence types
actually does that). - multiple columns basically kill any future ability to unify the
storage for sequences and also adds complexity, especially around alter
table (since it means drop/add column and stuff)
But I already wrote both versions anyway so from that perspective it
does not matter much which part we merge.
(As a side-node I would have preferred to have this discussion earlier
than 2 days before feature freeze because the current implementation is
something that we agreed on several months ago so there was plenty of
time to revisit that decision.)
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
