On Tue, Jan 14, 2020 at 12:53:04PM -0500, Tom Lane wrote:
> Also worth noting is that we have a seriously bad track record about
> choosing external packages to depend on. The regex code has no upstream
> maintainer anymore (well, the Tcl guys seem to think that *we* are
> upstream for that now), and snowball is next door to moribund.
> With C not being a particularly hip language to develop in anymore,
> it wouldn't surprise me in the least for any C-code JSON parser
> we might pick to go dead pretty soon.
>
> Between that problem and the likelihood that we'd need to make
> significant code changes anyway to meet our own coding style etc
> expectations, I think really we'd have to assume that we're going
> to fork and maintain our own copy of any code we pick.
>
> Now, if it's a small enough chunk of code (and really, how complex
> is JSON parsing anyway) maybe that doesn't matter. But I tend to
> agree with Robert's position that it's a big ask for this patch
> to introduce a frontend JSON parser.
I know we have talked about our experience in maintaining external code:
* TCL regex
* Snowball
* Timezone handling
However, the regex code is complex, and the Snowball and timezone code
is improved as they add new languages and time zones. I don't see JSON
parsing as complex or likely to change much, so it might be acceptable
to include it in our frontend code.
As far as using tab-delimited data, I know this usage was compared to
postgresql.conf and pg_hba.conf, which don't change much. However,
those files are not usually written, and do not contain user data, while
the backup file might contain user-specified paths if they are not just
relative to the PGDATA directory, and that would make escaping a
requirement.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +