On Fri, Mar 22, 2013 at 8:58 AM, Andrew Dunstan wrote:
>
> On 03/22/2013 09:29 AM, Merlin Moncure wrote:
>>
>> On Mon, Mar 18, 2013 at 3:12 PM, Tom Lane wrote:
>>>
>>> Andrew Dunstan writes:
I've been sitting here for a while mulling none too happily over the
debate on the names f
On 03/22/2013 09:29 AM, Merlin Moncure wrote:
On Mon, Mar 18, 2013 at 3:12 PM, Tom Lane wrote:
Andrew Dunstan writes:
I've been sitting here for a while mulling none too happily over the
debate on the names for the proposed JSON extraction functions. I
haven't really been happy with any of t
On Mon, Mar 18, 2013 at 3:12 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I've been sitting here for a while mulling none too happily over the
>> debate on the names for the proposed JSON extraction functions. I
>> haven't really been happy with any of the suggestions, much, not least
>> my ow
On 03/18/2013 12:29 PM, Andrew Dunstan wrote:
>
> One wrinkle in this picture is the variadic forms of extraction which
> don't lend themselves nicely to use with an operator. We could decide to
> do away with those altogether, or come up with a better name. I'm loath
> to use "json_path" since it
Andrew Dunstan writes:
> I've been sitting here for a while mulling none too happily over the
> debate on the names for the proposed JSON extraction functions. I
> haven't really been happy with any of the suggestions, much, not least
> my own original function names which were really only inte
On 03/01/2013 11:09 AM, Merlin Moncure wrote:
On Fri, Feb 22, 2013 at 11:50 AM, David E. Wheeler
wrote:
On Feb 22, 2013, at 9:37 AM, Robert Haas wrote:
What I think is NOT tolerable is choosing a set of short but arbitrary
names which are different from anything that we have now and
pretend
On Fri, Feb 22, 2013 at 11:50 AM, David E. Wheeler
wrote:
> On Feb 22, 2013, at 9:37 AM, Robert Haas wrote:
>
>> What I think is NOT tolerable is choosing a set of short but arbitrary
>> names which are different from anything that we have now and
>> pretending that we'll want to use those again
On Feb 22, 2013, at 9:37 AM, Robert Haas wrote:
> What I think is NOT tolerable is choosing a set of short but arbitrary
> names which are different from anything that we have now and
> pretending that we'll want to use those again for the next data type
> that comes along. That's just wishful t
On Thu, Feb 21, 2013 at 1:16 PM, Merlin Moncure wrote:
> Well, for case the of operator, it means whatever we reserve to mean.
> Very much agree on limitations of symbolic representation of behaviors
> (especially since some of the best ones were reserved by SQL or other
> acctors), so I think the
On Thu, Feb 21, 2013 at 11:02 AM, Robert Haas wrote:
> On Thu, Feb 21, 2013 at 10:51 AM, Merlin Moncure wrote:
>> Sure: but that's another straw man: abuse of + operator is case of
>> combining arbitrarily different behaviors (concatenation and
>> arithmetic aggregation) into uniform syntax. T
On Thu, Feb 21, 2013 at 10:51 AM, Merlin Moncure wrote:
> Sure: but that's another straw man: abuse of + operator is case of
> combining arbitrarily different behaviors (concatenation and
> arithmetic aggregation) into uniform syntax. This is bad, but a
> different thing. The right way to do
On Wed, Feb 20, 2013 at 9:42 AM, Robert Haas wrote:
> On Tue, Feb 19, 2013 at 10:00 AM, Merlin Moncure wrote:
>> Anyways, as to overloading in general, well, SQL is heavily
>> overloaded. We don't have int_max, float_max, etc. and it would be
>> usability reduction if we did.
>
> That's true, bu
On Tue, Feb 19, 2013 at 10:00 AM, Merlin Moncure wrote:
> Anyways, as to overloading in general, well, SQL is heavily
> overloaded. We don't have int_max, float_max, etc. and it would be
> usability reduction if we did.
That's true, but max(int) and max(float) are doing pretty much the
same logi
2013/2/19 Josh Berkus :
>
>>> I've come to value greppability of source code pretty highly. I think
>> that
>>> some of the points you raise are valid, but in my (minority) opinion
>>> overloading creates more problems than it solves. You're not going to
>>> convince me that get() is *ever* a goo
>> I've come to value greppability of source code pretty highly. I think
> that
>> some of the points you raise are valid, but in my (minority) opinion
>> overloading creates more problems than it solves. You're not going to
>> convince me that get() is *ever* a good name for a function - you mi
On Feb 19, 2013, at 6:11 AM, Petr Jelinek wrote:
>> some of the points you raise are valid, but in my (minority) opinion
>> overloading creates more problems than it solves. You're not going to
>> convince me that get() is *ever* a good name for a function - you might as
>> well call it thing()
On Tue, Feb 19, 2013 at 8:04 AM, Robert Haas wrote:
>> The argument for removing json_ prefix is that when function behaviors
>> are unambiguously controlled by the arguments, decorating the function
>> name to match the input argument is unnecessary verbosity.
>
> I've come to value greppability
2013/2/19 Petr Jelinek :
>> -Original Message-
>> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
>> ow...@postgresql.org] On Behalf Of Robert Haas
>> Sent: 19 February 2013 15:05
>> To: Merlin Moncure
>> Cc: David E. Wheeler; PostgreSQL-development Hackers
>> > The argument
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: 19 February 2013 15:05
> To: Merlin Moncure
> Cc: David E. Wheeler; PostgreSQL-development Hackers
> > The argument for removing json_ prefix is th
On Mon, Feb 18, 2013 at 10:42 AM, Merlin Moncure wrote:
> if you wanted to. And yes, I absolutely think this is superior to
> cluttering the public namespace with xml specific verbage, and could
> be extended to other formats. Look at the other way: we currently
> have encode(format text, stuff
On Fri, Feb 15, 2013 at 11:25 AM, Robert Haas wrote:
>> 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
On 02/17/2013 01:19 PM, David E. Wheeler wrote:
On Feb 17, 2013, at 6:33 AM, Andrew Dunstan wrote:
No, then we don't have a variadic version. You are going to have to accept that
we can't make one function name cover all of this.
Well, for me, I would rather specify an array than call a fun
On Feb 17, 2013, at 6:33 AM, Andrew Dunstan wrote:
> No, then we don't have a variadic version. You are going to have to accept
> that we can't make one function name cover all of this.
Well, for me, I would rather specify an array than call a function with a
different name. But it’s six of on
On 02/16/2013 07:50 PM, David E. Wheeler wrote:
On Feb 16, 2013, at 12:47 PM, Andrew Dunstan wrote:
To answer David's point, there is no point in having both
get(json,text)
get(json, variadic text[])
since the second can encompass the first, and having both would make calls
ambiguo
On Feb 16, 2013, at 12:47 PM, Andrew Dunstan wrote:
> To answer David's point, there is no point in having both
>
>get(json,text)
>get(json, variadic text[])
>
> since the second can encompass the first, and having both would make calls
> ambiguous.
Oh. Well then how about
get(jso
On 02/16/2013 03:05 PM, Andres Freund wrote:
On 2013-02-16 11:55:26 -0800, David E. Wheeler wrote:
On Feb 16, 2013, at 8:57 AM, Andrew Dunstan 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 tak
On 2013-02-16 11:55:26 -0800, David E. Wheeler wrote:
> On Feb 16, 2013, at 8:57 AM, Andrew Dunstan 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
On Feb 16, 2013, at 8:57 AM, Andrew Dunstan 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
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()
On Feb 15, 2013, at 9:25 AM, Robert Haas 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,
On Tue, Feb 12, 2013 at 2: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
On Wed, Feb 13, 2013 at 11:40 AM, Alvaro Herrera
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 wrote:
>
>> >>I think Merlin's suggestion if unwrap might be good. Or simply
>> >>"elements()" might work.
>> >Per
Andrew Dunstan wrote:
>
> On 02/13/2013 12:07 PM, David E. Wheeler wrote:
> >On Feb 13, 2013, at 8:36 AM, Andrew Dunstan 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?
>
>
On Feb 13, 2013, at 9:31 AM, Andrew Dunstan 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,
On 02/13/2013 12:07 PM, David E. Wheeler wrote:
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan 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 b
2013/2/13 David E. Wheeler :
> On Feb 13, 2013, at 8:36 AM, Andrew Dunstan 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 s
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan 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
Andrew Dunstan 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_recor
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
On Tue, Feb 12, 2013 at 1:18 PM, David E. Wheeler wrote:
couple other suggestions:
> Existing Name Proposed Name
> --
> json_array_length() array_length() or length() or size()
very much prefer wit
On Feb 12, 2013, at 8:00 PM, Merlin Moncure 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 anyeleme
On Tue, Feb 12, 2013 at 6:15 PM, Tom Lane wrote:
> Josh Berkus 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
Josh Berkus 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 f
On Feb 12, 2013, at 2:01 PM, Josh Berkus 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)
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 i
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
mon
46 matches
Mail list logo
