| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Proposal: Add JSON support |
| Date: | 2010-03-29 16:06:28 |
| Message-ID: | 603c8f071003290906q6bc3aedeh904c9c0d2a833e5b@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 29, 2010 at 12:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Mar 28, 2010 at 11:24 PM, Joseph Adams
>> <joeyadams3(dot)14159(at)gmail(dot)com> wrote:
>>> My reasoning for "It should be built-in" is:
>>> * It would be nice to have a built-in serialization format that's
>>> available by default.
>>> * It might be a little faster because it doesn't have to link to an
>>> external library.
>
>> I don't think either of these reasons is valid.
>
> FWIW, our track record with relying on external libraries has been less
> than great --- "upstream will maintain it" sounds good but has fallen
> over with respect to both the regex engine and the snowball stemmers,
> to take two examples. And libxml2 has been nothing but a source of pain.
>
> If this is going to end up being one fairly small C file implementing
> a spec that is not a moving target, I'd vote against depending on an
> external library instead, no matter how spiffy and license-compatible
> the external library might be.
Fair enough. Note that I did go on to say which reasons I did think
were potentially valid. ;-)
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-03-29 16:10:16 | Re: enable_joinremoval |
| Previous Message | Greg Smith | 2010-03-29 16:03:09 | Re: enable_joinremoval |