From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Peter van Hardenberg <pvh(at)pvh(dot)ca>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Calling json_* functions with JSONB data |
Date: | 2016-05-23 21:45:08 |
Message-ID: | CAKFQuwZazz+8YLueMV1p4+RzkaAmGyXyfV2xDjbdC8+hU6eEOQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 23, 2016 at 5:38 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> On 5/23/16 11:55 AM, Peter van Hardenberg wrote:
>
>> Fortunately, this seems quite easy to resolve by taking advantage of our
>> ability to add json_*(jsonb) form of the functions.
>>
>
> Another issue no one has mentioned is functions that return JSON/JSONB.
> IMO those should NOT be overloaded, because that will make it very easy to
> accidentally change from one type to the other without meaning to.
Actually, by definition they cannot be overloaded. A function's signature
is derived from its input types only.
http://www.postgresql.org/docs/devel/static/sql-createfunction.html
"""
The name of the new function must not match any existing function with the
same input argument types in the same schema. However, functions of
different argument types can share a name (this is called overloading).
"""
Admittedly the absence of "output" is not emphasized but overloading in
(most?) languages (small sample size for personal knowledge) is subject to
the same restriction.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2016-05-23 21:49:52 | Re: Inheritance |
Previous Message | Jim Nasby | 2016-05-23 21:38:16 | Re: Calling json_* functions with JSONB data |