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
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 |
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 |