3 ms·

Erm... JSON is pure text - so not much of an innovation in truth - I can store it in SQLight right now.

by bdfh42 15y ago

TylerE 15y ago
I think you're missing the point. With this feature you'll be able to write a query that returns a JSON string of the results, possible as a field in a larger result set. It also validates that the JSON parses on the way in.
- bdfh42 15y ago
  Thanks for the help - so it is a "result type" (not so much core) - OK that will save a few lines of code - unless I have to write as many lines to handle result sets that do not parse... I suspect I am not a big fan of abstractions.
  - julian37 15y ago
    I'm with you, this smells of feature creep. I don't see a big benefit over serializing the result set on the client. This is literally a one-liner if you're using an ORM or something like PEP 249. The new constraint allowing you to ensure the string stored is valid JSON sounds useful though.
    - jeffdavis 15y ago
      > I'm with you, this smells of feature creep. There are good reasons to have JSON support in the DBMS, such as querying and indexing on the fields within a JSON document. My only criticism is that postgres has a great extensions mechanism, and it would be better if effort were spent improving the ecosystem around that. I can't think of any reason for it to be in core if installing an extension were a trivial and widely accepted practice. But, it takes time to really develop that ecosystem. And there are users that want JSON support yesterday. EDIT: from a technological standpoint, there is no reason why it can't exist as an extension. PostGIS is much more sophisticated on all counts, and it's an extension.
      - fdr 15y ago
        I agree with you insomuch as it's ideal for an extension, and argued for its inclusion as a 9.3 feature (looks like Christmas might come early, though). However, I concluded with this: Right now the perception of Postgres...actually, databases in general, including virtually all of the newcomers -- is that they are monolithic systems, and for most people either "9.3" will "have" javascript and indexing of JSON documents, or it won't. In most cases I would say "meh, let them eat cake until extensions become so apparently dominant that we can wave someone aside to extension-land", but in this case I think that would be a strategic mistake. http://archives.postgresql.org/pgsql-hackers/2011-12/msg00782.php http://archives.postgresql.org/pgsql-hackers/2011-12/msg0078... So this is definitely a social problem. Why not move UUID out of the core? (not uuid-ossp, which implements generation, but uuid parsing and storage) Because, for now, one cannot assume extensions for really common useful functionality. Luckily, I think things are on the right path to at a future juncture that even a commonly desired data type can live as an extension.
jacques_chester 15y ago
OT nitpick: SQLite.
- tzury 15y ago
  I was staring at that comment for few seconds trying to figure out what is wrong with what I see. SQLight. Nice pick.

Erm... JSON is pure text - so not much of an innovation in truth - I can store it in SQLight right now.

by bdfh42 15y ago

Erm... JSON is pure text - so not much of an innovation in truth - I can store it in SQLight right now.

I think you're missing the point. With this feature you'll be able to write a query that returns a JSON string of the results, possible as a field in a larger result set. It also validates that the JSON parses on the way in.

bdfh42 15y ago
Thanks for the help - so it is a "result type" (not so much core) - OK that will save a few lines of code - unless I have to write as many lines to handle result sets that do not parse... I suspect I am not a big fan of abstractions.
- julian37 15y ago
  I'm with you, this smells of feature creep. I don't see a big benefit over serializing the result set on the client. This is literally a one-liner if you're using an ORM or something like PEP 249. The new constraint allowing you to ensure the string stored is valid JSON sounds useful though.
  - jeffdavis 15y ago
    > I'm with you, this smells of feature creep. There are good reasons to have JSON support in the DBMS, such as querying and indexing on the fields within a JSON document. My only criticism is that postgres has a great extensions mechanism, and it would be better if effort were spent improving the ecosystem around that. I can't think of any reason for it to be in core if installing an extension were a trivial and widely accepted practice. But, it takes time to really develop that ecosystem. And there are users that want JSON support yesterday. EDIT: from a technological standpoint, there is no reason why it can't exist as an extension. PostGIS is much more sophisticated on all counts, and it's an extension.
    - fdr 15y ago
      I agree with you insomuch as it's ideal for an extension, and argued for its inclusion as a 9.3 feature (looks like Christmas might come early, though). However, I concluded with this: Right now the perception of Postgres...actually, databases in general, including virtually all of the newcomers -- is that they are monolithic systems, and for most people either "9.3" will "have" javascript and indexing of JSON documents, or it won't. In most cases I would say "meh, let them eat cake until extensions become so apparently dominant that we can wave someone aside to extension-land", but in this case I think that would be a strategic mistake. http://archives.postgresql.org/pgsql-hackers/2011-12/msg00782.php http://archives.postgresql.org/pgsql-hackers/2011-12/msg0078... So this is definitely a social problem. Why not move UUID out of the core? (not uuid-ossp, which implements generation, but uuid parsing and storage) Because, for now, one cannot assume extensions for really common useful functionality. Luckily, I think things are on the right path to at a future juncture that even a commonly desired data type can live as an extension.

jacques_chester 15y ago

OT nitpick: SQLite.

tzury 15y ago
I was staring at that comment for few seconds trying to figure out what is wrong with what I see. SQLight. Nice pick.