| From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Extensions, patch v16 |
| Date: | 2010-12-10 17:30:49 |
| Message-ID: | BAA30F50-F3EB-4147-A1C2-E7C301C2BBF1@kineticode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Dec 10, 2010, at 12:26 AM, Dimitri Fontaine wrote:
> 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...
There are ways to deal with those issue, I'm sure.
>> * Always remove $extension.control in the `clean` targets
>
> Hell no, as you can bypass the .in mechanism and provide directly the
> .control file.
I'm saying disallow the .control file, only allow the control.in file.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2010-12-10 17:31:50 | Re: Extensions, patch v16 |
| Previous Message | Tom Lane | 2010-12-10 17:30:00 | Re: Extensions, patch v16 |