| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | "Leif B(dot) Kristensen" <leif(at)solumslekt(dot)org>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Survey: renaming/removing script binaries (createdb, createuser...) |
| Date: | 2008-03-26 21:06:07 |
| Message-ID: | 12487.1206565567@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> I like this too. It'd be considerably more work than the currently
>> proposed patch, though, since we'd have to meld the currently
>> separate programs into one executable.
> I note that we can continue to have the current executables stashed in
> PREFIX/share/libexec and let the "pg" executable exec them.
Not share/ surely, since these are executables, but yeah.
This brings me to the idea that "pg" is a very small stupid program
that just tries to match its first argument against a filename in
PREFIX/libexec/postgresql. If it finds a match it execs that program
with the remaining args, else it fails. If we do it that way then the
problem of a client-only installation is solved: it merely has a smaller
population of files in PREFIX/libexec, and "pg" doesn't know the
difference. Also the problem of optionally providing the old names just
reduces to providing links in bin/, whereas with a melded executable
we'd need still more smarts to look at how it'd been invoked.
So +2 or so for this one.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-03-26 21:07:04 | Re: Survey: renaming/removing script binaries (createdb, createuser...) |
| Previous Message | Paolo Saudin | 2008-03-26 20:50:45 | R: Survey: renaming/removing script binaries (createdb, createuser...) |