Re: [HACKERS] Enticing interns to PostgreSQL
От | Chris Travers |
---|---|
Тема | Re: [HACKERS] Enticing interns to PostgreSQL |
Дата | |
Msg-id | 42E6A2E2.4010101@travelamericas.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Enticing interns to PostgreSQL ("Jim C. Nasby" <decibel@decibel.org>) |
Ответы |
Re: [HACKERS] Enticing interns to PostgreSQL
|
Список | 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 по дате отправления: