Skip site navigation (1) Skip section navigation (2)

Re: data to json enhancements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: data to json enhancements
Date: 2012-09-26 17:46:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Drawing together various discussions both here and elsewhere (e.g. the 
> PostgresOpen hallway track) I propose to work on the following:

> 1. make datum_to_json() honor a type's cast to json if it exists. The 
> fallback is to use the type's string representation, as now.
> 2. add a cast hstore -> json (any others needed for core / contrib types ?)
> 3. add a to_json(anyelement) function
> 4. add a new aggregate function json_agg(anyrecord) -> json to simplify 
> and make more effecient turning a resultset into json.

> Comments welcome.

ISTM the notion of to_json(anyelement) was already heavily discussed and
had spec-compliance issues ... in fact, weren't you one of the people
complaining?  What exactly does #3 mean that is different from the
previous thread?

Also, on reflection I'm not sure about commandeering cast-to-json for
this --- aren't we really casting to "json member" or something like
that?  The distinction between a container and its contents seems
important here.  With a container type as source, it might be important
to do something different if we're coercing it to a complete JSON
value versus something that will be just one member.  I'm handwaving
here because I don't feel like going back to re-read the RFC, but
it seems like something that should be considered carefully before
we lock down an assumption that there can never be a difference.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2012-09-26 18:09:53
Subject: Re: data to json enhancements
Previous:From: Jeff JanesDate: 2012-09-26 17:18:51
Subject: Re: autovacuum stress-testing our system

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group