Re: [HACKERS] Enticing interns to PostgreSQL

From: Chris Travers <chris(at)travelamericas(dot)com>
To: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: [HACKERS] Enticing interns to PostgreSQL
Date: 2005-07-26 20:53:54
Message-ID: 42E6A2E2.4010101@travelamericas.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

Jim C. Nasby wrote:

>
>And what do we use as a platform for this?
>
><dons flame suit> Should we have a "Why you probably don't want to use
>MySQL" document somewhere on the site?
>
>
>
It would be better to have a "Benefits over MySQL" page. Something like:
* More robust error handling
* Better optimization
* Triggers
* Add your own language for stored procedures
* Add your own data types
* Better standards compliance
* Lower cost of development
* Fewer licensing issues

In fact, having a maintained feature sheet listing PostgreSQL, MySQL,
and FirebirdSQL probably wouldn't be a bad idea.

>The case I'm thinking of is when you have a small table that you want to
>have an enum-like field in; in such a case using an ID to reference
>another table every time you want to find a value probably doesn't make
>sense. But if you've got a moderately large number of allowable values
>(say more than a couple dozen), maintaining a check constraint to handle
>the ENUM might be a bear.
>
>
Probably the best way of doing this is to have a VARCHAR primary key in
the enum table (sole column), and a VARCHAR foreign key referencing it.

>But as you mentioned, if we're careful with syntax the type can always
>be expanded. Another interesting use case would be an enum that
>automatically adds new values to the lookup table if they don't already
>exist. I know it's no longer an enum in the traditional sense, but this
>is a common enough use case that it would be very convenient to have.
>
>
This could be done with triggers and deferred RI constraints. However,
how does it differ from a VARCHAR?

> Agreed and agreed. I'm absolutely opposed to continuing dumb mistakes
>
>made by MySQL. This should be an example of how they should have done
>things in the first place.
>
>I'm starting a new job next week that might allow doing this kind of
>work with some official corporate sponsorship. Because of that I'm going
>to hold off a bit on creating a pg-foundry project (though I suspect
>that's where this will be hosted anyway). In any case, expect to see
>something mid-next week.
>
>
I will be bringing this up to another possibly interested party as well.

Best Wishes,
Chris Travers

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Jeff Davis 2005-07-26 20:56:11 Re: [HACKERS] Enticing interns to PostgreSQL
Previous Message Denis Lussier 2005-07-26 20:52:03 SQL/PSM for 8.2 will offer ANSI/ISO, MySQL, and DB2 Compatibility

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-07-26 20:53:58 Re: VACUUM DATABASE
Previous Message Magnus Hagander 2005-07-26 20:52:14 Re: For review: Server instrumentation patch