Skip site navigation (1) Skip section navigation (2)

Re: LinuxTag wrapup

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LinuxTag wrapup
Date: 2004-07-03 17:50:30
Message-ID: 21964.1088877030@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
>> How about an external tool that helps in translating apps to
>> SQL-standard syntax?  Oracle does accept the standard syntax after all.

> Nice idea, but
> - sources might not be accessible
> - sources might not be easily readable (esp. if not embedded sql, 
> example pgadmin) or created dynamically.
> - probably too many non-ansi compliant servers (i.e. pre-9) still in use.

Well, I am certainly *not* buying into a goal of "support any
application that has worked with any version of Oracle with zero source
code changes".  As Dennis already pointed out, the syntax is just the
tip of the iceberg.  (Look for instance at the thread on pgsql-bugs
yesterday, where we concluded that Oracle 8 thinks the way to interpret
"WHERE charcolumn = intconstant" is to cast the column to integer.
Talk about bizarre choices...)

If we bought into such a goal, even partially, we'd stop making forward
progress on our own issues and spend all our time hashing over Oracle
compatibility choices.

The plain fact is that users who want to migrate off Oracle are going
to have to take significant responsibility for porting their own apps,
the more so the more they depended on non-standard constructs.
We can perhaps help them with tools, but if they want a zero-effort
solution they are out of luck.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Jeroen T. VermeulenDate: 2004-07-03 18:10:10
Subject: Re: PREPARE and transactions
Previous:From: Andreas PflugDate: 2004-07-03 17:31:05
Subject: Re: LinuxTag wrapup

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group