2020-04-13 17:55:45 +02:00
|
|
|
#! /usr/bin/perl
|
2008-06-23 19:54:30 +02:00
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
#
|
|
|
|
# Gen_fmgrtab.pl
|
2017-12-21 23:07:32 +01:00
|
|
|
# Perl script that generates fmgroids.h, fmgrprotos.h, and fmgrtab.c
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
# from pg_proc.dat
|
2008-06-23 19:54:30 +02:00
|
|
|
#
|
2023-01-02 21:00:37 +01:00
|
|
|
# Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2008-06-23 19:54:30 +02:00
|
|
|
# Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
#
|
|
|
|
#
|
|
|
|
# IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
# src/backend/utils/Gen_fmgrtab.pl
|
2008-06-23 19:54:30 +02:00
|
|
|
#
|
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
2010-01-05 02:06:57 +01:00
|
|
|
use Catalog;
|
|
|
|
|
2008-06-23 19:54:30 +02:00
|
|
|
use strict;
|
|
|
|
use warnings;
|
2019-02-12 15:53:36 +01:00
|
|
|
use Getopt::Long;
|
2008-06-23 19:54:30 +02:00
|
|
|
|
2010-01-05 02:06:57 +01:00
|
|
|
my $output_path = '';
|
2018-05-19 22:04:47 +02:00
|
|
|
my $include_path;
|
2017-10-04 09:22:38 +02:00
|
|
|
|
2019-02-12 15:53:36 +01:00
|
|
|
GetOptions(
|
|
|
|
'output:s' => \$output_path,
|
|
|
|
'include-path:s' => \$include_path) || usage();
|
2008-06-23 19:54:30 +02:00
|
|
|
|
2010-01-05 02:06:57 +01:00
|
|
|
# Make sure output_path ends in a slash.
|
|
|
|
if ($output_path ne '' && substr($output_path, -1) ne '/')
|
|
|
|
{
|
2012-07-05 03:47:49 +02:00
|
|
|
$output_path .= '/';
|
2010-01-05 02:06:57 +01:00
|
|
|
}
|
|
|
|
|
2017-10-04 09:22:38 +02:00
|
|
|
# Sanity check arguments.
|
2019-02-12 15:53:36 +01:00
|
|
|
die "No input files.\n" unless @ARGV;
|
|
|
|
die "--include-path must be specified.\n" unless $include_path;
|
2017-10-04 09:22:38 +02:00
|
|
|
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
# Read all the input files into internal data structures.
|
|
|
|
# Note: We pass data file names as arguments and then look for matching
|
|
|
|
# headers to parse the schema from. This is backwards from genbki.pl,
|
|
|
|
# but the Makefile dependencies look more sensible this way.
|
2019-01-04 00:38:49 +01:00
|
|
|
# We currently only need pg_proc, but retain the possibility of reading
|
|
|
|
# more than one data file.
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
my %catalogs;
|
|
|
|
my %catalog_data;
|
2019-02-12 15:53:36 +01:00
|
|
|
foreach my $datfile (@ARGV)
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
{
|
|
|
|
$datfile =~ /(.+)\.dat$/
|
|
|
|
or die "Input files need to be data (.dat) files.\n";
|
2017-10-04 09:22:38 +02:00
|
|
|
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
my $header = "$1.h";
|
|
|
|
die "There in no header file corresponding to $datfile"
|
|
|
|
if !-e $header;
|
2010-01-05 02:06:57 +01:00
|
|
|
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
my $catalog = Catalog::ParseHeader($header);
|
|
|
|
my $catname = $catalog->{catname};
|
|
|
|
my $schema = $catalog->{columns};
|
|
|
|
|
|
|
|
$catalogs{$catname} = $catalog;
|
|
|
|
$catalog_data{$catname} = Catalog::ParseData($datfile, $schema, 0);
|
2010-01-05 02:06:57 +01:00
|
|
|
}
|
2008-06-23 19:54:30 +02:00
|
|
|
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
# Collect certain fields from pg_proc.dat.
|
|
|
|
my @fmgr = ();
|
2020-11-02 17:57:28 +01:00
|
|
|
my %proname_counts;
|
2017-05-18 01:01:23 +02:00
|
|
|
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
foreach my $row (@{ $catalog_data{pg_proc} })
|
|
|
|
{
|
|
|
|
my %bki_values = %$row;
|
2012-07-05 03:47:49 +02:00
|
|
|
|
|
|
|
push @fmgr,
|
2018-05-09 16:14:46 +02:00
|
|
|
{
|
|
|
|
oid => $bki_values{oid},
|
2020-11-02 17:57:28 +01:00
|
|
|
name => $bki_values{proname},
|
|
|
|
lang => $bki_values{prolang},
|
2020-11-04 17:25:56 +01:00
|
|
|
kind => $bki_values{prokind},
|
Move bootstrap-time lookup of regproc OIDs into genbki.pl.
Formerly, the bootstrap backend looked up the OIDs corresponding to
names in regproc catalog entries using brute-force searches of pg_proc.
It was somewhat remarkable that that worked at all, since it was used
while populating other pretty-fundamental catalogs like pg_operator.
And it was also quite slow, and getting slower as pg_proc gets bigger.
This patch moves the lookup work into genbki.pl, so that the values in
postgres.bki for regproc columns are always numeric OIDs, an option
that regprocin() already supported. Perl isn't the world's speediest
language, so this about doubles the time needed to run genbki.pl (from
0.3 to 0.6 sec on my machine). But we only do that at most once per
build. The time needed to run initdb drops significantly --- on my
machine, initdb --no-sync goes from 1.8 to 1.3 seconds. So this is
a small net win even for just one initdb per build, and it becomes
quite a nice win for test sequences requiring many initdb runs.
Strip out the now-dead code for brute-force catalog searching in
regprocin. We'd also cargo-culted similar logic into regoperin
and some (not all) of the other reg*in functions. That is all
dead code too since we currently have no need to load such values
during bootstrap. I removed it all, reasoning that if we ever
need such functionality it'd be much better to do it in a similar
way to this patch.
There might be some simplifications possible in the backend now that
regprocin doesn't require doing catalog reads so early in bootstrap.
I've not looked into that, though.
Andreas Karlsson, with some small adjustments by me
Discussion: https://postgr.es/m/30896.1492006367@sss.pgh.pa.us
2017-04-13 18:07:47 +02:00
|
|
|
strict => $bki_values{proisstrict},
|
|
|
|
retset => $bki_values{proretset},
|
|
|
|
nargs => $bki_values{pronargs},
|
2020-11-02 17:57:28 +01:00
|
|
|
args => $bki_values{proargtypes},
|
2018-05-09 16:14:46 +02:00
|
|
|
prosrc => $bki_values{prosrc},
|
|
|
|
};
|
2020-11-02 17:57:28 +01:00
|
|
|
|
|
|
|
# Count so that we can detect overloaded pronames.
|
|
|
|
$proname_counts{ $bki_values{proname} }++;
|
2008-06-23 19:54:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
# Emit headers for both files
|
2012-07-05 03:47:49 +02:00
|
|
|
my $tmpext = ".tmp$$";
|
2010-01-05 21:23:32 +01:00
|
|
|
my $oidsfile = $output_path . 'fmgroids.h';
|
2016-12-28 18:00:00 +01:00
|
|
|
my $protosfile = $output_path . 'fmgrprotos.h';
|
2012-07-05 03:47:49 +02:00
|
|
|
my $tabfile = $output_path . 'fmgrtab.c';
|
2010-01-05 21:23:32 +01:00
|
|
|
|
2017-03-27 04:24:13 +02:00
|
|
|
open my $ofh, '>', $oidsfile . $tmpext
|
|
|
|
or die "Could not open $oidsfile$tmpext: $!";
|
|
|
|
open my $pfh, '>', $protosfile . $tmpext
|
|
|
|
or die "Could not open $protosfile$tmpext: $!";
|
|
|
|
open my $tfh, '>', $tabfile . $tmpext
|
|
|
|
or die "Could not open $tabfile$tmpext: $!";
|
2010-01-05 21:23:32 +01:00
|
|
|
|
2018-05-19 22:04:47 +02:00
|
|
|
print $ofh <<OFH;
|
|
|
|
/*-------------------------------------------------------------------------
|
2008-06-23 19:54:30 +02:00
|
|
|
*
|
|
|
|
* fmgroids.h
|
|
|
|
* Macros that define the OIDs of built-in functions.
|
|
|
|
*
|
|
|
|
* These macros can be used to avoid a catalog lookup when a specific
|
|
|
|
* fmgr-callable function needs to be referenced.
|
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2008-06-23 19:54:30 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* NOTES
|
|
|
|
* ******************************
|
|
|
|
* *** DO NOT EDIT THIS FILE! ***
|
|
|
|
* ******************************
|
|
|
|
*
|
Avoid putting build-location-dependent strings into generated files.
Various Perl scripts we use to generate files were in the habit of
printing things like "generated by $0" into their output files.
That looks like a fine idea at first glance, but it results in
non-reproducible output, because in VPATH builds $0 won't be just
the name of the script file, but a full path for it. We'd prefer
that you get identical results whether using VPATH or not, so this
is a bad thing.
Some of these places also printed their input file name(s), causing
an additional hazard of the same type.
Hence, establish a policy that thou shalt not print $0, nor input file
pathnames, into output files (they're still allowed in error messages,
though). Instead just write the script name verbatim. While we are at
it, we can make these annotations more useful by giving the script's
full relative path name within the PG source tree, eg instead of
Gen_fmgrtab.pl let's print src/backend/utils/Gen_fmgrtab.pl.
Not all of the changes made here actually affect any files shipped
in finished tarballs today, but it seems best to apply the policy
everyplace so that nobody copies unsafe code into places where it
could matter.
Christoph Berg and Tom Lane
Discussion: https://postgr.es/m/20171215102223.GB31812@msg.df7cb.de
2017-12-21 16:56:57 +01:00
|
|
|
* It has been GENERATED by src/backend/utils/Gen_fmgrtab.pl
|
2008-06-23 19:54:30 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef FMGROIDS_H
|
|
|
|
#define FMGROIDS_H
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Constant macros for the OIDs of entries in pg_proc.
|
|
|
|
*
|
2020-11-02 17:57:28 +01:00
|
|
|
* F_XXX macros are named after the proname field; if that is not unique,
|
|
|
|
* we append the proargtypes field, replacing spaces with underscores.
|
|
|
|
* For example, we have F_OIDEQ because that proname is unique, but
|
|
|
|
* F_POW_FLOAT8_FLOAT8 (among others) because that proname is not.
|
2008-06-23 19:54:30 +02:00
|
|
|
*/
|
2018-05-19 22:04:47 +02:00
|
|
|
OFH
|
2008-06-23 19:54:30 +02:00
|
|
|
|
2018-05-19 22:04:47 +02:00
|
|
|
print $pfh <<PFH;
|
|
|
|
/*-------------------------------------------------------------------------
|
2016-12-28 18:00:00 +01:00
|
|
|
*
|
|
|
|
* fmgrprotos.h
|
|
|
|
* Prototypes for built-in functions.
|
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2016-12-28 18:00:00 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* NOTES
|
|
|
|
* ******************************
|
|
|
|
* *** DO NOT EDIT THIS FILE! ***
|
|
|
|
* ******************************
|
|
|
|
*
|
Avoid putting build-location-dependent strings into generated files.
Various Perl scripts we use to generate files were in the habit of
printing things like "generated by $0" into their output files.
That looks like a fine idea at first glance, but it results in
non-reproducible output, because in VPATH builds $0 won't be just
the name of the script file, but a full path for it. We'd prefer
that you get identical results whether using VPATH or not, so this
is a bad thing.
Some of these places also printed their input file name(s), causing
an additional hazard of the same type.
Hence, establish a policy that thou shalt not print $0, nor input file
pathnames, into output files (they're still allowed in error messages,
though). Instead just write the script name verbatim. While we are at
it, we can make these annotations more useful by giving the script's
full relative path name within the PG source tree, eg instead of
Gen_fmgrtab.pl let's print src/backend/utils/Gen_fmgrtab.pl.
Not all of the changes made here actually affect any files shipped
in finished tarballs today, but it seems best to apply the policy
everyplace so that nobody copies unsafe code into places where it
could matter.
Christoph Berg and Tom Lane
Discussion: https://postgr.es/m/20171215102223.GB31812@msg.df7cb.de
2017-12-21 16:56:57 +01:00
|
|
|
* It has been GENERATED by src/backend/utils/Gen_fmgrtab.pl
|
2016-12-28 18:00:00 +01:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef FMGRPROTOS_H
|
|
|
|
#define FMGRPROTOS_H
|
|
|
|
|
|
|
|
#include "fmgr.h"
|
|
|
|
|
2018-05-19 22:04:47 +02:00
|
|
|
PFH
|
2016-12-28 18:00:00 +01:00
|
|
|
|
2018-05-19 22:04:47 +02:00
|
|
|
print $tfh <<TFH;
|
|
|
|
/*-------------------------------------------------------------------------
|
2008-06-23 19:54:30 +02:00
|
|
|
*
|
|
|
|
* fmgrtab.c
|
|
|
|
* The function manager's table of internal functions.
|
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2008-06-23 19:54:30 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* NOTES
|
|
|
|
*
|
|
|
|
* ******************************
|
|
|
|
* *** DO NOT EDIT THIS FILE! ***
|
|
|
|
* ******************************
|
|
|
|
*
|
Avoid putting build-location-dependent strings into generated files.
Various Perl scripts we use to generate files were in the habit of
printing things like "generated by $0" into their output files.
That looks like a fine idea at first glance, but it results in
non-reproducible output, because in VPATH builds $0 won't be just
the name of the script file, but a full path for it. We'd prefer
that you get identical results whether using VPATH or not, so this
is a bad thing.
Some of these places also printed their input file name(s), causing
an additional hazard of the same type.
Hence, establish a policy that thou shalt not print $0, nor input file
pathnames, into output files (they're still allowed in error messages,
though). Instead just write the script name verbatim. While we are at
it, we can make these annotations more useful by giving the script's
full relative path name within the PG source tree, eg instead of
Gen_fmgrtab.pl let's print src/backend/utils/Gen_fmgrtab.pl.
Not all of the changes made here actually affect any files shipped
in finished tarballs today, but it seems best to apply the policy
everyplace so that nobody copies unsafe code into places where it
could matter.
Christoph Berg and Tom Lane
Discussion: https://postgr.es/m/20171215102223.GB31812@msg.df7cb.de
2017-12-21 16:56:57 +01:00
|
|
|
* It has been GENERATED by src/backend/utils/Gen_fmgrtab.pl
|
2008-06-23 19:54:30 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2017-10-04 09:22:38 +02:00
|
|
|
#include "access/transam.h"
|
2008-06-23 19:54:30 +02:00
|
|
|
#include "utils/fmgrtab.h"
|
2016-12-28 18:00:00 +01:00
|
|
|
#include "utils/fmgrprotos.h"
|
2008-06-23 19:54:30 +02:00
|
|
|
|
2018-05-19 22:04:47 +02:00
|
|
|
TFH
|
2008-06-23 19:54:30 +02:00
|
|
|
|
2020-11-02 17:57:28 +01:00
|
|
|
# Emit fmgroids.h and fmgrprotos.h entries in OID order.
|
2008-06-23 19:54:30 +02:00
|
|
|
my %seenit;
|
2012-07-05 03:47:49 +02:00
|
|
|
foreach my $s (sort { $a->{oid} <=> $b->{oid} } @fmgr)
|
2008-06-23 19:54:30 +02:00
|
|
|
{
|
2020-11-02 17:57:28 +01:00
|
|
|
my $sqlname = $s->{name};
|
|
|
|
$sqlname .= "_" . $s->{args} if ($proname_counts{ $s->{name} } > 1);
|
|
|
|
$sqlname =~ s/\s+/_/g;
|
|
|
|
print $ofh "#define F_" . uc $sqlname . " $s->{oid}\n";
|
2020-11-04 17:25:56 +01:00
|
|
|
# We want only one extern per internal-language, non-aggregate function
|
|
|
|
if ( $s->{lang} eq 'internal'
|
|
|
|
&& $s->{kind} ne 'a'
|
|
|
|
&& !$seenit{ $s->{prosrc} })
|
2020-11-02 17:57:28 +01:00
|
|
|
{
|
|
|
|
$seenit{ $s->{prosrc} } = 1;
|
|
|
|
print $pfh "extern Datum $s->{prosrc}(PG_FUNCTION_ARGS);\n";
|
|
|
|
}
|
2008-06-23 19:54:30 +02:00
|
|
|
}
|
|
|
|
|
2017-10-04 09:22:38 +02:00
|
|
|
# Create the fmgr_builtins table, collect data for fmgr_builtin_oid_index
|
2017-03-27 04:24:13 +02:00
|
|
|
print $tfh "\nconst FmgrBuiltin fmgr_builtins[] = {\n";
|
2008-06-23 19:54:30 +02:00
|
|
|
my %bmap;
|
|
|
|
$bmap{'t'} = 'true';
|
|
|
|
$bmap{'f'} = 'false';
|
2017-10-04 09:22:38 +02:00
|
|
|
my @fmgr_builtin_oid_index;
|
2019-01-09 21:22:43 +01:00
|
|
|
my $last_builtin_oid = 0;
|
2017-10-04 09:22:38 +02:00
|
|
|
my $fmgr_count = 0;
|
2012-07-05 03:47:49 +02:00
|
|
|
foreach my $s (sort { $a->{oid} <=> $b->{oid} } @fmgr)
|
2008-06-23 19:54:30 +02:00
|
|
|
{
|
2020-11-02 17:57:28 +01:00
|
|
|
next if $s->{lang} ne 'internal';
|
2020-11-04 17:25:56 +01:00
|
|
|
# We do not need entries for aggregate functions
|
|
|
|
next if $s->{kind} eq 'a';
|
2020-11-02 17:57:28 +01:00
|
|
|
|
|
|
|
print $tfh ",\n" if ($fmgr_count > 0);
|
2017-03-27 04:24:13 +02:00
|
|
|
print $tfh
|
2018-10-16 23:51:18 +02:00
|
|
|
" { $s->{oid}, $s->{nargs}, $bmap{$s->{strict}}, $bmap{$s->{retset}}, \"$s->{prosrc}\", $s->{prosrc} }";
|
2017-10-04 09:22:38 +02:00
|
|
|
|
|
|
|
$fmgr_builtin_oid_index[ $s->{oid} ] = $fmgr_count++;
|
2019-01-09 21:22:43 +01:00
|
|
|
$last_builtin_oid = $s->{oid};
|
2017-10-04 09:22:38 +02:00
|
|
|
}
|
2020-11-02 17:57:28 +01:00
|
|
|
print $tfh "\n};\n";
|
2017-10-04 09:22:38 +02:00
|
|
|
|
2019-01-09 21:22:43 +01:00
|
|
|
printf $tfh qq|
|
2017-10-04 09:22:38 +02:00
|
|
|
const int fmgr_nbuiltins = (sizeof(fmgr_builtins) / sizeof(FmgrBuiltin));
|
2019-01-09 21:22:43 +01:00
|
|
|
|
|
|
|
const Oid fmgr_last_builtin_oid = %u;
|
|
|
|
|, $last_builtin_oid;
|
2017-10-04 09:22:38 +02:00
|
|
|
|
|
|
|
|
2019-06-17 09:13:16 +02:00
|
|
|
# Create fmgr_builtin_oid_index table.
|
2019-01-09 21:22:43 +01:00
|
|
|
printf $tfh qq|
|
|
|
|
const uint16 fmgr_builtin_oid_index[%u] = {
|
|
|
|
|, $last_builtin_oid + 1;
|
2017-10-04 09:22:38 +02:00
|
|
|
|
2019-01-09 21:22:43 +01:00
|
|
|
for (my $i = 0; $i <= $last_builtin_oid; $i++)
|
2017-10-04 09:22:38 +02:00
|
|
|
{
|
|
|
|
my $oid = $fmgr_builtin_oid_index[$i];
|
|
|
|
|
2019-01-09 21:22:43 +01:00
|
|
|
# fmgr_builtin_oid_index is sparse, map nonexistent functions to
|
2017-10-04 09:22:38 +02:00
|
|
|
# InvalidOidBuiltinMapping
|
|
|
|
if (not defined $oid)
|
|
|
|
{
|
|
|
|
$oid = 'InvalidOidBuiltinMapping';
|
|
|
|
}
|
|
|
|
|
2019-01-09 21:22:43 +01:00
|
|
|
if ($i == $last_builtin_oid)
|
2017-10-04 09:22:38 +02:00
|
|
|
{
|
|
|
|
print $tfh " $oid\n";
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
print $tfh " $oid,\n";
|
|
|
|
}
|
2008-06-23 19:54:30 +02:00
|
|
|
}
|
2017-10-04 09:22:38 +02:00
|
|
|
print $tfh "};\n";
|
|
|
|
|
2008-06-23 19:54:30 +02:00
|
|
|
|
|
|
|
# And add the file footers.
|
2018-05-19 22:04:47 +02:00
|
|
|
print $ofh "\n#endif\t\t\t\t\t\t\t/* FMGROIDS_H */\n";
|
|
|
|
print $pfh "\n#endif\t\t\t\t\t\t\t/* FMGRPROTOS_H */\n";
|
2008-06-23 19:54:30 +02:00
|
|
|
|
2017-03-27 04:24:13 +02:00
|
|
|
close($ofh);
|
|
|
|
close($pfh);
|
|
|
|
close($tfh);
|
2008-06-23 19:54:30 +02:00
|
|
|
|
|
|
|
# Finally, rename the completed files into place.
|
2010-01-05 21:23:32 +01:00
|
|
|
Catalog::RenameTempFile($oidsfile, $tmpext);
|
2016-12-28 18:00:00 +01:00
|
|
|
Catalog::RenameTempFile($protosfile, $tmpext);
|
2012-07-05 03:47:49 +02:00
|
|
|
Catalog::RenameTempFile($tabfile, $tmpext);
|
2010-01-05 02:06:57 +01:00
|
|
|
|
|
|
|
sub usage
|
|
|
|
{
|
2012-07-05 03:47:49 +02:00
|
|
|
die <<EOM;
|
2019-02-12 15:53:36 +01:00
|
|
|
Usage: perl -I [directory of Catalog.pm] Gen_fmgrtab.pl [--include-path/-i <path>] [path to pg_proc.dat]
|
|
|
|
|
|
|
|
Options:
|
|
|
|
--output Output directory (default '.')
|
|
|
|
--include-path Include path in source tree
|
2010-01-05 02:06:57 +01:00
|
|
|
|
2017-12-21 23:07:32 +01:00
|
|
|
Gen_fmgrtab.pl generates fmgroids.h, fmgrprotos.h, and fmgrtab.c from
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
pg_proc.dat
|
2010-01-05 02:06:57 +01:00
|
|
|
|
2019-01-19 19:06:35 +01:00
|
|
|
Report bugs to <pgsql-bugs\@lists.postgresql.org>.
|
2010-01-05 02:06:57 +01:00
|
|
|
EOM
|
|
|
|
}
|
2008-06-23 19:54:30 +02:00
|
|
|
|
|
|
|
exit 0;
|