From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "David E(dot) Wheeler" <david(at)justatheory(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: JSON Function Bike Shedding |
Date: | 2013-02-18 15:42:08 |
Message-ID: | CAHyXU0zSzosFjUrDgARLnyj__GR2dMAjnfS7fYVvMg3WDfJVfw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 15, 2013 at 11:25 AM, Robert Haas <robertmhaas(at)gmail(dot)com> 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 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.
It's a little late, but I'd like to rebut this point:
> string_agg() to agg()?
This not germane to the discussion. string_agg means you are
aggregating *to* a string, not from one, which is a completely
different thing. This also applies to to_char, to_date, etc. If you
wanted to do just 'agg()', you'd have to supply output type somehow --
the only way to do that in postgres is to use hstore null::foo trick
(which is not an improvement obviously).
> xml_is_well_formed() to just is_well_formed()?
Again, this is not the same thing. It does not work on the xml type,
but text, so you'd have to supply a hint to specific behaviors if you
wanted to abstract type out of the function. Because the returned
type is unambiguously boolean though, you can get away with:
validate(format text, data text);
select validate('json', <json string>);
select validate('xml', <xml string>);
etc.
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 bytea). Would we be better off with
hex_encode(bytea), escape_encode(bytea)... .etc?
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.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-02-18 15:50:44 | Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system |
Previous Message | Kevin Grittner | 2013-02-18 15:18:34 | Re: Materialized views WIP patch |