Re: Table 9.46. UUID Extraction Functions - Mailing list pgsql-docs

From Laurenz Albe
Subject Re: Table 9.46. UUID Extraction Functions
Date
Msg-id d16be0c5e1f60366dfdc181b0ebd5cf2d213ecf7.camel@cybertec.at
Whole thread
In response to Re: Table 9.46. UUID Extraction Functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Table 9.46. UUID Extraction Functions
List pgsql-docs
On Thu, 2026-10-08 at 23:32 -0400, Tom Lane wrote:
> Laurenz Albe <laurenz.albe@cybertec.at> writes:
> > On Thu, 2026-10-08 at 12:41 -0400, Tom Lane wrote:
> > > Not in the least.  Those, and every other &zwsp; in the SGML docs,
> > > are there so that the PDF version renders without complaints about
> > > overlength lines.
>
> I still wonder whether there's another solution path though.
> We settled on &zwsp; because it fixed the major issue here,
> but that doesn't mean there isn't a better answer.

The funny thing is that the line in question is not broken in the
PDF output that was generated here:

  uuid_extract_version('41db1265-8bc1-4ab3-992f-885799a4af1d'::uuid)
  →4
  uuid_extract_version('019535d9-3df7-79fb-b466-fa907fa17f9e'::uuid)
  →7

But elsewhere I see a break:

  uuid_extract_timestamp('019535d9-3df7-79fb-b466-
  fa907fa17f9e'::uuid) → 2025-02-23 21:46:24.503-05

I think that an improved version could look as follows:

  uuid_extract_timestamp(
     '019535d9-3df7-79fb-b466-fa907fa17f9e'::uuid
  ) → 2025-02-23 21:46:24.503-05

Also, not everything (query results etc.) are likely to be copied and
pasted by users.  So I guess the way forward would be for me to spend
some time with this.  But then - is it *that* important?

Yours,
Laurenz Albe



pgsql-docs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Table 9.46. UUID Extraction Functions
Next
From: Tom Lane
Date:
Subject: Re: Table 9.46. UUID Extraction Functions