Re: backup manifests

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: backup manifests
Дата
Msg-id 12445.1579024384@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: backup manifests  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: backup manifests
Re: backup manifests
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> ... I would also expect that depending on an external package
> would provoke significant opposition. If we suck the code into core,
> then we have to keep it up to date with the upstream, which is a
> significant maintenance burden - look at all the time Tom has spent on
> snowball, regex, and time zone code over the years.

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.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Create/alter policy and exclusive table lock
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: Unicode escapes with any backend encoding