Re: [HACKERS] SQL/JSON in PostgreSQL - Mailing list pgsql-hackers

From Peter van Hardenberg
Subject Re: [HACKERS] SQL/JSON in PostgreSQL
Date
Msg-id CABTbUpjRWAaJbt03vi8DBGCwBbVgpU278VNFi3=gmCsvrgob4w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] SQL/JSON in PostgreSQL  ("Sven R. Kunze" <srkunze@mail.de>)
Responses Re: [HACKERS] SQL/JSON in PostgreSQL  ("Sven R. Kunze" <srkunze@mail.de>)
Re: [HACKERS] SQL/JSON in PostgreSQL  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
Anecdotally, we just stored dates as strings and used a convention (key ends in "_at", I believe) to interpret them. The lack of support for dates in JSON is well-known, universally decried... and not a problem the PostgreSQL community can fix.

On Thu, Mar 9, 2017 at 10:24 AM, Sven R. Kunze <srkunze@mail.de> wrote:
On 09.03.2017 18:58, Robert Haas wrote:
Also, even if the superset thing were true on a theoretical plane, I'm
not sure it would do us much good in practice.  If we start using
YAML-specific constructs, we won't have valid JSON any more.  If we
use only things that are legal in JSON, YAML's irrelevant.

That's true. I just wanted to share my view of the "date guessing" part of pgpro's commits.
I don't have a good solution for it either, I can only tell that where I work we do have same issues: either we guess by looking at the string value or we know that "this particular key" must be a date.
Unsatisfied with either solution, we tend to use YAML for our APIs if possible.


Regards,
Sven


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



--
Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt."—Kurt Vonnegut

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] New CORRESPONDING clause design
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Couple of issues with prepared FETCH commands