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 <br...@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 +