On Thu, Jun 19, 2014 at 12:32 PM, Greg Stark <st...@mit.edu> wrote: > On Wed, Jun 18, 2014 at 4:51 AM, Heikki Linnakangas > <hlinnakan...@vmware.com> wrote: >> Implementing something is a good way to demonstrate how it would look like. >> But no, I don't insist on implementing every possible design whenever a new >> feature is proposed. >> >> I liked Greg's sketch of what the opclass support functions would be. It >> doesn't seem significantly more complicated than what's in the patch now. > > As a counter-point to my own point there will be nothing stopping us > in the future from generalizing things. Dealing with catalogs is > mostly book-keeping headaches and careful work. it's something that > might be well-suited for a GSOC or first patch from someone looking to > familiarize themselves with the system architecture. It's hard to > invent a whole new underlying infrastructure at the same time as > dealing with all that book-keeping and it's hard for someone > familiarizing themselves with the system to also have a great new > idea. Having tasks like this that are easy to explain and that mentor > understands well can be easier to manage than tasks where the newcomer > has some radical new idea.
Generalizing this in the future would be highly likely to change the on-disk format for existing indexes, which would be a problem for pg_upgrade. I think we will likely be stuck with whatever the initial on-disk format looks like for a very long time, which is why I think we need to try rather hard to get this right the first time. -- 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
