| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Johnston <polobo(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: additional json functionality |
| Date: | 2013-11-20 18:51:52 |
| Message-ID: | 528D04C8.9070307@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/20/2013 01:36 PM, Tom Lane wrote:
>
> You'd have to make the data self-identifying (which I think was the plan
> already), and ensure that *every* function taking "json" could cope with
> both formats on input. The typmod could only be expected to be enforced
> when storing or explicitly casting to one subformat, much like operations
> on "numeric" pay little attention to the original precision/scale if any.
>
> I agree that this solution isn't terribly workable, mainly because it'd
> break any third-party C functions that take json today.
>
>
Yeah, I had come to this conclusion. I don't think we can bolt on
typmods after the event.
I don't think having a separate "jsonb" type will be a tragedy.
I'm already planning on overloading the existing json functions and
operators.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabrízio de Royes Mello | 2013-11-20 18:52:04 | [PATCH] Store Extension Options |
| Previous Message | Josh Berkus | 2013-11-20 18:48:41 | Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1 |