>> But we have decode(): It is a different decode function, more akin to "case when".
>> Just to give you a fair warning: I'm not going to be in favor of adding any "Oracle compatibility" functionality that overlaps with existing and/or standardized functionality. I wouldn't even dream of it. The last thing I want to do is turn PostgreSQL into an Oracle clone. My aim is to provide a simplified migration path from Oracle and to implement basic compatibility to enable interoperability between the two DBs. Bruce Momjian wrote: > Peter Eisentraut wrote: > >>Marc Lavergne writes: >> >> >>>This covers a few different sub-projects so I'm breaking it down in >>>order of how I'm going to attack it. >> >>Just to give you a fair warning: I'm not going to be in favor of adding >>any "Oracle compatibility" functionality that overlaps with existing >>and/or standardized functionality. That kind of thing would lock us into >>an endless catch-up game and would induce users to code their applications >>to proprietary interfaces. > > > I think some of the Oracle stuff will have to be turned on to be > enabled, others of it can be on by default. > > >>I suppose some of the things you propose would be external applications, >>such as the export file reader or the SQL*Net proxy. The synonym >>functionality would be interesting to add, since there is no existing >>feature of that type. But random misfeatures such as the join syntax or >>the decode() function are going to have a hard time getting accepted. > > > But we have decode(): > > test=> \df decode > List of functions > Result data type | Schema | Name | Argument data types > ------------------+------------+--------+--------------------- > bytea | pg_catalog | decode | text, text > (1 row) > > Is this a different decode? > ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
