Re: Survey: renaming/removing script binaries (createdb, createuser...) - Mailing list pgsql-general

From Ron Mayer
Subject Re: Survey: renaming/removing script binaries (createdb, createuser...)
Date
Msg-id 47EAA53C.3080408@cheapcomplexdevices.com
Whole thread Raw
In response to Re: Survey: renaming/removing script binaries (createdb, createuser...)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:
> "Leif B. Kristensen" <leif@solumslekt.org> writes:
>> On Wednesday 26. March 2008, Ron Mayer wrote:
>>> I'd prefer a "pg" program that took as arguments
>>> the command.  So you'd have "pg createdb" instead
>>> of "pg_createdb".
>
> 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.

If it'd help make it happen, I could work on a patch as a
strawman.

> One fairly serious objection is that doing so would eliminate the
> current distinction between client-side and server-side applications,
> at least if we wanted to fold both sets into one "pg" executable.
> So a client-only install would be carrying some baggage in the form
> of code that's useless if the server isn't local.
>
> If we are OK with restricting the scope of the "pg" program to
> client-side functionality, then there's no problem.

Could it detect if the server side components aren't installed
and give a "server components aren't installed" error message
if they aren't available?    This could probably be handled
reasonably portably if the "pg" program called a separate
executable for the server functionality behind the scenes.

 From a user point of view, I think the single executable's
nice.   From an installer point of view, I think keeping
them separate is nice.  Seems both would be possible this
way, tho.


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: page is uninitialized --- fixing
Next
From: Alvaro Herrera
Date:
Subject: Re: page is uninitialized --- fixing