>> 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?
>
