Datum_to_json
SELECT 'a=>1'::hstore, '1'::xml, '{"a":1}'
(Please note that last column is unknown – datatype)
Now, what is the main goal? to get:
1)
{
"hstore": "\"a\"=>\"1\"",
"xml": "1",
"?column?": "{\"a\":1}"
}
or:
2)
{
"hstore": {
"a": "1"
},
On 09/29/2012 10:29 PM, Andrew Dunstan wrote:
On 09/29/2012 05:01 PM, Hannu Krosing wrote:
On 09/29/2012 05:40 PM, Andrew Dunstan wrote:
I still think Tom's suggestion is the best and simplest way to do that.
which Toms suggestion you mean here ?
The 3. mentioned above was for making possib
Hannu Krosing wrote:
Reflecting over the dual possible interpretation of what it does mean to
convert between "text" and "json" data types it has dawned to me that
the confusion may come mainly from wanting json to be two things at once:
1. - a serialisation of of a subset of javascript object
On 09/29/2012 05:01 PM, Hannu Krosing wrote:
On 09/29/2012 05:40 PM, Andrew Dunstan wrote:
I still think Tom's suggestion is the best and simplest way to do that.
which Toms suggestion you mean here ?
The 3. mentioned above was for making possible 2 separate ways to
convert (serialise/quote
On 09/29/2012 05:40 PM, Andrew Dunstan wrote:
I am not opposed to making a new type, but I really don't think that
means we need to do nothing for the existing data type. The suggested
SERIALIZATION mechanism seems to be fairly intrusive and heavy handed,
as opposed to the very lightweight
On 09/29/2012 11:47 AM, Hannu Krosing wrote:
On 09/26/2012 06:46 PM, Tom Lane wrote:
Andrew Dunstan 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 jso
On 09/26/2012 06:46 PM, Tom Lane wrote:
Andrew Dunstan 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
No probs...
And I did...The thing is, subject is to wide... Post too long... Intention
was just to better explain thoughts... I am not a blogger anyway, just new
in Postgres community... Trying to say, probably 90% of post would be
suficient just for the list, and because of i am new it is hard to
On 09/28/2012 10:34 PM, Misa Simic wrote:
Hi Guys,
I have made some blog about the subject:
http://misasimic.blogspot.co.uk/2012/09/postgresql-92-and-json-datatype.html
Hopefully will help on some kind...
I think if you want to contribute you should post on the mailing list -
otherwise t
Hi Guys,
I have made some blog about the subject:
http://misasimic.blogspot.co.uk/2012/09/postgresql-92-and-json-datatype.html
Hopefully will help on some kind...
Kind Regards,
Misa
On 09/28/2012 08:22 AM, Peter Eisentraut wrote:
(3) Invent an auxiliary type along the lines of "json_value" and say
that you create a cast from foo to json_value when you want one
interpretation, or directly to json if you want the other. Then
things like record_to_json would look for the appr
On 9/27/12 10:36 AM, Tom Lane wrote:
> (1) Reject Robert's assumption that we have to support both
> interpretations for every cast situation. For instance, it doesn't
> seem that unreasonable to me to insist that you have to cast to text
> and then to json if you want the literal-reinterpretation
On 09/28/2012 12:42 AM, Andrew Dunstan wrote:
On 09/27/2012 06:58 PM, Hannu Krosing wrote:
On 09/27/2012 09:18 PM, Andrew Dunstan wrote:
On 09/27/2012 10:36 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2012 09:22 AM, Robert Haas wrote:
Maybe I am being too pedantic about this and th
On 09/27/2012 06:58 PM, Hannu Krosing wrote:
On 09/27/2012 09:18 PM, Andrew Dunstan wrote:
On 09/27/2012 10:36 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2012 09:22 AM, Robert Haas wrote:
Maybe I am being too pedantic about this and there is a way to
make it
all work nicely, but
On 09/27/2012 09:18 PM, Andrew Dunstan wrote:
On 09/27/2012 10:36 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2012 09:22 AM, Robert Haas wrote:
Maybe I am being too pedantic about this and there is a way to make it
all work nicely, but it sure feels like using the casting machinery
h
On 09/27/2012 10:36 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2012 09:22 AM, Robert Haas wrote:
Maybe I am being too pedantic about this and there is a way to make it
all work nicely, but it sure feels like using the casting machinery
here is blending together two different concepts
Hm...
IMO,
'[1,2,3]'::json
'[1,2,3]'::text::json
'[1,2,3]'::int[]::json
are the same thing... (though I am not sure '[1,2,3]'::int[] is valid in
postgres...)
in js var o = JSON.parse(result_of_any_cast_above) should produce array of
3 integer
'[1,2,3]' is different then'"[1,2,3]"'
If there is
On Thu, Sep 27, 2012 at 10:09 AM, Andrew Dunstan wrote:
> So how about this suggestion: we'll look for a visible function named
> "as_json" or some such which has one parameter of the given type and returns
> json, and if it's present use it instead of the standard text
> representation. As an opt
Andrew Dunstan writes:
> On 09/27/2012 09:22 AM, Robert Haas wrote:
>> Maybe I am being too pedantic about this and there is a way to make it
>> all work nicely, but it sure feels like using the casting machinery
>> here is blending together two different concepts that are only
>> sometimes the sa
On 09/27/2012 09:22 AM, Robert Haas wrote:
On Wed, Sep 26, 2012 at 1:46 PM, Tom Lane wrote:
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 see
On Thu, Sep 27, 2012 at 8:22 AM, Robert Haas wrote:
> On Wed, Sep 26, 2012 at 1:46 PM, Tom Lane wrote:
>> 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
On Wed, Sep 26, 2012 at 1:46 PM, Tom Lane wrote:
> 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 ty
On 09/26/2012 06:46 PM, Tom Lane wrote:
Andrew Dunstan 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
On 09/26/2012 01:46 PM, Tom Lane wrote:
Andrew Dunstan 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 typ
Andrew Dunstan 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
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
26 matches
Mail list logo
