'k, so you want "pure PostgreSQL" ... but, shouldn't it be possible,
with all of our CREATE FUNCTION / RULES / etc features to create a
'translation layer' that could be loaded, like anything else in contrib?
Sure but that isn't what was suggested :)
Hell, even if it gave an initial "in" for MySQL software developers to
get their code running on PostgreSQL, and then when they come out that
"do this is slower under PostgreSQL", they could optimize their code
appropriately?
I understand the idea but I personally don't like it. I am not really
interested in cross-database compatible code. 9 times out of 10 it is
hacky, slow and lacks a solid supportable model because you are always
taking into account *the other* databases the application supports.
And to be frank, I don't think we should waste our time on MySQL. It
isn't a competitor, it just thinks it is. We should focus on our real
competition which is DB2, MSSQL, and Oracle.
If we want to create contrib modules that have types etc... that help
port from Oracle to PostgreSQL or DB2 to PostgreSQL I am all for it.
The first thing that comes to mind is a set of domains that implement
Oracle types (names) as PostgreSQL types.
Here's a start ;)
postgres=# create domain varchar2 AS text;
CREATE DOMAIN
postgres=# create domain clob as text;
CREATE DOMAIN
postgres=# create domain blob as bytea;
CREATE DOMAIN
postgres=# create domain number as integer;
CREATE DOMAIN
postgres=#
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
