2 <!-- Shouldn't have to use a SYSTEM doctype -->
3 <!DOCTYPE appendix SYSTEM "/usr/share/xml/docbook/schema/dtd/5.0/docbook.dtd" [
5 <!-- Use symbols for repeating text. -->
6 <!ENTITY % entities SYSTEM "entities">
8 <!-- Use symbols for hardcoded Gombe-MI data -->
9 <!ENTITY % constants SYSTEM "constants">
12 <!-- <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook V5.0//EN"
13 "http://www.oasis-open.org/docbook/xml/5.0/docbook.dtd">
15 <!-- Copyright (C) 2015 The Meme Factory, Inc. http://www.meme.com/
16 - See document output for full copyright information. -->
18 <!-- Documentation of the warning system. -->
20 <appendix xml:id="warning_system"
21 xmlns="http://docbook.org/ns/docbook"
23 <title>The Warning Sub-System</title>
25 <section xml:id="warning_system-introduction">
26 <title>Introduction to the Warning Sub-System</title>
28 <para>For the most part, database integrity checks are built into
29 the system and it should not be possible to put invalid data into
30 the database. However in some cases, whether for reasons of
31 complexity or for some other reason, some database integrity
32 problems are not caught by the system. There are also
33 questionable cases; situations where the acceptability of the
34 data is dependent upon circumstances. In these cases it is useful
35 for the system to provide a warning and allow the user to decide
36 whether a problem really exists. It is for these reasons that the
37 warning sub-system exists.</para>
39 <para>The warning sub-system provides a means by which the system
40 can be supplied with arbitrary queries which validate data
41 integrity. These queries are stored and, when activated, report
42 arbitrary problems with the database's data integrity, either
43 warning conditions or errors. Errors are always reported when the
44 warning system is activated. Individual warnings reported by the
45 supplied queries are then manually sorted into one of the
46 following categories: unclassified (the default),
47 labeled <quote>resolved</quote>, or deferred until a later date.
48 When the warning system is activated unclassified warnings are
49 reported, <quote>resolved</quote> warnings are not reported, and
50 deferred warnings are not reported until the current date reaches
51 the deferral date.</para>
53 <para>Unlike the database integrity checks built into the rest of
54 the system which report problems immediately as data is inserted
55 into the database, the warning system does nothing until
58 <para>The warning system is activated by use of one of the
59 <link linkend="warning_system-The-Warning-Sub-System-Functions">supplied
60 functions</link>, causing one or more of the stored queries to
61 check the state of the database.</para>
65 <section xml:id="warning_system-Overview">
66 <title>An Overview of the Warning Sub-System Data Structures</title>
68 <para>This section provides an overview of the data structures
69 used by the warning sub-system.</para>
72 href="warning_main_tables.xml"
73 xmlns:xi="http://www.w3.org/2001/XInclude"/>
76 href="warning_support_tables.xml"
77 xmlns:xi="http://www.w3.org/2001/XInclude"/>
80 href="warning_diagrams.xml"
81 xmlns:xi="http://www.w3.org/2001/XInclude"/>
85 <section xml:id="warning_system-Main-Tables">
86 <title>The Warning Sub-System Main Tables</title>
88 <para>All date plus time values (timestamps) have a one second
89 precision. Fractions of a second are not recorded.</para>
91 <section xml:id="INTEGRITY_QUERIES" xreflabel="INTEGRITY_QUERIES">
92 <title>INTEGRITY_QUERIES</title>
94 <para>The INTEGRITY_QUERIES contains one row for every query
95 used to search for database integrity issues.</para>
97 <para>The <xref linkend="Integrity_Queries-Last_Run"/> value
99 <xref linkend="Integrity_Queries-First_Run"/> value.</para>
102 <para>Use &postgresql;'s &dollar_quoting; when inserting
103 queries into INTEGRITY_QUERIES using <command>INSERT</command>
104 statements. This avoids problems that would otherwise arise
105 involving the use of quote characters inside quoted strings.
109 <title>Inserting a query into INTEGRITY_QUERIES using dollar
112 <literallayout><code>INSERT INTO integrity_queries (iqname, error, type, query)
113 VALUES('mycheck', false, 'bdate',
114 $$SELECT 'Bad birthdate: ' || mytable.id || ', ' || mytable.birthdate
118 || ') has a birthdate ('
123 WHERE mytable.birthdate < '1950-01-01'$$
124 );</code></literallayout>
128 <section xml:id="Integrity_Queries-IQName" xreflabel="IQName">
129 <title>IQName (Integrity Query Name)</title>
131 <para>A unique name for the query. The IQName value cannot be
132 changed. &emptytext; ¬null; &nospaces; The IQName value
133 may contain no more than &warn_iqname_len; characters.</para>
136 <section xml:id="Integrity_Queries-Error" xreflabel="Error">
139 <para>A Boolean value. &true; when the query finds conditions
140 that are errors, &false; when the query finds conditions that
141 are warnings. See <xref linkend="INTEGRITY_WARNINGS"/> (and
142 the <xref linkend="warning_system-introduction"/>)
143 for <link linkend="warnings-vs-errors">more</link> on warnings
146 <para>¬null;</para>
149 <section xml:id="Integrity_Queries-Type" xreflabel="Type">
152 <para>Code classifying the query. The legal values for this
153 column are defined by the <xref linkend="IQTYPES"/> support
156 <para>¬null;</para>
159 <section xml:id="Integrity_Queries-First_Run" xreflabel="First_Run">
160 <title>First_Run</title>
162 <para>Date and time the query was first run by the warning
163 sub-system. &null; if the query has never been run.</para>
166 <section xml:id="Integrity_Queries-Last_Run" xreflabel="Last_Run">
167 <title>Last_Run</title>
169 <para>Date and time the query was most recently run by the
170 warning sub-system. &null; if the query has never been
174 <section xml:id="Integrity_Queries-Query" xreflabel="Query">
177 <para>A query which checks for database integrity violations.
178 The query need not end in a semi-colon. The query must return
179 2 columns, both of type <code>TEXT</code>.</para>
181 <section xml:id="Integrity_Queries-Query-Col1" xreflabel="ID">
182 <title>The first returned column, the ID column</title>
184 <para>The first column is used as an id. It must contain a
185 unique value. (Unique per results returned by the given
186 query). The value must also be constant; repeated runs of
187 the query which find the same problem must return a
188 consistent value.</para>
191 <para>The system can not enforce the requirement that the
192 first column be consistent over repeated runs of the
193 query. If the query does not satisfy this requirement the
194 warning sub-system will generate duplicates of previously
195 reported problems.</para>
198 <para>The value of the first column may not be &null; or the
201 <para>Guidelines for the value of the first column are that
202 it should be human readable and relatively short. It should
203 probably contain id values in order to ensure uniqueness,
204 but only those that will not change over time.</para>
206 <para>The value of this first column may need to be typed in
207 or otherwise referenced by a person in order to make notes
208 regarding the problem or to change the problem's
212 <section xml:id="Integrity_Queries-Query-Col2" xreflabel="Msg">
213 <title>The second returned column, the Msg column</title>
215 <para>The second column contains a message describing the
216 discovered database integrity problem. It should contain a
217 complete description of the problem and may be as verbose as
220 <para>The value of the second column may not be &null; or the
226 <section xml:id="Integrity_Queries-Comment" xreflabel="Commment">
227 <title>Comment</title>
229 <para>A textual comment regards the query. This may be as
230 verbose as necessary. &emptytext; This column may contain
231 &null; when no comment is desired.</para>
235 <section xml:id="INTEGRITY_WARNINGS" xreflabel="INTEGRITY_WARNINGS">
236 <title>INTEGRITY_WARNINGS (Warning Sub-System Results)</title>
238 <para>The INTEGRITY_WARNINGS table contains one row for every
239 database integrity problem discovered by the queries in
240 <xref linkend="INTEGRITY_QUERIES"/>. It's purpose is twofold.
241 It provides an efficient way to list data integrity problems,
242 without having to execute the potentially complex queries which
243 discover the problems. But it's main purpose is to allow
244 warnings, i.e. those problems discovered by the queries saved in
245 <xref linkend="INTEGRITY_QUERIES"/> rows having a &false;
246 <xref linkend="Integrity_Queries-Error"/> value, to be resolved
247 -- permanently marked as acceptable conditions. Resolved
248 warnings can be safely ignored thereafter, and since the warning
249 sub-system automatically ignores resolved warnings those
250 responsible for maintaining database integrity need not
251 repeatedly concern themselves with resolved conditions.</para>
253 <para>To resolve a warning place a timestamp in the
254 <xref linkend="Integrity_Warnings-Resolved"/> column.</para>
256 <para xml:id="warnings-vs-errors">Data integrity errors can not
257 be resolved, the erroneous data condition must be fixed --
258 INTEGRITY_WARNINGS rows must have a &null;
259 <xref linkend="Integrity_Warnings-Resolved"/> value when the row
260 has a <xref linkend="Integrity_Warnings-IQName"/> related to an
261 <xref linkend="INTEGRITY_QUERIES"/> row having a &true;
262 <xref linkend="Integrity_Queries-Error"/> value.</para>
264 <para>The <xref linkend="Integrity_Warnings-Last_Seen"/> value,
265 the <xref linkend="Integrity_Warnings-Resolved"/> value, and the
266 <xref linkend="Integrity_Warnings-Deferred_To"/> value cannot be
267 before the <xref linkend="Integrity_Warnings-First_Seen"/>
270 <para>A resolved warning cannot be deferred -- either
271 <xref linkend="Integrity_Warnings-Resolved"/> or
272 <xref linkend="Integrity_Warnings-Deferred_To"/>, or both, must
276 <xref linkend="INTEGRITY_WARNINGS"/>.<xref linkend="Integrity_Warnings-Deferred_To"/>
278 <xref linkend="INTEGRITY_WARNINGS"/>.<xref linkend="Integrity_Warnings-Resolved"/>
279 value without raising an error either update both values in
280 the same <code>UPDATE</code> statement or first set the
281 <xref linkend="Integrity_Warnings-Deferred_To"/> value to
283 <xref linkend="Integrity_Warnings-Resolved"/> value to
284 something non-&null;.</para>
287 <para>The warning id generated by the stored query must be
288 unique per query -- the combination of
289 INTEGRITY_WARNINGS.<xref linkend="Integrity_Warnings-IQName"/>
291 INTEGRITY_WARNINGS.<xref linkend="Integrity_Warnings-Warning_Id"/>
292 must be unique.</para>
294 <section xml:id="Integrity_Warnings-IWID" xreflabel="IWID">
295 <title>IWID (Integrity Warning Identifier)</title>
297 <para>An integer uniquely identifying the row containing the
298 result of a database integrity query. The IWID value cannot
302 <section xml:id="Integrity_Warnings-IQName" xreflabel="IQName">
303 <title>IQName (Integrity Query Name)</title>
306 <xref linkend="INTEGRITY_QUERIES"/>.<xref linkend="Integrity_Queries-IQName"/>
307 value identifying the query which produced the result.</para>
310 <section xml:id="Integrity_Warnings-First_Seen" xreflabel="First_Seen">
311 <title>First_Seen</title>
313 <para>Date and time the query result was first
314 produced by the warning sub-system. ¬null;</para>
317 <section xml:id="Integrity_Warnings-Last_Seen" xreflabel="Last_Seen">
318 <title>Last_Seen</title>
320 <para>Date and time the query result was most recently
321 produced by the warning sub-system. ¬null;</para>
324 <section xml:id="Integrity_Warnings-Resolved" xreflabel="Resolved">
325 <title>Resolved (Date and Time Resolved)</title>
327 <para>Date and time the query result was resolved; i.e. marked
328 not a concern. The warning sub-system does not display
329 resolved results, although of course the INTEGRITY_WARNINGS
330 table can always be manually queried.</para>
332 <para>The value of this column is &null; both when the query
333 result is a data integrity error and when it is a data
334 integrity warning that has not yet been resolved.</para>
337 <section xml:id="Integrity_Warnings-Deferred_To" xreflabel="Deferred_To">
338 <title>Deferred_To</title>
340 <para>Date and time before which the warning sub-system will
341 not display the result. Use of this column allows resolution
342 of data integrity problems to be deferred, and hence not
343 clutter up the output of the warning sub-system with noise
344 that might hide other problems.</para>
346 <para>When this column is &null; the warning sub-system will
347 display the query result.</para>
350 <section xml:id="Integrity_Warnings-Category" xreflabel="Category">
351 <title>Category</title>
353 <para>Code classifying the query result. The legal values for
354 this column are defined by the
355 <xref linkend="WARNING_REMARKS"/> support table.</para>
357 <para>This column may be &null; when the query result is
361 <section xml:id="Integrity_Warnings-Warning_Id" xreflabel="Warning_Id">
362 <title>Warning_Id</title>
364 <para>This is a unique, unique per query that is, identifier
365 for the query result. It is
366 the <link linkend="Integrity_Queries-Query-Col1">first
367 column</link> produced by the related
368 <xref linkend="INTEGRITY_QUERIES"/>.<xref linkend="Integrity_Queries-Query"/>.</para>
370 <para>¬null;</para>
372 <para>Once given a value, the content of this column may not
373 be altered except by a username with administrative
377 <section xml:id="Integrity_Warnings-Warning_Message"
378 xreflabel="Warning_Message">
379 <title>Warning_Message</title>
381 <para>This is the message,
382 the <link linkend="Integrity_Queries-Query-Col2">second
383 column</link>, produced by the
384 <xref linkend="INTEGRITY_QUERIES"/>.<xref linkend="Integrity_Queries-Query"/>.</para>
387 <para>Once given a value, the content of this column may not
388 be altered except by a username with administrative
392 <section xml:id="Notes" xreflabel="Notes">
395 <para>Any textual notes regarding this particular query
396 result. This column may be &null; when there are no such
397 notes. &emptytext;</para>
404 <section xml:id="warning_system-Support-Tables">
405 <title>Warning Sub-System Support Tables</title>
407 <section xml:id="IQTYPES" xreflabel="IQTYPES">
408 <title>IQTYPES (Integrity Query Types)</title>
410 <para>IQTYPES contains one row for every code used to classify
411 database integrity queries. Classification may be by the type
412 of data integrity problem the related queries are designed to
413 uncover, by who is responsible for resolving the discovered
414 problems, or any other desired classification scheme.</para>
416 <section xml:id="IQTypes-Key" xreflabel="IQType">
417 <title xml:id="IQTypes-IQType" xreflabel="IQType">Key:
420 <para>The IQTYPES table is keyed by the IQType column. No
421 more than &warn_iqtype_len; characters are allowed in the key.
425 <section xml:id="IQTypes-Special-Values">
426 <title>Special Values</title>
432 <section xml:id="WARNING_REMARKS" xreflabel="WARNING_REMARKS">
433 <title>WARNING_REMARKS (Remarks Regards Warning Results)</title>
435 <para>WARNING_REMARKS contains one row for every code used to
436 classify or explain sets of database integrity problems,
437 problems discovered by the warning sub-system's queries.
438 Codes may be used as needed, whether to organize reported
439 problems pending resolution, to describe the circumstances
440 which resolve an issue, or to serve other purposes.</para>
442 <section xml:id="Warning_Remarks-Key" xreflabel="WRID">
443 <title xml:id="Warning_Remarks-WRID" xreflabel="WRID">Key:
446 <para>The WARNING_REMARKS table is keyed by the WRID column. No
447 more than &warn_wrid_len; characters are allowed in the key.
451 <section xml:id="Warning_Remarks-Special-Values">
452 <title>Special Values</title>
459 <section xml:id="warning_system-The-Warning-Sub-System-Functions"
460 xreflabel="The Warning Sub-System Functions">
461 <title>The Warning Sub-System Functions (Activating The Warning
464 <para>The warning sub-system is activated by using one of it's
465 functions. Of course the <xref linkend="INTEGRITY_WARNINGS"/>
466 table may always be queried manually, but this does not discover
467 any new problems.</para>
469 <para>All of the warning sub-system functions are designed to be
470 used in the <code>FROM</code> clause of <code>SELECT</code>
471 statements, as if they were tables. Indeed the functions look
472 like tables to the <code>SELECT</code> statement, tables that look
473 exactly like <xref linkend="INTEGRITY_WARNINGS"/> -- except that
474 the <xref linkend="Integrity_Warnings-Resolved"/> and
475 <xref linkend="Integrity_Warnings-Deferred_To"/> columns are
476 missing. The difference between querying on the
477 <xref linkend="INTEGRITY_WARNINGS"/> table directly and querying
478 using the warning sub-system's functions is that the functions
479 update the content of the <xref linkend="INTEGRITY_WARNINGS"/>
480 table by executing the the queries in
481 <xref linkend="INTEGRITY_QUERIES"/> table. Also, the functions
482 never return rows where the underlying
483 <xref linkend="INTEGRITY_WARNINGS"/> row has a non-&null;
484 <xref linkend="Integrity_Warnings-Resolved"/> value or a
485 <xref linkend="Integrity_Warnings-Deferred_To"/> time and date
486 that has not yet been reached.</para>
488 <para>All timestamps, date plus time values, which the warning
489 sub-system updates in the <xref linkend="INTEGRITY_QUERIES"/> and
490 <xref linkend="INTEGRITY_WARNINGS"/> tables are set to the date
491 and time at which program execution started. So when, say,
492 <xref linkend="run_integrity_queries"/>, is run, all of the new
493 timestamp values in the <xref linkend="INTEGRITY_QUERIES"/> and
494 <xref linkend="INTEGRITY_WARNINGS"/> rows touched by the execution
495 are identical.</para>
497 <para>Various warning sub-system functions (or versions of the
498 same function) are supplied to allow easy selection of which
499 queries in which <xref linkend="INTEGRITY_QUERIES"/> rows are to
500 be executed, whether all or only some.</para>
503 <para>As with a regular table, the order in which rows are
504 returned by the warning sub-system's functions is indeterminate.
505 If you wish to ensure a specific ordering an <code>ORDER
506 BY</code> clause must be used.</para>
509 <refentry xml:id="run_integrity_queries"
510 xreflabel="run_integrity_queries()">
512 <refentrytitle>run_integrity_queries</refentrytitle>
516 <refname>run_integrity_queries</refname>
517 <refpurpose>execute one or more of the queries stored in the
518 INTEGRITY_QUERIES table</refpurpose>
525 <type>TABLE (iwid, iqname, first_seen, last_seen, category,
526 warning_id, warning_message, notes)</type>
527 <function>run_integrity_queries</function>
533 <type>TABLE (iwid, iqname, first_seen, last_seen, category,
534 warning_id, warning_message, notes)</type>
535 <function>run_integrity_queries</function>
539 <parameter>iq_query</parameter>
545 <refsection xml:id="run_integrity_queries_input">
547 <refsection xml:id="run_integrity_queries_iq_query">
548 <title>iq_query</title>
550 <para>The text of an SQL query. The query must return a
552 <xref linkend="INTEGRITY_QUERIES"/>.<xref linkend="Integrity_Queries-IQName"/>
557 <refsection xml:id="run_integrity_queries_description">
558 <title>Description</title>
560 <para>A function which runs the queries stored in the
561 <xref linkend="INTEGRITY_QUERIES"/> table, returns the output
562 of the stored queries, and stores the results in the
563 <xref linkend="INTEGRITY_WARNINGS"/> table. Because the
564 function returns rows and columns it must be invoked in
565 the <code>FROM</code> clause of a <code>SELECT</code>
567 <link linkend="run_integrity_queries-Examples">Examples</link>
570 <para>The function may be called in one of two ways. When
571 called with no arguments all of the queries in
572 <xref linkend="INTEGRITY_QUERIES"/> are run. When called with
573 the text of an SQL query, a query which returns a single
575 <xref linkend="INTEGRITY_QUERIES"/>.<xref linkend="Integrity_Queries-IQName"/>
576 values, the function runs only those queries.</para>
579 <para>Use &postgresql;'s &dollar_quoting; when supplying a
580 query to <code>run_integrity_queries()</code>.</para>
583 <para>The function returns a set of columns with multiple
584 rows, a table. So it must be used in the <code>FROM</code>
585 clause of a <code>SELECT</code> statement. The columns
586 returned by the function are the columns of the
587 <xref linkend="INTEGRITY_WARNINGS"/> table, excepting the
588 <xref linkend="Integrity_Warnings-Resolved"/> column and the
589 <xref linkend="Integrity_Warnings-Deferred_To"/>
592 <para>The rows returned by the function are those of the newly
593 updated <xref linkend="INTEGRITY_WARNINGS"/> table, excepting
594 those rows with a non-&null;
595 <xref linkend="Integrity_Warnings-Resolved"/> column or those
596 rows with a <xref linkend="Integrity_Warnings-Deferred_To"/>
597 value that is in the future. Only those rows that are related
598 to the executed queries (in
599 <xref linkend="INTEGRITY_QUERIES"/>) are returned. So, when
600 called with no arguments the function returns all warnings
601 that have not been resolved and all errors. When called with
602 a query that selects specific
603 <xref linkend="INTEGRITY_QUERIES"/> to execute, only the
604 unresolved warnings and errors discovered by the executed
605 <xref linkend="INTEGRITY_QUERIES"/> are returned.</para>
608 <xref linkend="INTEGRITY_QUERIES"/>.<xref linkend="Integrity_Queries-Query"/>
609 does more than add new rows to the
610 <xref linkend="INTEGRITY_WARNINGS"/> table. The
611 <xref linkend="INTEGRITY_QUERIES"/>.<xref linkend="Integrity_Queries-Last_Run"/>
612 column is updated with a new timestamp as is the
613 <xref linkend="INTEGRITY_WARNINGS"/>.<xref linkend="Integrity_Warnings-Last_Seen"/>
614 value of all <xref linkend="INTEGRITY_WARNINGS"/> rows with
615 <xref linkend="Integrity_Warnings-IQName"/> values matching
616 that of the executed query where the
617 <xref linkend="Integrity_Warnings-Warning_Id"/> value matches
618 the value returned in the first column of the executed
621 <para>Further, if an existing
622 <xref linkend="INTEGRITY_WARNINGS"/> row matches the
623 <xref linkend="Integrity_Queries-IQName"/> value of the
624 executed query but there is no corresponding
625 <xref linkend="Integrity_Warnings-Warning_Id"/> value returned
626 by the executed query then the
627 <xref linkend="INTEGRITY_WARNINGS"/> row is deleted. This
628 empties the <xref linkend="INTEGRITY_WARNINGS"/> table of
629 errors and warnings that no longer apply to the current state
630 of the database. This happens to warnings regardless of
631 whether or not the warning is resolved.</para>
634 <para>If significant research has gone into the resolution
635 of a warning condition that is expected, for whatever
636 reason, to be absent from the database and then re-appear
637 then care should be taken to record this research somewhere
638 other than in the <xref linkend="INTEGRITY_WARNINGS"/>
639 table. The row corresponding to the warning condition in
640 <xref linkend="INTEGRITY_WARNINGS"/> may be automatically
641 deleted by the warning sub-system when the warning condition
642 is temporarily absent from the database content.</para>
647 <refsection xml:id="run_integrity_queries-Examples">
648 <title>Examples</title>
650 <para>The following example runs all the queries in
651 <xref linkend="INTEGRITY_QUERIES"/>, displays all the errors
652 and all the unresolved warnings (unless the error or warning
653 has been deferred), ordered first by the name of the query,
654 within that showing newer problems first, and within that
655 ordered by warning id.</para>
657 <example xml:id="run_integrity_queries-all_queries">
658 <title>Executing all INTEGRITY_QUERIES</title>
660 <literallayout><code>SELECT *
661 FROM run_integrity_queries() AS problems
662 ORDER BY problems.iqname
663 , problems.first_seen desc
664 , problems.warning_id;</code>
668 <para>The following example runs a single saved query with an
669 <xref linkend="INTEGRITY_QUERIES"/>.<xref linkend="Integrity_Queries-IQName"/>
670 of <literal>mycheck</literal> and displays any of these sorts
671 of problems found, ordered as in the previous example. This
672 example also demonstrates how to use &dollar_quoting; to give
673 a query to <code>run_integrity_queries</code> and thereby
674 avoid problems having to do with trying to nest regular
677 <example xml:id="run_integrity_query-onequery">
678 <title>Executing a single INTEGRITY_QUERIES.Query</title>
680 <literallayout><code>SELECT *
681 FROM run_integrity_queries($$SELECT 'mycheck'$$) AS problems
682 ORDER BY problems.iqname
683 , problems.first_seen desc
684 , problems.warning_id;</code>
688 <para>The following example runs all the queries of
689 the <literal>bdate</literal> type and displays any of these
690 sorts of problems found, ordered as in the previous example.
691 This example also demonstrates how to use &dollar_quoting; to
692 give a query to <code>run_integrity_queries</code> and thereby
693 avoid problems having to do with trying to nest regular
696 <example xml:id="run_integrity_query-birthdate">
697 <title>Executing INTEGRITY_QUERIES of
698 the <quote>bdate</quote> type</title>
700 <literallayout><code>SELECT *
701 FROM run_integrity_queries(
702 $$SELECT integrity_queries.iqname
703 FROM integrity_queries
704 WHERE integrity_queries.type = 'bdate'$$
706 ORDER BY problems.iqname
707 , problems.first_seen desc
708 , problems.warning_id;</code>