Tom Lane b7103bbe34 Avoid direct C access to possibly-null pg_subscription_rel.srsublsn.
This coding technique is unsafe, since we'd be accessing off the end
of the tuple if the field is null.  SIGSEGV is pretty improbable, but
perhaps not impossible.  Also, returning garbage for the LSN doesn't
seem like a great idea, even if callers aren't looking at it today.

Also update docs to point out explicitly that
pg_subscription.subslotname and pg_subscription_rel.srsublsn
can be null.

Perhaps we should mark these two fields BKI_FORCE_NULL, so that
they'd be correctly labeled in databases that are initdb'd in the
future.  But we can't force that for existing databases, and on
balance it's not too clear that having a mix of different catalog
contents in the field would be wise.

Apply to v10 (where this code came in) through v12.  Already
fixed in v13 and HEAD.

Discussion: https://postgr.es/m/732838.1595278439@sss.pgh.pa.us
2020-07-21 11:40:46 -04:00
..
2019-09-08 10:27:16 +02:00
2019-09-08 10:27:16 +02:00
2019-09-08 10:27:16 +02:00
2020-07-18 22:43:45 +09:00
2019-09-06 22:17:58 +02:00
2020-02-10 08:43:52 +05:30
2017-10-20 19:26:10 -04:00
2019-07-05 08:33:51 +02:00
2019-09-13 17:22:49 +03:00
2020-07-18 22:43:45 +09:00
2018-10-11 11:43:56 -07:00
2020-07-18 22:43:45 +09:00
2019-09-08 10:27:16 +02:00
2020-07-18 22:43:45 +09:00
2018-06-20 16:06:03 +02:00
2019-09-08 10:27:16 +02:00
2020-06-07 13:19:25 +02:00
2019-06-09 11:25:56 +09:00
2017-10-17 15:10:33 -04:00
2017-10-17 15:10:33 -04:00
2020-07-18 22:43:45 +09:00
2018-07-16 10:48:05 +02:00
2019-04-03 17:40:29 -07:00
2017-10-17 15:10:33 -04:00
2017-10-17 15:10:33 -04:00
2020-07-18 22:43:45 +09:00
2020-07-18 22:43:45 +09:00
2019-09-08 10:27:16 +02:00
2020-01-01 12:21:45 -05:00
2019-09-08 10:27:16 +02:00
2019-09-08 10:27:16 +02:00
2020-06-15 13:13:11 +12:00
2020-07-18 22:43:45 +09:00
2017-10-17 15:10:33 -04:00
2018-08-28 21:33:32 +09:00
2019-09-08 10:27:16 +02:00
2017-10-17 15:10:33 -04:00
2019-09-08 10:27:16 +02:00
2019-09-08 10:27:16 +02:00
2020-07-18 22:43:45 +09:00
2020-07-18 22:43:45 +09:00
2019-04-03 17:40:29 -07:00
2019-08-20 13:45:53 +09:00
2020-04-11 08:11:06 +01:00
2019-03-29 13:36:24 +01:00
2020-07-18 22:43:45 +09:00
2019-09-08 10:27:16 +02:00
2019-08-20 13:45:53 +09:00
2017-08-15 14:37:44 -04:00
2019-03-27 23:10:23 +01:00
2019-03-27 23:10:23 +01:00
2019-09-08 10:27:16 +02:00
2019-09-08 10:27:16 +02:00
2019-09-08 10:27:16 +02:00
2019-09-08 10:27:16 +02:00
2019-08-20 13:45:53 +09:00
2019-09-08 10:27:16 +02:00

<!-- doc/src/sgml/README.links -->

Linking within DocBook documents can be confusing, so here is a summary:


Intra-document Linking
----------------------

<xref>
	use to get chapter/section number from the title of the target
	link, or xreflabel if defined at the target, or refentrytitle if target
        is a refentry;  has no close tag
	http://www.oasis-open.org/docbook/documentation/reference/html/xref.html

<link>
	use to supply text for the link, requires </link>
	http://www.oasis-open.org/docbook/documentation/reference/html/link.html

linkend=
	controls the target of the link/xref, required

endterm=
	for <xref>, allows the text of the link/xref to be taken from a
	different link target title


External Linking
----------------

<ulink>
	like <link>, but uses a URL (not a document target);  requires
	</ulink>; if no text is specified, the URL appears as the link
	text
	http://www.oasis-open.org/docbook/documentation/reference/html/ulink.html

url=
	used by <ulink> to specify the URL, required


Guidelines
----------

- For an internal link, if you want to supply text, use <link>, else
  <xref>.

- Specific nouns like GUC variables, SQL commands, and contrib modules
  usually have xreflabels.

- For an external link, use <ulink>, with or without link text.