On 04/09/14 18:02, Craig Ringer wrote:
> On 09/04/2014 06:48 AM, Joshua D. Drake wrote:
>> On 09/03/2014 11:48 AM, Robert Haas wrote:
>>
>>> Anyway, to get back around to the topic of PL/SQL compatibility
>>> specifically, if you care about that issue, pick one thing that exists
>>> in PL/SQL but not in PL/pgsql and try to do something about it. Maybe
>>> it'll be something that EnterpiseDB has already done something about,
>>> in which case, if your patch gets committed, Advanced Server will lose
>>> a bit of distinction as compared with PostgreSQL. Or maybe it'll be
>>> something that EnterpriseDB hasn't done anything about, and then
>>> everybody comes out strictly ahead. What I think you shouldn't do
>>> (although you're free to ignore me) is continue thinking of Oracle
>>> compatibility as one monolithic thing, because it isn't, or to pursue
>>> of a course of trying to get the PostgreSQL community to slavishly
>>> follow Oracle, because I think you'll fail, and even if you succeed I
>>> don't think the results will actually be positive for PostgreSQL.
>> Well put Robert.
> Indeed, especially with reference to the size and scope of Oracle. Its
> XML library alone is huge.
>
> At best it's reasonable to hope for compatibility with a limited subset
> of PL/SQL - and really, we're a good way there already, with most of
> what's missing being down to missing core server features or things
> PostgreSQL just does differently.
>
> True "Oracle compatibility" (for procedures) pretty much requires an
> embedded JVM with a rich class library. Since PL/Java seems to be dying
> a slow death by neglect and disinterest I don't think it's likely anyone
> would be tackling compatibility with the embedded JVM features anytime soon.
>
> There are a few things I would like to see, like secure session
> variables in PL/PgSQL. Mostly, though, I think talk of "Oracle
> compatibility" seems to be something that comes up before the speaker
> has really understood what that would mean, and the sheer scope of the
> endeavour.
>
> It's not going from 50% compatible to 80% compatible, it's going from 5%
> compatible to 7% compatible. The most used 5% maybe, but still...
>
Getting that 5% of what is most used, would be a great gain. Maybe
the speaker is mislead in the size of the endeavour, but quite sure
about what that market needs are ;)
Cheers,
Álvaro