Excerpts from Tom Lane's message of mar abr 19 14:12:46 -0300 2011: > Alvaro Herrera <[email protected]> writes: > > Excerpts from Tom Lane's message of mar abr 19 12:29:04 -0300 2011: > >> I'm intending to revert last week's patch in favor of this approach, > >> at least in HEAD. It'll be slightly more invasive than the previous > >> patch because of the API change for index_build, so I'm not sure whether > >> to back-patch or not --- comments? > > > Maybe add a new function index_build_ext that has the API change, and > > keep the existing index_build as a wrapper that keeps the current > > behavior. In HEAD just change the API of index_build and make > > index_build_ext a macro on top of the function (or just make it > > disappear.) > > Not sure it's worth that amount of trouble. index_build is pretty far > down in the nest of code that manages index (re)building --- is it at > all likely that third-party code is calling it directly?
Then why bother keeping the API unchanged? If you're correct, it would be pointless. > And even more to the point, if there is such third-party code, we don't > want the fix to fail to operate when a reindex is invoked through that > code path rather than the core paths. So if you think there's a > realistic risk of this, we probably shouldn't back-patch. After actually having a look at the API, I don't. -- Álvaro Herrera <[email protected]> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
