Re: [HACKERS] Re: HISTORY for 6.5.2

> I think I can safely speak for a newbie and I happen to dislike
> createdb etc as well. I started out with postgreSQL with the
> intention of writing an application-specific CORBA front-end
> to it, so I cared most about the C++ interface. The existence of
> the createdb command confused me for a while, leaving me thinking
> I could do INSERT and SELECT etc from libpq++, but would have
> to resort to UNIX calls to do createdb.
>
> --Yu Cao
>

I would have to say that if you 'started out with theintention of writing
a corba front-and' then I dont think you can really speak for newbies.

When I started using postgresql I had vaguely heard of odbc and I had
a couple of example queries of SQL.

If I had had to go to template1 and create database whatever; and THEN
go use it, I would have been fairly confused.

The way I look at it, it is functionality that is THERE already. If you
remove it, you remove from the overall functionality of postgres. It doesnt
actually gain anything to remove it. Sure it looks a bit neater, but the end
user cares about being able to use it easilly, not if the scripts are
technically pleasing.

I think the problem described above comes from a lack in the documentation,
or a failure to read the relavent documentation. Having more functionality
is good. Removing it is counterproductive.

The arguement that was put forwards of 'if they want scripts they can write
them, let the admins learn and do it themselves' is a bad one IMHO. Is
it really desirable for a dozen people to be forced to write what is
effectively the same script? When the script is already there anyway?
We should be moving towards a lower learning curve to getting a basic
database up and running, not a higher one. Not all the users WANT to
have to write theirown scripts for everything. I know I certainly
dont.

Just my 2p worth

~Michael