OK, clear.
But if you have access to your application code, it's maybe better to
create an abstraction layer in front of the DB specific SQLs, and
implement for each DB differently (this is how we do it).
The "nvl" and "decode" statements are Oracle specific, so I can't see
why not use the Postgres specific syntax for Postgres. A lot of Oracle
queries will work a lot better on postgres if rewritten differently, and
some of them can be even expressed more elegantly in Postgres. AFAIKT,
designing your application so it can use a DB abstraction layer will
give you far less trouble in the long run than trying to make the Oracle
queries work unchanged on Postgres...
Cheers,
Csaba.
On Wed, 2003-08-27 at 10:55, Christian Traber wrote:
I know this functions, but I do not want to change the statements in my
old application.
So I want to make the functions with the Oracle names for compatibility.
Best regards,
Christian
Csaba Nagy wrote:
You don't need to build any function for this, you have them ready:
http://www.postgresql.org/docs/view....l.html#AEN9753
http://www.postgresql.org/docs/view....l.html#AEN9698
Cheers,
Csaba.
On Wed, 2003-08-27 at 09:58, Christian Traber wrote:
Hi,
I'll try to switch from Oracle to postgres for some small applications.
Is it possible to build functions like Oracle's nvl or decode with pgplsql?
How can I make a function like nvl that works for every datatype?
Best regards,
Christian
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
