Conversation
josh-heyer
left a comment
josh-heyer
left a comment
There was a problem hiding this comment.
Left a few notes inline - I'm gonna stop at this point because there are a couple real show-stoppers; this won't build if imported today, and even if it did the content is gonna be corrupt in a pretty big pile of places.
Best if this bakes a bit more, IMHO.
| | `MEDIAN (`*expr*`)` | `timestamp, timestamptz, interval, float` | `MEDIAN (`*expression*`)`<br><br>*Example:*<br><br>`SELECT department_id, MEDIAN(salary) `<br>`FROM employees `<br>`GROUP BY department_id;` | Can take a two-dimensional array as input. Treats such arrays as matrices. | | ||
| | `PERCENTILE_CONT (`*expr*`) WITHIN GROUP (ORDER BY `*expr*` [DESC/ASC])` | `timestamp, timestamptz, interval, float` | `PERCENTILE_CONT(`*percentage*`) WITHIN GROUP (ORDER BY `*expression*`)`<br><br>*Example:*<br><br>`SELECT department_id,`<br>`PERCENTILE_CONT (0.5) WITHIN GROUP (ORDER BY salary DESC)`<br>`"Median_cont"; `<br>`FROM employees GROUP BY department_id;` | Performs an inverse distribution function that assumes a continuous distribution model. It takes a percentile value and a sort specification and returns the same datatype as the numeric datatype of the argument. This returned value is a computed result after performing linear interpolation. Null are ignored in this calculation. | | ||
| | `PERCENTILE_DISC (`*expr*`) WITHIN GROUP (ORDER BY `*expr*` [DESC/ASC])` | `timestamp, timestamptz, interval, float` | `PERCENTILE_DISC(`*percentage*`) WITHIN GROUP (ORDER BY `*expression*`)`<br><br>*Example:*<br><br>`SELECT department_id, `<br>`PERCENTILE_DISC (0.5) WITHIN GROUP (ORDER BY salary DESC)`<br>`"Median_desc"; `<br>`FROM employees GROUP BY department_id;` | Performs an inverse distribution function that assumes a discrete distribution model. It takes a percentile value and a sort specification. This returned value is an element from the set. Null are ignored in this calculation. | | ||
| | `sum(array[])` | `smallint[]int[], bigint[], float[]` | `sum(array[[1,2],[3,4]])`<br><br>*Example:*<br><br>`CREATE TABLE mymatrix (myvalue int[]);`<br>`INSERT INTO mymatrix VALUES (array[[1,2],[3,4]]);`<br>`INSERT INTO mymatrix VALUES (array[[0,1],[1,0]]);`<br>`SELECT sum(myvalue) FROM mymatrix;`<br>`sum `<br>`---------------`<br>`{{1,3},{4,4}}` | Performs matrix summation. Can take as input a two-dimensional array that is treated as a matrix. | |
There was a problem hiding this comment.
This is corrupt in a couple of ways:
- The big one is that
{{1,3},{4,4}}contains entities that are interpreted in HTML as left-hand curly braces. Since this is now inline code, HTML isn't allowed (nor is it needed - these were escaped to avoid build errors as curly braces in MDX demarcate expressions). The phrase should read,{{1,3},{4,4}} - Smaller, but somewhat annoying: this code block was written as it was to preserve whitespace - it's showing output from an SQL expression as it might render in psql, which displays it as an ASCII table. That doesn't really work very well with inline code separated by
<br/>elements - it's readable, but without whitespace the table layout kinda just becomes a mess.
Recommendation 1: do a pass on the entities (this affects all versions of this file, and several other files e.g. functions-operators.md, json-data.md). Entities should be preserved when used outside code. Entities that end up inside code should be converted to their corresponding character.
Recommendation 2: if we're gonna rewrite this whole table, maybe consider making it... Not a table. This is a whole damn reference section - it could have a table of contents all its own, and that could be in a table... But at the point where you have code blocks, maybe a table isn't really the right choice. Sections & subsections & so on are really nice for this. I know, I know, the PostgreSQL docs use tables - but they're like 2 columns, or in an especially relevant example ONE column - IOW, they're not trying to shoehorn an example into column 3 of a 4 column table (and even so, the result looks kinda dumb IMHO).
2 participants
so they can render properly on the EDB site