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?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
