knngist patch support
in [PgSql]
|
Prev: [HACKERS] knngist patch support
Next: pgsql: Remove old-style VACUUM FULL (which wasknown for a little while
From: Tom Lane on 13 Feb 2010 15:02 Robert Haas <robertmhaas(a)gmail.com> writes: > On Sat, Feb 13, 2010 at 2:03 PM, Joshua Tolley <eggyknap(a)gmail.com> wrote: >> (Realizing I'm a lurker in this conversation, and hoping not to ask irritating >> questions) Do we need to rename SearchSysCache et al. to SearchSysCache1, >> etc.? It seems to me that requires changes to all kinds of software without >> any real need. The four lines of PL/LOLCODE that inspired this thought aren't >> themselves a great burden, but when combined with everyone else using >> SearchSysCache already... > If we want to allow 5-key syscaches, we have to add an extra parameter > to SearchSysCache and friends. So everyone caller of SearchSysCache > is going to break. (Well, unless we instead leave SearchSysCache > alone and add SearchSysCacheExtended or similar; but that's not really > project style.) It's fair to stop and think about how this would affect external packages and what they'd have to do to support building against both new and old-style backends. Reflecting on it, it seems to me that the separate SearchSysCacheN() macros are obviously cleaner and closer to preferred project style than the existing code with all those explicit zeroes. So I think there's a case for migrating to that style even if we didn't have a concern about the max number of lookup keys. What would probably be the recommended solution for backwards-compatible source code is to convert the actual calls to new style, and then provide a block of macro definitions along the lines of #if CATALOG_VERSION_NO < something #define SearchSysCache1(...) SearchSysCache(..., 0, 0, 0) #define SearchSysCache2(...) SearchSysCache(..., 0, 0) etc So that seems okay so far. What's not clear from this is whether we should reserve SearchSysCache as an equivalent to SearchSysCache4() and therefore name the underlying function something different. That would allow being lazy about converting individual calls over. I'm inclined to think not, and here's the reason: with the old call style it was never apparent from the callee side how many arguments the caller intended to be valid, and so for example we couldn't have an Assert that checked it was right. I'm not sure if we should go so far as to add an explicit nkeys argument to SearchSysCache, but it's worth thinking about at least. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Hitoshi Harada on 13 Feb 2010 14:21 2010/2/14 Robert Haas <robertmhaas(a)gmail.com>: > If we want to allow 5-key syscaches, we have to add an extra parameter > to SearchSysCache and friends. So everyone caller of SearchSysCache > is going to break. (Well, unless we instead leave SearchSysCache > alone and add SearchSysCacheExtended or similar; but that's not really > project style.) DirectFunctionCall1/2/3...? -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 13 Feb 2010 15:52 On Sat, Feb 13, 2010 at 2:38 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Hitoshi Harada <umi.tanuki(a)gmail.com> writes: >> And we don't have time to invent such new world. > > Huh? This is all discussion for 9.1 (or even later). There's > plenty of time. Just to be clear, I was intending this patch, at least, to be applied now. I actually think there's a good argument that we should do at least this much for 9.0, namely that now is probably the time when there are the fewest outstanding patches that will be broken by this. If we try to apply this for the first 9.1 CommitFest, then (1) it'll have to be completely redone and (2) it'll force massive rebasing. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 13 Feb 2010 14:38 Hitoshi Harada <umi.tanuki(a)gmail.com> writes: > And we don't have time to invent such new world. Huh? This is all discussion for 9.1 (or even later). There's plenty of time. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Yeb Havinga on 14 Feb 2010 11:01
Dimitri Fontaine wrote: > Then there's the metric space which is a data type with a distance > function. This function must be non-negative, commutative, etc. > > So I guess what we need here is a Operator Group to define our plus and > minus operators, and the fact that it's a group says (by convention, > like the total ordering of a BTree) that the + is commutative and the - > its opposite. Or we have an "option" called abelian for specifying the > commutativity? > Would the group analogy work with partially ordered domains, e.g. with a location on a sphere datatype together with an identifier for the sphere - so poi on earth can be compared to another, but not a poi on earth with a poi on the moon. ? regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |