3 ms·

Agreed. How about something like: "Here is a financial transaction. Please make sure it is balanced and post it." This is not trivial to do right now. Top-

Agreed. How about something like: "Here is a financial transaction. Please make sure it is balanced and post it." This is not trivial to do right now. Top-notch JSON support would make it a breeze.

jeltz 13y ago
Just having a JSON type should fix this without the need for a JSON based protocol. Actually the current JSON support in 9.3 should be enough for this. Just call a stored procedure with the JSON object describing the transactions.
- einhverfr 13y ago
  It's reasonably easy to wrap the SQL involved in calling stored procedures.[1] The JSON in 9.3 is almost good enough for this. It doesn't handle nested data structures to sql nested complex types properly, and so it won't quite get you there but otherwise agreed. I.e. to make it work currently you have to slice and dice the JSON in some fun ways first. I find it less painful to just handle the complex type serialization/deserialization on the client side. [1] See https://github.com/einhverfr/PGObject-Simple-Role https://github.com/einhverfr/PGObject-Simple-Role
  - dorfsmay 13y ago
    Yes, it is easy, but people using Mongo, CouchDB etc... will argue that not having to do it at all is better, and will use that argument to justify their choice. Same idea as ORMs... Making any CRUD operation is easy in SQL, why did we need ORMs? Yet, there is a fragment of the population who wouldn't use a database they couldn't talk to through an ORM. Today, there is a segment of programers that won't use a database if they can't PUT({"name": "Big Bird", "address": "123 Sesame street"}), because, you know, that's the modern way to do things.
    - einhverfr 13y ago
      It loses the power of SQL which may also seem to be the modern way to do things ;-)
      - dorfsmay 13y ago
        No. Adding support for a json NoSQL like interface doesn't remove the SQL access. You could let the front end guys do Create Update Retrieve by primary key using the json interface, while the backend analysis guys use SQL through the normal SQL driver.
        einhverfr 13y ago
        I think you misunderstood my point. The "modern" way seems to be to avoid SQL using either NoSQL or something like an ORM. Personally I prefer to tackle this from the other side with stored procedures and service locators so my application code is free of SQL (aside from the service locator), and all my SQL is in .sql files.....
rdtsc 13y ago
> This is not trivial to do right now. Top-notch JSON support would make it a breeze What does it matter if it is JSON or not. In financial transactions you want: * Maximum fault tolerance * Auditability * Security * Performance * Ability to roll it back with all the cleanly defined states in between * Ability to talk to legacy / standard systems JSON-ifying the contents of the transaction is nice. But I wouldn't think that is the main pain point in the industry at the moment. It is really the behavior of the systems outside the transaction contents itself that matters.
- einhverfr 13y ago
  > What does it matter if it is JSON or not. It makes it easier to pass the complex data regarding a financial transaction into a stored procedure all at once. That's the non-trivial part today.

Agreed. How about something like: "Here is a financial transaction. Please make sure it is balanced and post it." This is not trivial to do right now. Top-notch JSON support would make it a breeze.

jeltz 13y ago

Just having a JSON type should fix this without the need for a JSON based protocol. Actually the current JSON support in 9.3 should be enough for this. Just call a stored procedure with the JSON object describing the transactions.

einhverfr 13y ago
It's reasonably easy to wrap the SQL involved in calling stored procedures.[1] The JSON in 9.3 is almost good enough for this. It doesn't handle nested data structures to sql nested complex types properly, and so it won't quite get you there but otherwise agreed. I.e. to make it work currently you have to slice and dice the JSON in some fun ways first. I find it less painful to just handle the complex type serialization/deserialization on the client side. [1] See https://github.com/einhverfr/PGObject-Simple-Role https://github.com/einhverfr/PGObject-Simple-Role
- dorfsmay 13y ago
  Yes, it is easy, but people using Mongo, CouchDB etc... will argue that not having to do it at all is better, and will use that argument to justify their choice. Same idea as ORMs... Making any CRUD operation is easy in SQL, why did we need ORMs? Yet, there is a fragment of the population who wouldn't use a database they couldn't talk to through an ORM. Today, there is a segment of programers that won't use a database if they can't PUT({"name": "Big Bird", "address": "123 Sesame street"}), because, you know, that's the modern way to do things.
  - einhverfr 13y ago
    It loses the power of SQL which may also seem to be the modern way to do things ;-)
    - dorfsmay 13y ago
      No. Adding support for a json NoSQL like interface doesn't remove the SQL access. You could let the front end guys do Create Update Retrieve by primary key using the json interface, while the backend analysis guys use SQL through the normal SQL driver.
      - einhverfr 13y ago
        I think you misunderstood my point. The "modern" way seems to be to avoid SQL using either NoSQL or something like an ORM. Personally I prefer to tackle this from the other side with stored procedures and service locators so my application code is free of SQL (aside from the service locator), and all my SQL is in .sql files.....

rdtsc 13y ago

> This is not trivial to do right now. Top-notch JSON support would make it a breeze What does it matter if it is JSON or not. In financial transactions you want: * Maximum fault tolerance * Auditability * Security * Performance * Ability to roll it back with all the cleanly defined states in between * Ability to talk to legacy / standard systems JSON-ifying the contents of the transaction is nice. But I wouldn't think that is the main pain point in the industry at the moment. It is really the behavior of the systems outside the transaction contents itself that matters.

einhverfr 13y ago
> What does it matter if it is JSON or not. It makes it easier to pass the complex data regarding a financial transaction into a stored procedure all at once. That's the non-trivial part today.