Re: [HACKERS] Enticing interns to PostgreSQL

On Tue, Jul 26, 2005 at 01:20:58PM -0700, Chris Travers wrote:
> 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.

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?

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

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.

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

Excellent idea, I'd forgotten about that type. I suspect it would be
perfectly useful as both a tinyint and a tinyuint (if we wanted to add
that as well; I honestly don't know if MySQL has one or not).

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

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.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"