4 ms·

Could you name some I’m pretty curious? For my use case it’s a no brainer because only PostgreSQL have a decent GIS extension, last time I checked Oracle was l

Could you name some I’m pretty curious? For my use case it’s a no brainer because only PostgreSQL have a decent GIS extension, last time I checked Oracle was lagging well behind.

pjmlp 7y ago
- Distributed transactions across cluster nodes - The IDE experience with PL/SQL, including graphical debugging of stored procedures - Compiling PL/SQL to native code for better performance - Running bare metal without an underlying OS - Oracle RAC - The fine tuning options on their JDBC and .NET drivers - A proper C++ driver API
- sverhagen 7y ago
  I don't have the stats to back this up, bit that all seems very niche. I have to imagine you get downvoted because people don't recognize these as real requirements. I needed not a single one of these. Ever.
  - jsty 7y ago
    Compiling SQL -> native I'm not sure deserves to be described as niche, since lots of analytical queries can benefit from that. Worth pointing out that Postgres has a JIT compiler [0]. [0] https://www.postgresql.org/docs/current/jit.html https://www.postgresql.org/docs/current/jit.html
  - jacques_chester 7y ago
    > I needed not a single one of these. Ever. Enterprise software tends to have lots of features that the majority of folks will never encounter in their career. The enterprise market space is composed of around a thousand potential customers world wide, all of whom are large enough to have sophisticated and complex internal computing environments. They have varying norms, requirements, workloads, regulatory environments, industry standards and so on and so forth. Each has a lot of money and rejecting the requirements of one company often means you are effectively rejecting several, or perhaps even an entire sector. So you add something to cover them and before long, your software has the union set of features required solely by enormous companies. From a non-enterprise view a particular feature may seem like absurd overkill. But someone, somewhere, needs it and there is a long and often impressive story of how it was achieved.
- sixbrx 7y ago
  As an "enterprise" Oracle user, I'd give all those up in a heartbeat if Oracle would just support proper indexing on Json values (well CLOBS with a "is json" constraint in Oracle - bleh). Meaning that I wouldn't have to execute ddl to create a function index on each new field path within the json that I want to support. IOW I want a Postgres path ops GIN index which work beautifully.
kccqzy 7y ago
Like automatically refreshing materialized views, by which I mean when a base table is changed, the engine uses the definition of the materialized view to run triggers to update materialized view.
- Twisell 7y ago
  This is related to default implementation details, this behavior can be achieved using trigger/materialized view on PostgreSQL as well.
  - kccqzy 7y ago
    My entire point is that I shouldn't have to write the triggers myself. PostgreSQL figures out the triggers from my definition of the materialized view.

Could you name some I’m pretty curious? For my use case it’s a no brainer because only PostgreSQL have a decent GIS extension, last time I checked Oracle was lagging well behind.

pjmlp 7y ago

- Distributed transactions across cluster nodes - The IDE experience with PL/SQL, including graphical debugging of stored procedures - Compiling PL/SQL to native code for better performance - Running bare metal without an underlying OS - Oracle RAC - The fine tuning options on their JDBC and .NET drivers - A proper C++ driver API

sverhagen 7y ago
I don't have the stats to back this up, bit that all seems very niche. I have to imagine you get downvoted because people don't recognize these as real requirements. I needed not a single one of these. Ever.
- jsty 7y ago
  Compiling SQL -> native I'm not sure deserves to be described as niche, since lots of analytical queries can benefit from that. Worth pointing out that Postgres has a JIT compiler [0]. [0] https://www.postgresql.org/docs/current/jit.html https://www.postgresql.org/docs/current/jit.html
- jacques_chester 7y ago
  > I needed not a single one of these. Ever. Enterprise software tends to have lots of features that the majority of folks will never encounter in their career. The enterprise market space is composed of around a thousand potential customers world wide, all of whom are large enough to have sophisticated and complex internal computing environments. They have varying norms, requirements, workloads, regulatory environments, industry standards and so on and so forth. Each has a lot of money and rejecting the requirements of one company often means you are effectively rejecting several, or perhaps even an entire sector. So you add something to cover them and before long, your software has the union set of features required solely by enormous companies. From a non-enterprise view a particular feature may seem like absurd overkill. But someone, somewhere, needs it and there is a long and often impressive story of how it was achieved.
sixbrx 7y ago
As an "enterprise" Oracle user, I'd give all those up in a heartbeat if Oracle would just support proper indexing on Json values (well CLOBS with a "is json" constraint in Oracle - bleh). Meaning that I wouldn't have to execute ddl to create a function index on each new field path within the json that I want to support. IOW I want a Postgres path ops GIN index which work beautifully.

kccqzy 7y ago

Like automatically refreshing materialized views, by which I mean when a base table is changed, the engine uses the definition of the materialized view to run triggers to update materialized view.

Twisell 7y ago
This is related to default implementation details, this behavior can be achieved using trigger/materialized view on PostgreSQL as well.
- kccqzy 7y ago
  My entire point is that I shouldn't have to write the triggers myself. PostgreSQL figures out the triggers from my definition of the materialized view.