Re: [HACKERS] Enticing interns to PostgreSQL - Mailing list pgsql-advocacy

From Chris Travers
Subject Re: [HACKERS] Enticing interns to PostgreSQL
Date
Msg-id 42E6A2E2.4010101@travelamericas.com
Whole thread Raw
In response to Re: [HACKERS] Enticing interns to PostgreSQL  ("Jim C. Nasby" <decibel@decibel.org>)
Responses Re: [HACKERS] Enticing interns to PostgreSQL
List pgsql-advocacy
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

pgsql-advocacy by date:

Previous
From: "Denis Lussier"
Date:
Subject: SQL/PSM for 8.2 will offer ANSI/ISO, MySQL, and DB2 Compatibility
Next
From: Jeff Davis
Date:
Subject: Re: [HACKERS] Enticing interns to PostgreSQL