Re: Second-granular timezone offset format not documented
On Tue, Jul 6, 2021 at 2:04 AM Tom Lane wrote: > I tried to interest them in dropping the LMT idea altogether [1]. FWIW, I agree with you. It's meaningless because those coordinates don't seem to be the meridians historically used for local mean time (Trafalgar Square may be the prime meridian for pigeons, but real London time was based on its most famous observatory long before standardisation AFAICS, and if even that "zero case" is wrong, I guess the rest are wrong too where there even is an answer; the year given is also disputable). That's all fine and well given the disclaimer that it's meaningless, but then why even have it? The LMT concept is itself being applied proleptically (before the definition of mean time, before the existence of the named cities, ...). I think it would be a whole lot more useful and less surprising to make standard time proleptic instead, or just reject undefined conversions.
Re: conventions
On Wed, Jul 7, 2021, at 1:30 PM, rir wrote: > > The conventions page is weak. Here is a proposed start for > change. Seeing SQL as an early language, I have tried to use something > like plain English. Here "early" could describe a mail merge user > wandering into programming SQL after seeing some simple examples. Hi Rob, Unless someone translates your suggestion into a patch, you could probably do it and submit a patch. If you are a first time contributor, I suggest that you read Submitting a patch [1]. It is a detailed document that describes the development workflow. Talking about this patch, edit doc/src/sgml/notation.sgml, run configure script, follow the steps described in Building the Documentation section [2] and send a 'git diff' to this list. You might need some tools [3] to build the documentation. [1] https://wiki.postgresql.org/wiki/Submitting_a_Patch [2] https://www.postgresql.org/docs/current/docguide-build.html [3] https://www.postgresql.org/docs/current/docguide-toolsets.html -- Euler Taveira EDB https://www.enterprisedb.com/
conventions
The conventions page is weak. Here is a proposed start for change. Seeing SQL as an early language, I have tried to use something like plain English. Here "early" could describe a mail merge user wandering into programming SQL after seeing some simple examples. I like the idea of accessibility but I may have been overly influenced by the tone of the existing page. I tried to express the idea of operators and that "repeaters" could/should be viewed as tokens. I am not sure if parenthetical groups are degenerate in their behavior pertaining to their contents. It seems they take the op's on the outside. Thanks, rob Conventions The conventions used in the synopses of commands vary with the language being presented. SQL The conventions for SQL synopses consist of placeholders, groups, repeaters and the alternator. Placeholders are bold, italicized names for SQL code. Often the placeholder's definition or syntax is is introduced and presented later in the synopsis. When not defined, there are three possible reasons: 1. The placeholder is self-evident, i.e. "name" being more helpful in giving the intent of the code than "sql_identifier". 2. The placeholder is a common SQL construct explained elsewhere, i.e. "expression". 3. The placeholder is arcane or requires knowledge beyond SQL; the commonest cases involve creating or altering C language code. In the above cases, the page's explanatory text should help. Square brackets ([ and ]) create optional groups. Pointy braces ({ and }) create required groups. To date, only alternative lists exist inside braces. Parentheses (( and )) are to be taken literally as part of the SQL code, but also group parts. The bar or pipe (|) is the alternator, it separates lists of alternatives which require one choice. The ellipsis (...) is the basic repeater, all repeaters indicate some repetition of the prior group, symbol or word. The basic repeater requires at least one repetition. The ellipsis in square brackets ([ ... ]) indicates an optional repetition. The other repeaters are special usages of square brackets to create repeaters that contain a separator that goes between the repetitions. These are ([, ...]), ([ OR ...]) and ([ AND ...]). PL/pgSQL XXX See SQL above. PL/Tcl ... PL/Perl ... PL/Python ...
Re: markdown error
> On 7 Jul 2021, at 09:17, PG Doc comments form wrote: > Tables for operators and functions in version 13 and devel 14 are broken These tables were deliberately changed to this format to allow for wide content. -- Daniel Gustafsson https://vmware.com/
markdown error
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/functions-json.html Description: Tables for operators and functions in version 13 and devel 14 are broken https://www.postgresql.org/docs/current/functions-json.html