From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: JSON Function Bike Shedding |
Date: | 2013-02-13 04:00:45 |
Message-ID: | CAHyXU0xzWtxc7XCTv6e2LPoUC5GLBHtvnMOo7ys5s8O9tTLdAg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 12, 2013 at 6:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2013-02-13 05:37:57 | Re: JSON Function Bike Shedding |
Previous Message | Amit Kapila | 2013-02-13 03:38:21 | Re: Identity projection |