On Thu, 17 Apr 2003, Dave Page wrote:
> Hi Ben
>
> > - 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?
Yes. But isn't serial just syntactic sugar for create sequence seqname;
then including that sequence in a default clause?
Personally, i could easily see a use for enum() covering the check in
constraint. MySQL users can use enum() at their leisure, postgresql users
can pick if up if they want to, and underneath it all is a check
constraint the user can see with /dt just like with serial.
> > - 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.
But at the same time, it's one of those gotchas that would be nice to get
rid of for people who just want a simple little database on their
workstation. It might be nice to have some kind of lazy auto vacuum
daemon installed by default and configured to run every hour or so
according to postgresql.conf.
> > - 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.
And let's face it, if we get tablespaces implemented, this kind of thing
goes awawy.
