Re: Extensions, patch v16
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Cc: "David E. Wheeler" <david@kineticode.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2010-12-10T15:32:56Z
Lists: pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: > "David E. Wheeler" <david@kineticode.com> writes: >>> What if $extension.control exists? Is it a byproduct of the .in file >>> from previous `make` run or a user file? What if we have both the .in >>> and the make variable because people are confused? Or both the make >>> variables and a .control and not .control.in? Etc... >> * Always remove $extension.control in the `clean` targets > Hell no, as you can bypass the .in mechanism and provide directly the > .control file. Are there any actual remaining use-cases for that sed step? It's certainly vestigial as far as the contrib modules are concerned: it would be simpler and more readable to replace MODULE_PATHNAME with $libdir in the sources. Unless somebody can point to a real-world use-case, I'd just as soon get rid of the .in files altogether while we're having this flag day. regards, tom lane