JSON Function Bike Shedding
Hello Hackers,
If you dislike bike-shedding (and who does?), delete this email and the ensuing thread right now. You have been warned!
I have been playing with Andrew’s JSON enhancements and really enjoying them. I am already using them in code I’m developing for production deployment in a month or two. Kudos!
However, I am not so keen on the function names. They all start with json_! This mostly feels redundant to me, since the types of the parameters are part of the function signature.
Therefore, I would like to propose different names:
Existing Name Proposed Name
-------------------------- ----------------------------------------
json_array_length() array_length() or length() or size()
json_each() each_json()
json_each_as_text() each_text()
json_get() get_json()
json_get_as_text() get_text()
json_get_path() get_json()
json_get_path_as_text() get_text()
json_object_keys() get_keys()
json_populate_record() record() or row()
json_populate_recordset() records() or rows()
json_unnest() get_values()
json_agg() collect_json()
Note that I have given json_get() and json_get_path() the same names, as it seems to me that the former is the same as the latter, with only one parameter. Same for json_get_as_text() and json_get_path_as_text().
One nice thing about get_values() as opposed to json_unnest(), is that it could be used to fetch the values from a JSON object as well as an array. (BTW, I think unnest is not a good name at all, since unlike the SQL unnest() function, it doesn't actually unnest (flatten) the entire array).
As for the operators, as previously discussed, I'm happy with either -> or ~> (and ->> or ~>>, of course). But I'm wondering if the same operator couldn't be used when an array is on the RHS. I mean, having #> to that it doesn't have to be cast is nice, too, but I think it'd be nice if an array would work with -> and ->>, too.
AS for #> and #>>, what about @> and @>> instead? Or am I just too much the Perl hacker for thinking that @ is a nice mnemonic for "array"?
And finally, a couple of feature requests, which can be taken with a shaker of salt -- or as ideas for 9.4 -- and are mostly stolen from hstore:
* An exists() function (and ? operator) similar to hstore
* A defined() function
* A delete() function
* A slice() function
* A concatenation function and operator
* union, intercept, and except operators and/or functions
* Perhaps some set-returning functions (select_keys(), select_values())
Even if nothing changes before release, I'm happy with the functionality Andrew has added. As I said, this is pure bike shedding, but I believe naming things is important, so it's a discussion worth having.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David,
However, I am not so keen on the function names. They all start with
json_! This mostly feels redundant to me, since the types of the
parameters are part of the function signature.
I have no opinion about starting the function names with json_ or not.
If we decide not, I agree that in general your proposed names are
reasonable. Except:
json_populate_record()
record() or row()
json_populate_recordset() records() or
rows()
Given that row() is already a type-agnostic function, and RECORD is a
stored procedure return meta-type, I think the above names would be a
mistake. I'd suggest instead:
json_to_record() and json_to_recordset()
or:
to_record(json) and to_recordset(json)
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb 12, 2013, at 2:01 PM, Josh Berkus <josh@agliodbs.com> wrote:
Given that row() is already a type-agnostic function, and RECORD is a
stored procedure return meta-type, I think the above names would be a
mistake. I'd suggest instead:json_to_record() and json_to_recordset()
or:to_record(json) and to_recordset(json)
I like these last two a lot, actually. Thanks!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
David,
However, I am not so keen on the function names. They all start with
json_! This mostly feels redundant to me, since the types of the
parameters are part of the function signature.
I have no opinion about starting the function names with json_ or not.
+1 for removing that where possible. We generally have avoided such
names at SQL level. (The C-level function names need such prefixes to
be unique, but the SQL names don't.)
In the cases where one or more arguments are anyelement, however, we may
need to be more specific to avoid ambiguity problems in future. I agree
with Josh's objections to record(), row() etc. to_record() and
to_recordset() might be OK.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Feb 12, 2013 at 6:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Josh Berkus <josh@agliodbs.com> writes:
David,
However, I am not so keen on the function names. They all start with
json_! This mostly feels redundant to me, since the types of the
parameters are part of the function signature.I have no opinion about starting the function names with json_ or not.
+1 for removing that where possible. We generally have avoided such
names at SQL level. (The C-level function names need such prefixes to
be unique, but the SQL names don't.)In the cases where one or more arguments are anyelement, however, we may
need to be more specific to avoid ambiguity problems in future. I agree
with Josh's objections to record(), row() etc. to_record() and
to_recordset() might be OK.
!
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb 12, 2013, at 8:00 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
+1 for removing that where possible. We generally have avoided such
names at SQL level. (The C-level function names need such prefixes to
be unique, but the SQL names don't.)In the cases where one or more arguments are anyelement, however, we may
need to be more specific to avoid ambiguity problems in future. I agree
with Josh's objections to record(), row() etc. to_record() and
to_recordset() might be OK.
Agreed on all counts. (Wow!)
!
Not sure this would make a useful operator. Maybe for exists()? :-O
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Feb 12, 2013 at 1:18 PM, David E. Wheeler <david@justatheory.com> wrote:
couple other suggestions:
Existing Name Proposed Name
-------------------------- ----------------------------------------
json_array_length() array_length() or length() or size()
very much prefer without 'array_' prefix as this leads to semantic
confusion with our (generally badly named) array manipulation API.
So, length() -- also I see no reason why this can't be made to run if
the outermost container is an object but that's an acceptable
implementation detail.
json_each() each_json()
why not each(). Assumption to return json is reasonable and doesn't
need decoration IMO.
json_each_as_text() each_text()
like this
json_get() get_json()
prefer get()
json_get_as_text() get_text()
like this
json_get_path() get_json()
get() please
json_get_path_as_text() get_text()
like this
json_object_keys() get_keys()
like this
json_populate_record() record() or row()
to_record()
json_populate_recordset() records() or rows()
to_recordset()
json_unnest() get_values()
greatly prefer unwrap()
json_agg() collect_json()
perfer to leave as json_agg() -- we have string_agg, array_agg, etc.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/12/2013 02:18 PM, David E. Wheeler wrote:
Hello Hackers,
If you dislike bike-shedding (and who does?), delete this email and the ensuing thread right now. You have been warned!
I have been playing with Andrew’s JSON enhancements and really enjoying them. I am already using them in code I’m developing for production deployment in a month or two. Kudos!
However, I am not so keen on the function names. They all start with json_! This mostly feels redundant to me, since the types of the parameters are part of the function signature.
I don't have any problem getting rid of the json_ prefixes, except for
json_agg which I think should keep it (c.f. string_agg, array_agg).
Therefore, I would like to propose different names:
Existing Name Proposed Name
-------------------------- ----------------------------------------
json_array_length() array_length() or length() or size()
json_each() each_json()
json_each_as_text() each_text()
json_get() get_json()
json_get_as_text() get_text()
json_get_path() get_json()
json_get_path_as_text() get_text()
json_object_keys() get_keys()
json_populate_record() record() or row()
json_populate_recordset() records() or rows()
json_unnest() get_values()
json_agg() collect_json()Note that I have given json_get() and json_get_path() the same names, as it seems to me that the former is the same as the latter, with only one parameter. Same for json_get_as_text() and json_get_path_as_text().
I will take some of this under advisement. Note that
json_populate_record's name was taken from hstore's populate_record, so
if we're trying to use similar names then it should possibly be just
populate_record. Or if that's still a bit long I would accept to_record.
One nice thing about get_values() as opposed to json_unnest(), is that it could be used to fetch the values from a JSON object as well as an array. (BTW, I think unnest is not a good name at all, since unlike the SQL unnest() function, it doesn't actually unnest (flatten) the entire array).
I think Merlin's suggestion if unwrap might be good. Or simply
"elements()" might work.
As for the operators, as previously discussed, I'm happy with either -> or ~> (and ->> or ~>>, of course). But I'm wondering if the same operator couldn't be used when an array is on the RHS. I mean, having #> to that it doesn't have to be cast is nice, too, but I think it'd be nice if an array would work with -> and ->>, too.
The point of using different operator names is that if there's an array
literal postgres will convert it to an array. If the operator names are
the same it will treat it as a text key instead. Being able to type
my_json #>> '{f1,0,f2,3,f3}'
is nice. Of course, we could duplicate the operators, but I generally
prefer not to do that.
AS for #> and #>>, what about @> and @>> instead? Or am I just too much the Perl hacker for thinking that @ is a nice mnemonic for "array"?
Probably. I deliberately avoided @> because it's used elsewhere to mean
"contains" and using it for something quite different here might be
confusing.
And finally, a couple of feature requests, which can be taken with a shaker of salt -- or as ideas for 9.4 -- and are mostly stolen from hstore:
* An exists() function (and ? operator) similar to hstore
* A defined() function
* A delete() function
* A slice() function
* A concatenation function and operator
* union, intercept, and except operators and/or functions
* Perhaps some set-returning functions (select_keys(), select_values())
I think this is beyond bikeshedding. Apparently you have missed the
existence of json_object_keys().
The new API makes many or all of these things possible to do with
relative ease as extensions (See my possibly upcoming talk on the subject.)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
I will take some of this under advisement. Note that
json_populate_record's name was taken from hstore's populate_record, so
if we're trying to use similar names then it should possibly be just
populate_record. Or if that's still a bit long I would accept to_record.
+1 for following precedent whenever there is some --- so let's go with
populate_record.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
I don't have any problem getting rid of the json_ prefixes, except for json_agg which I think should keep it (c.f. string_agg, array_agg).
I think that's an unfortunately naming forced on us by the SQL standard, and it doesn't mean we have to use it anyway.
I will take some of this under advisement. Note that json_populate_record's name was taken from hstore's populate_record, so if we're trying to use similar names then it should possibly be just populate_record. Or if that's still a bit long I would accept to_record.
to_record()++
I think Merlin's suggestion if unwrap might be good. Or simply "elements()" might work.
Perhaps unwrap() returns a set and elements() returns an array?
AS for #> and #>>, what about @> and @>> instead? Or am I just too much the Perl hacker for thinking that @ is a nice mnemonic for "array"?
Probably. I deliberately avoided @> because it's used elsewhere to mean "contains" and using it for something quite different here might be confusing.
I can see that, especially if you end up adding exists(): @> could be its operator.
I think this is beyond bikeshedding. Apparently you have missed the existence of json_object_keys().
Oh, I forgot it returned a set rather than an array. So I suggest:
values() - Returns an array
keys() - Returns an array
And:
unwrap() - Returns a set
skeys() - Returns a set
Er, okay, so skeys() sucks alongside the others here. If we were to steal from hstore, these would be:
svals() - Returns a set
skeys() - Returns a set
avals() - Returns an array
akeys() - Returns an array
I don’t love those, but if we want to follow precedent…
The new API makes many or all of these things possible to do with relative ease as extensions (See my possibly upcoming talk on the subject.)
I’ll be there, yo!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2013/2/13 David E. Wheeler <david@justatheory.com>:
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
I don't have any problem getting rid of the json_ prefixes, except for json_agg which I think should keep it (c.f. string_agg, array_agg).
I think that's an unfortunately naming forced on us by the SQL standard, and it doesn't mean we have to use it anyway.
I will take some of this under advisement. Note that json_populate_record's name was taken from hstore's populate_record, so if we're trying to use similar names then it should possibly be just populate_record. Or if that's still a bit long I would accept to_record.
to_record()++
I think Merlin's suggestion if unwrap might be good. Or simply "elements()" might work.
Perhaps unwrap() returns a set and elements() returns an array?
AS for #> and #>>, what about @> and @>> instead? Or am I just too much the Perl hacker for thinking that @ is a nice mnemonic for "array"?
Probably. I deliberately avoided @> because it's used elsewhere to mean "contains" and using it for something quite different here might be confusing.
I can see that, especially if you end up adding exists(): @> could be its operator.
I think this is beyond bikeshedding. Apparently you have missed the existence of json_object_keys().
Oh, I forgot it returned a set rather than an array. So I suggest:
values() - Returns an array
keys() - Returns an array
"values" is keyword and "keys" is relative high risk too
Regards
Pavel
And:
unwrap() - Returns a set
skeys() - Returns a setEr, okay, so skeys() sucks alongside the others here. If we were to steal from hstore, these would be:
svals() - Returns a set
skeys() - Returns a set
avals() - Returns an array
akeys() - Returns an arrayI don’t love those, but if we want to follow precedent…
The new API makes many or all of these things possible to do with relative ease as extensions (See my possibly upcoming talk on the subject.)
I’ll be there, yo!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/13/2013 12:07 PM, David E. Wheeler wrote:
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
I don't have any problem getting rid of the json_ prefixes, except for json_agg which I think should keep it (c.f. string_agg, array_agg).
I think that's an unfortunately naming forced on us by the SQL standard, and it doesn't mean we have to use it anyway.
Regardless of that, I'd prefer to be consistent.
I think Merlin's suggestion if unwrap might be good. Or simply "elements()" might work.
Perhaps unwrap() returns a set and elements() returns an array?
Now you're adding functionality. Let's just keep this to the question of
names.
I think this is beyond bikeshedding. Apparently you have missed the existence of json_object_keys().
Oh, I forgot it returned a set rather than an array. So I suggest:
values() - Returns an array
keys() - Returns an arrayAnd:
unwrap() - Returns a set
skeys() - Returns a setEr, okay, so skeys() sucks alongside the others here. If we were to steal from hstore, these would be:
svals() - Returns a set
skeys() - Returns a set
avals() - Returns an array
akeys() - Returns an arrayI don’t love those, but if we want to follow precedent…
Ditto. I think we're a bit late to be adding functionality.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb 13, 2013, at 9:31 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
I don’t love those, but if we want to follow precedent…
Ditto. I think we're a bit late to be adding functionality.
Well, how about having just keys() and vals() return arrays? Then one can just wrap them in unnest() to get sets.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan wrote:
On 02/13/2013 12:07 PM, David E. Wheeler wrote:
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
I think Merlin's suggestion if unwrap might be good. Or simply "elements()" might work.
Perhaps unwrap() returns a set and elements() returns an array?
Now you're adding functionality. Let's just keep this to the
question of names.
I agree with that, but it seems a good idea to leave names available for
future functionality, where reasonable.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Feb 13, 2013 at 11:40 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
Andrew Dunstan wrote:
On 02/13/2013 12:07 PM, David E. Wheeler wrote:
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
I think Merlin's suggestion if unwrap might be good. Or simply "elements()" might work.
Perhaps unwrap() returns a set and elements() returns an array?
Now you're adding functionality. Let's just keep this to the
question of names.I agree with that, but it seems a good idea to leave names available for
future functionality, where reasonable.
Given all that, is there consensus on the names so that Andrew knows
what changes to make?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Feb 12, 2013 at 2:18 PM, David E. Wheeler <david@justatheory.com> wrote:
Hello Hackers,
If you dislike bike-shedding (and who does?), delete this email and the ensuing thread right now. You have been warned!
I have been playing with Andrew’s JSON enhancements and really enjoying them. I am already using them in code I’m developing for production deployment in a month or two. Kudos!
However, I am not so keen on the function names. They all start with json_! This mostly feels redundant to me, since the types of the parameters are part of the function signature.
Therefore, I would like to propose different names:
Existing Name Proposed Name
-------------------------- ----------------------------------------
json_array_length() array_length() or length() or size()
json_each() each_json()
json_each_as_text() each_text()
json_get() get_json()
json_get_as_text() get_text()
json_get_path() get_json()
json_get_path_as_text() get_text()
json_object_keys() get_keys()
json_populate_record() record() or row()
json_populate_recordset() records() or rows()
json_unnest() get_values()
json_agg() collect_json()Note that I have given json_get() and json_get_path() the same names, as it seems to me that the former is the same as the latter, with only one parameter. Same for json_get_as_text() and json_get_path_as_text().
I realize I'm in the minority here, but -1 from me on all of this.
Should we also rename xml_is_well_formed() to just is_well_formed()?
string_agg() to agg()? Eventually we will have more data types, and
some of them will have functions that could also be called rows() or
get_values(), but it's unlikely that they'll have exactly the same
behavior, which will start to make things confusing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb 15, 2013, at 9:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
I realize I'm in the minority here, but -1 from me on all of this.
Should we also rename xml_is_well_formed() to just is_well_formed()?
That would be nice, but I think that ship done sunk.
string_agg() to agg()?
Would love a different name, but IIRC that followed array_agg(), which was dictated by the SQL standard, in its infinite wisdom. See also =>.
Eventually we will have more data types, and
some of them will have functions that could also be called rows() or
get_values(), but it's unlikely that they'll have exactly the same
behavior, which will start to make things confusing.
Well, they will have to take account of *this* precedent and act accordingly. Much easier for them to look back at what has been done here than for us to look forward to something that today exists as no more than a twinkle in your eye.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/13/2013 11:36 AM, Andrew Dunstan wrote:
Therefore, I would like to propose different names:
Existing Name Proposed Name
-------------------------- ----------------------------------------
json_array_length() array_length() or length() or size()
json_each() each_json()
json_each_as_text() each_text()
json_get() get_json()
json_get_as_text() get_text()
json_get_path() get_json()
json_get_path_as_text() get_text()
json_object_keys() get_keys()
json_populate_record() record() or row()
json_populate_recordset() records() or rows()
json_unnest() get_values()
json_agg() collect_json()Note that I have given json_get() and json_get_path() the same names,
as it seems to me that the former is the same as the latter, with
only one parameter. Same for json_get_as_text() and
json_get_path_as_text().I will take some of this under advisement. Note that
json_populate_record's name was taken from hstore's populate_record,
so if we're trying to use similar names then it should possibly be
just populate_record. Or if that's still a bit long I would accept
to_record.
I have had a look at doing something like this with the json_get
functions. The trouble is that the best way to do it is to have json_get
take "variadic any", but then string literals come in as unknown rather
than as text, which makes things fairly ugly. If we force people to cast
path elements to text then I think the cure is worse than the disease. I
think the best we can do here is possibly to provide json_get and
json_get_text taking either a single int or variadic text[], and
json_get_path and json_get_path_text taking non-variadic text[].
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb 16, 2013, at 8:57 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
I have had a look at doing something like this with the json_get functions. The trouble is that the best way to do it is to have json_get take "variadic any", but then string literals come in as unknown rather than as text, which makes things fairly ugly. If we force people to cast path elements to text then I think the cure is worse than the disease. I think the best we can do here is possibly to provide json_get and json_get_text taking either a single int or variadic text[], and json_get_path and json_get_path_text taking non-variadic text[].
Why not also one taking a single text?
get(text)
get(int)
get(variadic text[])
?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013-02-16 11:55:26 -0800, David E. Wheeler wrote:
On Feb 16, 2013, at 8:57 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
I have had a look at doing something like this with the json_get functions. The trouble is that the best way to do it is to have json_get take "variadic any", but then string literals come in as unknown rather than as text, which makes things fairly ugly. If we force people to cast path elements to text then I think the cure is worse than the disease. I think the best we can do here is possibly to provide json_get and json_get_text taking either a single int or variadic text[], and json_get_path and json_get_path_text taking non-variadic text[].
Why not also one taking a single text?
get(text)
get(int)
get(variadic text[])
Those aren't differentiable by their argument types. Why should json be
able to claim that namespace and not other datatypes?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
