RE: New "function tables" in V13 documentation

From: Kevin Brannen <KBrannen(at)efji(dot)com>
To: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: RE: New "function tables" in V13 documentation
Date: 2020-11-13 21:57:36
Message-ID: BN7PR19MB2338AB4C270101500C594755A4E60@BN7PR19MB2338.namprd19.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>From: David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>

>>On Fri, Nov 13, 2020 at 12:20 PM Kevin Brannen <mailto:KBrannen(at)efji(dot)com> wrote:

>>Designing pages to the smallest media just frustrates those users on larger media (cue the many examples on the web where the left/right margins are so wide half of your screen is wasted instead of letting the text flow and resize).]

>It is just as bad it is so wide that one has to move their head instead of just moving their eyes. If anything our tables could probably be improved by enforcing a maximum width to the content area.

True on moving heads is harder, but we have the option of making the browser narrower to compensate

if we feel the need. When there are max width constraints then the option to customize is taken out

of the user's hands and that's an issue. Let the user do what works best for them. Some flexibility

doesn't seem like to much to ask for...IMO.

I really don't expect the old tables to come back, as much as I'd like that, because groups rarely backtrack

or so my experience has been. However, this is also why I made the suggestions I did, especially the

last one about adding more CSS classes to let the users restyle if they feel strongly enough about it.

Maybe this works for most people:

upper ( text ) → text

Converts the string to all upper case, according to the rules of the database's locale.

upper('tom') → TOM

By why not let people do:

upper ( text ) → text

Converts the string to all upper case, according to the rules of the database's locale.

upper('tom') → TOM

[For those that don’t receive HTML in email, the function is bold, the return type is underlined,

the example has a light gray background, and the example result has a light blue background.]

I don’t know that I’d really do it that way, but the CSS required for that isn’t hard yet it makes

the parts stand out a lot better so I know what is what. The current docs are only missing 3 CSS

classes to allow me to do that: the description, the example code, and the example return (since it

uses the same class as the function return value). I can’t imagine that would be so hard to do.

I don’t see myself contributing to the Pg code base, but this is something I might could do and

should look into.

Kevin

This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, distribution, review, copy or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify us by reply e-mail, and destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Devrim Gündüz 2020-11-13 22:43:05 Re: Issue upgrading from 9.5 to 13 with pg_upgrade: "connection to database failed: FATAL: database "template1" does not exist"
Previous Message Atul Kumar 2020-11-13 21:33:47 checkpoint occurs too frequently