1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>68.2. System Catalog Initial Data</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="system-catalog-declarations.html" title="68.1. System Catalog Declaration Rules" /><link rel="next" href="bki-format.html" title="68.3. BKI File Format" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">68.2. System Catalog Initial Data</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="system-catalog-declarations.html" title="68.1. System Catalog Declaration Rules">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="bki.html" title="Chapter 68. System Catalog Declarations and Initial Contents">Up</a></td><th width="60%" align="center">Chapter 68. System Catalog Declarations and Initial Contents</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="bki-format.html" title="68.3. BKI File Format">Next</a></td></tr></table><hr /></div><div class="sect1" id="SYSTEM-CATALOG-INITIAL-DATA"><div class="titlepage"><div><div><h2 class="title" style="clear: both">68.2. System Catalog Initial Data <a href="#SYSTEM-CATALOG-INITIAL-DATA" class="id_link">#</a></h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="system-catalog-initial-data.html#SYSTEM-CATALOG-INITIAL-DATA-FORMAT">68.2.1. Data File Format</a></span></dt><dt><span class="sect2"><a href="system-catalog-initial-data.html#SYSTEM-CATALOG-OID-ASSIGNMENT">68.2.2. OID Assignment</a></span></dt><dt><span class="sect2"><a href="system-catalog-initial-data.html#SYSTEM-CATALOG-OID-REFERENCES">68.2.3. OID Reference Lookup</a></span></dt><dt><span class="sect2"><a href="system-catalog-initial-data.html#SYSTEM-CATALOG-AUTO-ARRAY-TYPES">68.2.4. Automatic Creation of Array Types</a></span></dt><dt><span class="sect2"><a href="system-catalog-initial-data.html#SYSTEM-CATALOG-RECIPES">68.2.5. Recipes for Editing Data Files</a></span></dt></dl></div><p>
3 Each catalog that has any manually-created initial data (some do not)
4 has a corresponding <code class="literal">.dat</code> file that contains its
5 initial data in an editable format.
6 </p><div class="sect2" id="SYSTEM-CATALOG-INITIAL-DATA-FORMAT"><div class="titlepage"><div><div><h3 class="title">68.2.1. Data File Format <a href="#SYSTEM-CATALOG-INITIAL-DATA-FORMAT" class="id_link">#</a></h3></div></div></div><p>
7 Each <code class="literal">.dat</code> file contains Perl data structure literals
8 that are simply eval'd to produce an in-memory data structure consisting
9 of an array of hash references, one per catalog row.
10 A slightly modified excerpt from <code class="filename">pg_database.dat</code>
11 will demonstrate the key features:
12 </p><pre class="programlisting">
15 # A comment could appear here.
16 { oid => '1', oid_symbol => 'Template1DbOid',
17 descr => 'database\'s default template',
18 datname => 'template1', encoding => 'ENCODING',
19 datlocprovider => 'LOCALE_PROVIDER', datistemplate => 't',
20 datallowconn => 't', dathasloginevt => 'f', datconnlimit => '-1', datfrozenxid => '0',
21 datminmxid => '1', dattablespace => 'pg_default', datcollate => 'LC_COLLATE',
22 datctype => 'LC_CTYPE', datlocale => 'DATLOCALE', datacl => '_null_' },
27 </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
28 The overall file layout is: open square bracket, one or more sets of
29 curly braces each of which represents a catalog row, close square
30 bracket. Write a comma after each closing curly brace.
31 </p></li><li class="listitem"><p>
32 Within each catalog row, write comma-separated
33 <em class="replaceable"><code>key</code></em> <code class="literal">=></code>
34 <em class="replaceable"><code>value</code></em> pairs. The
35 allowed <em class="replaceable"><code>key</code></em>s are the names of the catalog's
36 columns, plus the metadata keys <code class="literal">oid</code>,
37 <code class="literal">oid_symbol</code>,
38 <code class="literal">array_type_oid</code>, and <code class="literal">descr</code>.
39 (The use of <code class="literal">oid</code> and <code class="literal">oid_symbol</code>
40 is described in <a class="xref" href="system-catalog-initial-data.html#SYSTEM-CATALOG-OID-ASSIGNMENT" title="68.2.2. OID Assignment">Section 68.2.2</a> below,
41 while <code class="literal">array_type_oid</code> is described in
42 <a class="xref" href="system-catalog-initial-data.html#SYSTEM-CATALOG-AUTO-ARRAY-TYPES" title="68.2.4. Automatic Creation of Array Types">Section 68.2.4</a>.
43 <code class="literal">descr</code> supplies a description string for the object,
44 which will be inserted into <code class="structname">pg_description</code>
45 or <code class="structname">pg_shdescription</code> as appropriate.)
46 While the metadata keys are optional, the catalog's defined columns
47 must all be provided, except when the catalog's <code class="literal">.h</code>
48 file specifies a default value for the column.
49 (In the example above, the <code class="structfield">datdba</code> field has
50 been omitted because <code class="filename">pg_database.h</code> supplies a
51 suitable default value for it.)
52 </p></li><li class="listitem"><p>
53 All values must be single-quoted. Escape single quotes used within a
54 value with a backslash. Backslashes meant as data can, but need not,
55 be doubled; this follows Perl's rules for simple quoted literals.
56 Note that backslashes appearing as data will be treated as escapes by
57 the bootstrap scanner, according to the same rules as for escape string
58 constants (see <a class="xref" href="sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-ESCAPE" title="4.1.2.2. String Constants with C-Style Escapes">Section 4.1.2.2</a>); for
59 example <code class="literal">\t</code> converts to a tab character. If you
60 actually want a backslash in the final value, you will need to write
61 four of them: Perl strips two, leaving <code class="literal">\\</code> for the
62 bootstrap scanner to see.
63 </p></li><li class="listitem"><p>
64 Null values are represented by <code class="literal">_null_</code>.
65 (Note that there is no way to create a value that is just that
67 </p></li><li class="listitem"><p>
68 Comments are preceded by <code class="literal">#</code>, and must be on their
70 </p></li><li class="listitem"><p>
71 Field values that are OIDs of other catalog entries should be
72 represented by symbolic names rather than actual numeric OIDs.
73 (In the example above, <code class="structfield">dattablespace</code>
74 contains such a reference.)
75 This is described in <a class="xref" href="system-catalog-initial-data.html#SYSTEM-CATALOG-OID-REFERENCES" title="68.2.3. OID Reference Lookup">Section 68.2.3</a>
77 </p></li><li class="listitem"><p>
78 Since hashes are unordered data structures, field order and line
79 layout aren't semantically significant. However, to maintain a
80 consistent appearance, we set a few rules that are applied by the
81 formatting script <code class="filename">reformat_dat_file.pl</code>:
83 </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "><li class="listitem"><p>
84 Within each pair of curly braces, the metadata
85 fields <code class="literal">oid</code>, <code class="literal">oid_symbol</code>,
86 <code class="literal">array_type_oid</code>, and <code class="literal">descr</code>
87 (if present) come first, in that order, then the catalog's own
88 fields appear in their defined order.
89 </p></li><li class="listitem"><p>
90 Newlines are inserted between fields as needed to limit line length
91 to 80 characters, if possible. A newline is also inserted between
92 the metadata fields and the regular fields.
93 </p></li><li class="listitem"><p>
94 If the catalog's <code class="literal">.h</code> file specifies a default
95 value for a column, and a data entry has that same
96 value, <code class="filename">reformat_dat_file.pl</code> will omit it from
97 the data file. This keeps the data representation compact.
98 </p></li><li class="listitem"><p>
99 <code class="filename">reformat_dat_file.pl</code> preserves blank lines
100 and comment lines as-is.
101 </p></li></ul></div><p>
103 It's recommended to run <code class="filename">reformat_dat_file.pl</code>
104 before submitting catalog data patches. For convenience, you can
105 simply change to <code class="filename">src/include/catalog/</code> and
106 run <code class="literal">make reformat-dat-files</code>.
107 </p></li><li class="listitem"><p>
108 If you want to add a new method of making the data representation
109 smaller, you must implement it
110 in <code class="filename">reformat_dat_file.pl</code> and also
111 teach <code class="function">Catalog::ParseData()</code> how to expand the
112 data back into the full representation.
113 </p></li></ul></div></div><div class="sect2" id="SYSTEM-CATALOG-OID-ASSIGNMENT"><div class="titlepage"><div><div><h3 class="title">68.2.2. OID Assignment <a href="#SYSTEM-CATALOG-OID-ASSIGNMENT" class="id_link">#</a></h3></div></div></div><p>
114 A catalog row appearing in the initial data can be given a
115 manually-assigned OID by writing an <code class="literal">oid
116 => <em class="replaceable"><code>nnnn</code></em></code> metadata field.
117 Furthermore, if an OID is assigned, a C macro for that OID can be
118 created by writing an <code class="literal">oid_symbol
119 => <em class="replaceable"><code>name</code></em></code> metadata field.
121 Pre-loaded catalog rows must have preassigned OIDs if there are OID
122 references to them in other pre-loaded rows. A preassigned OID is
123 also needed if the row's OID must be referenced from C code.
124 If neither case applies, the <code class="literal">oid</code> metadata field can
125 be omitted, in which case the bootstrap code assigns an OID
127 In practice we usually preassign OIDs for all or none of the pre-loaded
128 rows in a given catalog, even if only some of them are actually
131 Writing the actual numeric value of any OID in C code is considered
132 very bad form; always use a macro, instead. Direct references
133 to <code class="structname">pg_proc</code> OIDs are common enough that there's
134 a special mechanism to create the necessary macros automatically;
135 see <code class="filename">src/backend/utils/Gen_fmgrtab.pl</code>. Similarly
136 — but, for historical reasons, not done the same way —
137 there's an automatic method for creating macros
138 for <code class="structname">pg_type</code>
139 OIDs. <code class="literal">oid_symbol</code> entries are therefore not
140 necessary in those two catalogs. Likewise, macros for
141 the <code class="structname">pg_class</code> OIDs of system catalogs and
142 indexes are set up automatically. For all other system catalogs, you
143 have to manually specify any macros you need
144 via <code class="literal">oid_symbol</code> entries.
146 To find an available OID for a new pre-loaded row, run the
147 script <code class="filename">src/include/catalog/unused_oids</code>.
148 It prints inclusive ranges of unused OIDs (e.g., the output
149 line <code class="literal">45-900</code> means OIDs 45 through 900 have not been
150 allocated yet). Currently, OIDs 1–9999 are reserved for manual
151 assignment; the <code class="filename">unused_oids</code> script simply looks
152 through the catalog headers and <code class="filename">.dat</code> files
153 to see which ones do not appear. You can also use
154 the <code class="filename">duplicate_oids</code> script to check for mistakes.
155 (<code class="filename">genbki.pl</code> will assign OIDs for any rows that
156 didn't get one hand-assigned to them, and it will also detect duplicate
157 OIDs at compile time.)
159 When choosing OIDs for a patch that is not expected to be committed
160 immediately, best practice is to use a group of more-or-less
161 consecutive OIDs starting with some random choice in the range
162 8000—9999. This minimizes the risk of OID collisions with other
163 patches being developed concurrently. To keep the 8000—9999
164 range free for development purposes, after a patch has been committed
165 to the master git repository its OIDs should be renumbered into
166 available space below that range. Typically, this will be done
167 near the end of each development cycle, moving all OIDs consumed by
168 patches committed in that cycle at the same time. The script
169 <code class="filename">renumber_oids.pl</code> can be used for this purpose.
170 If an uncommitted patch is found to have OID conflicts with some
171 recently-committed patch, <code class="filename">renumber_oids.pl</code> may
172 also be useful for recovering from that situation.
174 Because of this convention of possibly renumbering OIDs assigned by
175 patches, the OIDs assigned by a patch should not be considered stable
176 until the patch has been included in an official release. We do not
177 change manually-assigned object OIDs once released, however, as that
178 would create assorted compatibility problems.
180 If <code class="filename">genbki.pl</code> needs to assign an OID to a catalog
181 entry that does not have a manually-assigned OID, it will use a value in
182 the range 10000—11999. The server's OID counter is set to 10000
183 at the start of a bootstrap run, so that any objects created on-the-fly
184 during bootstrap processing also receive OIDs in this range. (The
185 usual OID assignment mechanism takes care of preventing any conflicts.)
187 Objects with OIDs below <code class="symbol">FirstUnpinnedObjectId</code> (12000)
188 are considered <span class="quote">“<span class="quote">pinned</span>”</span>, preventing them from being
189 deleted. (There are a small number of exceptions, which are
190 hard-wired into <code class="function">IsPinnedObject()</code>.)
191 <span class="application">initdb</span> forces the OID counter up
192 to <code class="symbol">FirstUnpinnedObjectId</code> as soon as it's ready to
193 create unpinned objects. Thus objects created during the later phases
194 of <span class="application">initdb</span>, such as objects created while
195 running the <code class="filename">information_schema.sql</code> script, will
196 not be pinned, while all objects known
197 to <code class="filename">genbki.pl</code> will be.
199 OIDs assigned during normal database operation are constrained to be
200 16384 or higher. This ensures that the range 10000—16383 is free
201 for OIDs assigned automatically by <code class="filename">genbki.pl</code> or
202 during <span class="application">initdb</span>. These
203 automatically-assigned OIDs are not considered stable, and may change
204 from one installation to another.
205 </p></div><div class="sect2" id="SYSTEM-CATALOG-OID-REFERENCES"><div class="titlepage"><div><div><h3 class="title">68.2.3. OID Reference Lookup <a href="#SYSTEM-CATALOG-OID-REFERENCES" class="id_link">#</a></h3></div></div></div><p>
206 In principle, cross-references from one initial catalog row to another
207 could be written just by writing the preassigned OID of the referenced
208 row in the referencing field. However, that is against project
209 policy, because it is error-prone, hard to read, and subject to
210 breakage if a newly-assigned OID is renumbered. Therefore
211 <code class="filename">genbki.pl</code> provides mechanisms to write
212 symbolic references instead.
213 The rules are as follows:
214 </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
215 Use of symbolic references is enabled in a particular catalog column
216 by attaching <code class="literal">BKI_LOOKUP(<em class="replaceable"><code>lookuprule</code></em>)</code>
217 to the column's definition, where <em class="replaceable"><code>lookuprule</code></em>
218 is the name of the referenced catalog, e.g., <code class="literal">pg_proc</code>.
219 <code class="literal">BKI_LOOKUP</code> can be attached to columns of
220 type <code class="type">Oid</code>, <code class="type">regproc</code>, <code class="type">oidvector</code>,
221 or <code class="type">Oid[]</code>; in the latter two cases it implies performing a
222 lookup on each element of the array.
223 </p></li><li class="listitem"><p>
224 It's also permissible to attach <code class="literal">BKI_LOOKUP(encoding)</code>
225 to integer columns to reference character set encodings, which are
226 not currently represented as catalog OIDs, but have a set of values
227 known to <code class="filename">genbki.pl</code>.
228 </p></li><li class="listitem"><p>
229 In some catalog columns, it's allowed for entries to be zero instead
230 of a valid reference. If this is allowed, write
231 <code class="literal">BKI_LOOKUP_OPT</code> instead
232 of <code class="literal">BKI_LOOKUP</code>. Then you can
233 write <code class="literal">0</code> for an entry. (If the column is
234 declared <code class="type">regproc</code>, you can optionally
235 write <code class="literal">-</code> instead of <code class="literal">0</code>.)
236 Except for this special case, all entries in
237 a <code class="literal">BKI_LOOKUP</code> column must be symbolic references.
238 <code class="filename">genbki.pl</code> will warn about unrecognized names.
239 </p></li><li class="listitem"><p>
240 Most kinds of catalog objects are simply referenced by their names.
241 Note that type names must exactly match the
242 referenced <code class="structname">pg_type</code>
243 entry's <code class="structfield">typname</code>; you do not get to use
244 any aliases such as <code class="literal">integer</code>
245 for <code class="literal">int4</code>.
246 </p></li><li class="listitem"><p>
247 A function can be represented by
248 its <code class="structfield">proname</code>, if that is unique among
249 the <code class="filename">pg_proc.dat</code> entries (this works like regproc
250 input). Otherwise, write it
251 as <em class="replaceable"><code>proname(argtypename,argtypename,...)</code></em>,
252 like regprocedure. The argument type names must be spelled exactly as
253 they are in the <code class="filename">pg_proc.dat</code> entry's
254 <code class="structfield">proargtypes</code> field. Do not insert any
256 </p></li><li class="listitem"><p>
257 Operators are represented
258 by <em class="replaceable"><code>oprname(lefttype,righttype)</code></em>,
259 writing the type names exactly as they appear in
260 the <code class="filename">pg_operator.dat</code>
261 entry's <code class="structfield">oprleft</code>
262 and <code class="structfield">oprright</code> fields.
263 (Write <code class="literal">0</code> for the omitted operand of a unary
265 </p></li><li class="listitem"><p>
266 The names of opclasses and opfamilies are only unique within an
267 access method, so they are represented
268 by <em class="replaceable"><code>access_method_name</code></em><code class="literal">/</code><em class="replaceable"><code>object_name</code></em>.
269 </p></li><li class="listitem"><p>
270 In none of these cases is there any provision for
271 schema-qualification; all objects created during bootstrap are
272 expected to be in the <code class="literal">pg_catalog</code> schema.
273 </p></li></ul></div><p>
274 <code class="filename">genbki.pl</code> resolves all symbolic references while it
275 runs, and puts simple numeric OIDs into the emitted BKI file. There is
276 therefore no need for the bootstrap backend to deal with symbolic
279 It's desirable to mark OID reference columns
280 with <code class="literal">BKI_LOOKUP</code> or <code class="literal">BKI_LOOKUP_OPT</code>
281 even if the catalog has no initial data that requires lookup. This
282 allows <code class="filename">genbki.pl</code> to record the foreign key
283 relationships that exist in the system catalogs. That information is
284 used in the regression tests to check for incorrect entries. See also
285 the macros <code class="literal">DECLARE_FOREIGN_KEY</code>,
286 <code class="literal">DECLARE_FOREIGN_KEY_OPT</code>,
287 <code class="literal">DECLARE_ARRAY_FOREIGN_KEY</code>,
288 and <code class="literal">DECLARE_ARRAY_FOREIGN_KEY_OPT</code>, which are
289 used to declare foreign key relationships that are too complex
290 for <code class="literal">BKI_LOOKUP</code> (typically, multi-column foreign
292 </p></div><div class="sect2" id="SYSTEM-CATALOG-AUTO-ARRAY-TYPES"><div class="titlepage"><div><div><h3 class="title">68.2.4. Automatic Creation of Array Types <a href="#SYSTEM-CATALOG-AUTO-ARRAY-TYPES" class="id_link">#</a></h3></div></div></div><p>
293 Most scalar data types should have a corresponding array type (that is,
294 a standard varlena array type whose element type is the scalar type, and
295 which is referenced by the <code class="structfield">typarray</code> field of
296 the scalar type's <code class="structname">pg_type</code>
297 entry). <code class="filename">genbki.pl</code> is able to generate
298 the <code class="structname">pg_type</code> entry for the array type
299 automatically in most cases.
301 To use this facility, just write an <code class="literal">array_type_oid
302 => <em class="replaceable"><code>nnnn</code></em></code> metadata field in the
303 scalar type's <code class="structname">pg_type</code> entry, specifying the OID
304 to use for the array type. You may then omit
305 the <code class="structfield">typarray</code> field, since it will be filled
306 automatically with that OID.
308 The generated array type's name is the scalar type's name with an
309 underscore prepended. The array entry's other fields are filled from
310 <code class="literal">BKI_ARRAY_DEFAULT(<em class="replaceable"><code>value</code></em>)</code>
311 annotations in <code class="filename">pg_type.h</code>, or if there isn't one,
312 copied from the scalar type. (There's also a special case
313 for <code class="structfield">typalign</code>.) Then
314 the <code class="structfield">typelem</code>
315 and <code class="structfield">typarray</code> fields of the two entries are
316 set to cross-reference each other.
317 </p></div><div class="sect2" id="SYSTEM-CATALOG-RECIPES"><div class="titlepage"><div><div><h3 class="title">68.2.5. Recipes for Editing Data Files <a href="#SYSTEM-CATALOG-RECIPES" class="id_link">#</a></h3></div></div></div><p>
318 Here are some suggestions about the easiest ways to perform common tasks
319 when updating catalog data files.
320 </p><p><strong>Add a new column with a default to a catalog: </strong>
321 Add the column to the header file with
322 a <code class="literal">BKI_DEFAULT(<em class="replaceable"><code>value</code></em>)</code>
323 annotation. The data file need only be adjusted by adding the field
324 in existing rows where a non-default value is needed.
325 </p><p><strong>Add a default value to an existing column that doesn't have
327 Add a <code class="literal">BKI_DEFAULT</code> annotation to the header file,
328 then run <code class="literal">make reformat-dat-files</code> to remove
329 now-redundant field entries.
330 </p><p><strong>Remove a column, whether it has a default or not: </strong>
331 Remove the column from the header, then run <code class="literal">make
332 reformat-dat-files</code> to remove now-useless field entries.
333 </p><p><strong>Change or remove an existing default value: </strong>
334 You cannot simply change the header file, since that will cause the
335 current data to be interpreted incorrectly. First run <code class="literal">make
336 expand-dat-files</code> to rewrite the data files with all
337 default values inserted explicitly, then change or remove
338 the <code class="literal">BKI_DEFAULT</code> annotation, then run <code class="literal">make
339 reformat-dat-files</code> to remove superfluous fields again.
340 </p><p><strong>Ad-hoc bulk editing: </strong>
341 <code class="filename">reformat_dat_file.pl</code> can be adapted to perform
342 many kinds of bulk changes. Look for its block comments showing where
343 one-off code can be inserted. In the following example, we are going
344 to consolidate two Boolean fields in <code class="structname">pg_proc</code>
347 </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
348 Add the new column, with a default,
349 to <code class="filename">pg_proc.h</code>:
350 </p><pre class="programlisting">
351 + /* see PROKIND_ categories below */
352 + char prokind BKI_DEFAULT(f);
354 </p></li><li class="listitem"><p>
355 Create a new script based on <code class="filename">reformat_dat_file.pl</code>
356 to insert appropriate values on-the-fly:
357 </p><pre class="programlisting">
358 - # At this point we have the full row in memory as a hash
359 - # and can do any operations we want. As written, it only
360 - # removes default values, but this script can be adapted to
361 - # do one-off bulk-editing.
362 + # One-off change to migrate to prokind
363 + # Default has already been filled in by now, so change to other
364 + # values as appropriate
365 + if ($values{proisagg} eq 't')
367 + $values{prokind} = 'a';
369 + elsif ($values{proiswindow} eq 't')
371 + $values{prokind} = 'w';
374 </p></li><li class="listitem"><p>
376 </p><pre class="programlisting">
377 $ cd src/include/catalog
378 $ perl rewrite_dat_with_prokind.pl pg_proc.dat
380 At this point <code class="filename">pg_proc.dat</code> has all three
381 columns, <code class="structfield">prokind</code>,
382 <code class="structfield">proisagg</code>,
383 and <code class="structfield">proiswindow</code>, though they will appear
384 only in rows where they have non-default values.
385 </p></li><li class="listitem"><p>
386 Remove the old columns from <code class="filename">pg_proc.h</code>:
387 </p><pre class="programlisting">
388 - /* is it an aggregate? */
389 - bool proisagg BKI_DEFAULT(f);
391 - /* is it a window function? */
392 - bool proiswindow BKI_DEFAULT(f);
394 </p></li><li class="listitem"><p>
395 Finally, run <code class="literal">make reformat-dat-files</code> to remove
396 the useless old entries from <code class="filename">pg_proc.dat</code>.
397 </p></li></ol></div><p>
399 For further examples of scripts used for bulk editing, see
400 <code class="filename">convert_oid2name.pl</code>
401 and <code class="filename">remove_pg_type_oid_symbols.pl</code> attached to this
403 <a class="ulink" href="https://www.postgresql.org/message-id/CAJVSVGVX8gXnPm+Xa=DxR7kFYprcQ1tNcCT5D0O3ShfnM6jehA@mail.gmail.com" target="_top">https://www.postgresql.org/message-id/CAJVSVGVX8gXnPm+Xa=DxR7kFYprcQ1tNcCT5D0O3ShfnM6jehA@mail.gmail.com</a>
404 </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="system-catalog-declarations.html" title="68.1. System Catalog Declaration Rules">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bki.html" title="Chapter 68. System Catalog Declarations and Initial Contents">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bki-format.html" title="68.3. BKI File Format">Next</a></td></tr><tr><td width="40%" align="left" valign="top">68.1. System Catalog Declaration Rules </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 68.3. <acronym class="acronym">BKI</acronym> File Format</td></tr></table></div></body></html>
begriffs.com / projects / ai-pg / blob