Re: [HACKERS] Enticing interns to PostgreSQL

Jim C. Nasby wrote:

> So, how can we increase awareness amongst people who have yet to choose
>
>an OSS database? Awareness that PostgreSQL exists, and awareness that
>it's almost always a superior choice than MySQL.
>
>
>
We help migrate apps to PostgreSQL. We help other people run
PostgreSQL. We show them the features that they really cannot live
without, such as schemas, views, etc.

We also show them the power of extensible types and extensible UDF
languages.

>This is something that's been discussed on IRC, and got a favorable
>response. In terms of compatability, I'd be happy with something that
>just emulated MySQL. I think it would actually be good to allow for
>both, since there are some limited cases where it doesn't make sense to
>use an integer pointer to an external table.
>
>
I would rather do things so that it covered 90% of all cases and did so
*right* than something that covered 100% of cases and did so by breaking
basic principles of database design. The enum_ table idea would work
well for all major uses that I can think of, and it would easily allow
new options to be added as necessary.

The problem with enums is that although they are handy they are never
elegant re: database design. Addign enum tables is the only way yo
maintain sanity in this eent that I can think of.

>
>
>>Also, why not simply allow tinyint to be the same as int(2)?
>>
>>
>
>Again, for simple compatability that would be fine. If alignment/padding
>issues could be dealt with, it would also be handy to have a true
>tinyint.
>
>
>
Ok. Bruce pointed out that there is a datatype "char" (with the quotes)
that is basically a single byte of info. We could maybe have tinyint
use that? Or for that, how hard would it be to write a simple datatype
(Occam's Razor-- One Should Not Needlessly Multiply Entities-- would
lead us to think that this is a bad idea when existing datatypes meet
this need)? That should be rediculously easy for a single byte of
information presented as an int.

>Would you be interested in supporting a pg-foundry project that worked
>on increasing mysql compatabality?
>
>
I would be interested in one that worked on decreasing migration costs.
I am thinking less in terms of compatibility, but more in terms of
helping shim an existing MySQL-based app so that it works on PostgreSQL,
and helping shim PostgreSQL so that it can accept input as expected from
MySQL.

100% compatibility would mean though that we would have to do things I
would never advocate, such as emulating MySQL's braindead error handling.

Best Wishes,
Chris Travers