On Fri, Oct 15, 2010 at 5:35 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Oct 15, 2010 at 12:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> BTW, have we discussed the idea of embedding the role in the strategy >> number? For example, require regular operators to have strategy >> numbers 1-9999, while ordering operators have numbers 10000-19999, >> leaving room for a couple more roles before we have to rethink the >> assignment or widen amopstrategy to an int. That's a bit ugly but >> might be better than adding a separate role column. > > Yeah, we talked about it. > > http://archives.postgresql.org/pgsql-hackers/2010-02/msg01075.php > http://archives.postgresql.org/pgsql-hackers/2010-02/msg01079.php
Having said that, I'm not wild on having 5-key syscaches, even though the patch is ready to go (modulo whatever rebasing is needed, which probably isn't much). So if you can figure out a way to avoid it, let's do that. I still feel vaguely uneasy about the fact that the proposed patch can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit more last night when I read Peter's patch to add collation support. We could possibly cram ASC/DESC and NULLS FIRST/LAST in by defining four new categories of operator strategies rather than one, but there's no way that's going to work for collations. Is there some other way to approach this problem? Can we leave pg_amop as it is, and pass the context (sort vs. qual, ASC/DESC, NULLS FIRST/LAST, collation, whatever...) to the index via some sort of side channel? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
