Make reformat_dat_file.pl preserve all blank lines.

In its original form, reformat_dat_file.pl smashed consecutive blank
lines to a single blank line, which was helpful for mopping up excess
whitespace during the bootstrap data format conversion.  But going
forward, there seems little reason to do that; if developers want to
put in multiple blank lines, let 'em.  This makes it conform to the
documentation I (tgl) wrote, too.

In passing, clean up some sloppy markup choices in bki.sgml.

John Naylor

Discussion: https://postgr.es/m/28827.1523039259@sss.pgh.pa.us
This commit is contained in:
Tom Lane 2018-04-09 14:58:39 -04:00
parent af1a949109
commit 2cdf359fc4
2 changed files with 8 additions and 17 deletions

View File

@ -129,19 +129,19 @@
</para> </para>
<para> <para>
Frontend code should not include any <structname>pg_xxx.h</structname> Frontend code should not include any <filename>pg_xxx.h</filename>
catalog header file, as these files may contain C code that won't compile catalog header file, as these files may contain C code that won't compile
outside the backend. (Typically, that happens because these files also outside the backend. (Typically, that happens because these files also
contain declarations for functions contain declarations for functions
in <filename>src/backend/catalog/</filename> files.) in <filename>src/backend/catalog/</filename> files.)
Instead, frontend code may include the corresponding Instead, frontend code may include the corresponding
generated <structname>pg_xxx_d.h</structname> header, which will contain generated <filename>pg_xxx_d.h</filename> header, which will contain
OID <literal>#define</literal>s and any other data that might be of use OID <literal>#define</literal>s and any other data that might be of use
on the client side. If you want macros or other code in a catalog header on the client side. If you want macros or other code in a catalog header
to be visible to frontend code, write <literal>#ifdef to be visible to frontend code, write <literal>#ifdef
EXPOSE_TO_CLIENT_CODE</literal> ... <literal>#endif</literal> around that EXPOSE_TO_CLIENT_CODE</literal> ... <literal>#endif</literal> around that
section to instruct <filename>genbki.pl</filename> to copy that section section to instruct <filename>genbki.pl</filename> to copy that section
to the <structname>pg_xxx_d.h</structname> header. to the <filename>pg_xxx_d.h</filename> header.
</para> </para>
<para> <para>
@ -419,11 +419,9 @@
Use of symbolic references is enabled in a particular catalog column Use of symbolic references is enabled in a particular catalog column
by attaching <literal>BKI_LOOKUP(<replaceable>lookuprule</replaceable>)</literal> by attaching <literal>BKI_LOOKUP(<replaceable>lookuprule</replaceable>)</literal>
to the column's definition, where <replaceable>lookuprule</replaceable> to the column's definition, where <replaceable>lookuprule</replaceable>
is <structname>pg_am</structname>, <structname>pg_proc</structname>, is <literal>pg_am</literal>, <literal>pg_proc</literal>,
<structname>pg_operator</structname>, <literal>pg_operator</literal>, <literal>pg_opclass</literal>,
<structname>pg_opclass</structname>, <literal>pg_opfamily</literal>, or <literal>pg_type</literal>.
<structname>pg_opfamily</structname>,
or <structname>pg_type</structname>.
<literal>BKI_LOOKUP</literal> can be attached to columns of <literal>BKI_LOOKUP</literal> can be attached to columns of
type <type>Oid</type>, <type>regproc</type>, <type>oidvector</type>, type <type>Oid</type>, <type>regproc</type>, <type>oidvector</type>,
or <type>Oid[]</type>; in the latter two cases it implies performing a or <type>Oid[]</type>; in the latter two cases it implies performing a

View File

@ -7,8 +7,7 @@
# #
# Metadata entries (if any) come first, with normal attributes # Metadata entries (if any) come first, with normal attributes
# starting on the following line, in the same order they would be in # starting on the following line, in the same order they would be in
# the corresponding table. Comments and non-consecutive blank lines # the corresponding table. Comments and blank lines are preserved.
# are preserved.
# #
# Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group # Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
# Portions Copyright (c) 1994, Regents of the University of California # Portions Copyright (c) 1994, Regents of the University of California
@ -109,7 +108,6 @@ foreach my $catname (@catnames)
my $catalog = $catalogs{$catname}; my $catalog = $catalogs{$catname};
my @attnames; my @attnames;
my $schema = $catalog->{columns}; my $schema = $catalog->{columns};
my $prev_blank = 0;
foreach my $column (@$schema) foreach my $column (@$schema)
{ {
@ -158,27 +156,22 @@ foreach my $catname (@catnames)
my $data_str = format_hash(\%values, @attnames); my $data_str = format_hash(\%values, @attnames);
print $dat $data_str; print $dat $data_str;
print $dat " },\n"; print $dat " },\n";
$prev_blank = 0;
} }
# Strings -- handle accordingly or ignore. It was necessary to # Strings -- handle accordingly or ignore. It was necessary to
# ignore bare commas during the initial data conversion. This # ignore bare commas during the initial data conversion. This
# should be a no-op now, but we may as well keep that behavior. # should be a no-op now, but we may as well keep that behavior.
# Note: We don't update $prev_blank if we ignore a string.
# Preserve non-consecutive blank lines. # Preserve blank lines.
elsif ($data =~ /^\s*$/) elsif ($data =~ /^\s*$/)
{ {
next if $prev_blank;
print $dat "\n"; print $dat "\n";
$prev_blank = 1;
} }
# Preserve comments or brackets that are on their own line. # Preserve comments or brackets that are on their own line.
elsif ($data =~ /^\s*(\[|\]|#.*?)\s*$/) elsif ($data =~ /^\s*(\[|\]|#.*?)\s*$/)
{ {
print $dat "$1\n"; print $dat "$1\n";
$prev_blank = 0;
} }
} }
close $dat; close $dat;