Don't use SGML empty tags
For DocBook XML compatibility, don't use SGML empty tags () anymore,
replace by the full tag name. Add a warning option to catch future
occurrences.
Alexander Lakhin, Jürgen Purtz
Branch
--
master
Details
---
On Tue, Oct 17, 2017 at 12:23 PM, Peter Geoghegan wrote:
> On Tue, Oct 17, 2017 at 3:40 AM, Alvaro Herrera
> wrote:
>> Peter Geoghegan wrote:
>>
>>> Wouldn't this last "if" test, to cover the pg_upgrade case, be better
>>> targeted by comparing *raw* xmin
On Tue, Oct 17, 2017 at 3:40 AM, Alvaro Herrera wrote:
> Peter Geoghegan wrote:
>
>> Wouldn't this last "if" test, to cover the pg_upgrade case, be better
>> targeted by comparing *raw* xmin to FrozenTransactionId? You're using
>> the potentially distinct xmin value
Fix misparsing of non-newline-terminated pg_hba.conf files.
This back-patches the v10-cycle commit 1e5a5d03d into 9.3 - 9.6.
I had noticed at the time that that was fixing a bug, namely that
next_token() might advance *lineptr past the line-terminating '\0',
but given the lack of field complaints
Fix misparsing of non-newline-terminated pg_hba.conf files.
This back-patches the v10-cycle commit 1e5a5d03d into 9.3 - 9.6.
I had noticed at the time that that was fixing a bug, namely that
next_token() might advance *lineptr past the line-terminating '\0',
but given the lack of field complaints
Fix misparsing of non-newline-terminated pg_hba.conf files.
This back-patches the v10-cycle commit 1e5a5d03d into 9.3 - 9.6.
I had noticed at the time that that was fixing a bug, namely that
next_token() might advance *lineptr past the line-terminating '\0',
but given the lack of field complaints
Fix misparsing of non-newline-terminated pg_hba.conf files.
This back-patches the v10-cycle commit 1e5a5d03d into 9.3 - 9.6.
I had noticed at the time that that was fixing a bug, namely that
next_token() might advance *lineptr past the line-terminating '\0',
but given the lack of field complaints
Peter Geoghegan wrote:
> Wouldn't this last "if" test, to cover the pg_upgrade case, be better
> targeted by comparing *raw* xmin to FrozenTransactionId? You're using
> the potentially distinct xmin value returned by
> HeapTupleHeaderGetXmin() for the test here. I think we should be
> directly
REASSIGN OWNED BY doc: s/privileges/membership/
Reported by: David G. Johnston
Discussion:
https://postgr.es/m/cakfquwajwqjqel9xc1xnnmtybg32edazkjxijzigbosgss_...@mail.gmail.com
Branch
--
master
Details
---