Re: For the ametures. (related to "Are we losing momentum?") - Mailing list pgsql-hackers

Hi Ben

> -----Original Message-----
> From: Ben Clewett [mailto:B.Clewett@roadrunner.uk.com]
> Sent: 17 April 2003 10:45
> Cc: pgsql-hackers@postgresql.org
> Subject: [HACKERS] For the ametures. (related to "Are we
> losing momentum?")
>
>
> I am not a hacker of PgSQL, and new to Databases.  I was using MySQL
> under .NET, but was annoyed by their agressive licence agreements and
> immaturity.  (Their sales personel are also very rude.  One girl once
> told me that if I didn't like their licence terms I should just use
> flat-files instead.)

Probably more powerful ;-)

> -    A true Windows version which people can learn their craft on.

Coming with 7.4...

> -    Tools which look like Access, to do row level data
> editing with no SQL.

http://www.pgadmin.org/

It looks more like SQL Server's Enterprise Manager but does most if not
all of what I expect you need.

> -    Centrally located complete documentation in many
> consistent  easy to
> read formats, of the system and *ALL* API's, including
> in-line tutorials
> and examples.

The tarball includes the complete documentation in HTML format, and in
pgAdmin there's a searchable copy in the main chm help file.

> -    Data types like 'ENUM' which appeal to ametures.

Isn't that just syntactic sugar for a column with a check for specific
values on it?

> -    There are no administrative mandatorys.  Eg, VACUUM.
> (A stand-alone
> commercial app, like an Email client, will be contrainted by
> having to
> be an app and a DBA in one.)

PostgreSQL is by no means alone in this requirement. SQL Server for
example has 'optimizations' that are performed usually as part of a
scheduled maintenance plan and are analagous to vacuum in some ways.

> -    The tables (not innodb) are in different files of the
> same name.
> Allowing the OS adminitrator great ability.  EG, putting tables on
> separate partitions and therefore greatly speeding performance.

One reason for not doing this is that a table in PostgreSQL might span
mutiple files if it exceeds a couple of gigs in size.

> -    They have extensive backup support.  Including now,
> concurrent backup
> without user interuption or risk of inconsistency.

So does PostgreSQL (pg_dump/pg_dumpall).

Regards, Dave

PS, it's nice you decided not to go to the Dark Side :-)