Add documentation for the LPAD and RPAD OQL functions#11190
Conversation
|
Awaiting 11.11 release. |
Just FYI, this still requires approval from the team and for the implementation story to be finalised. |
|
Got it, will wait for the go ahead. |
…e pad_expression multi-character alert
passalaqua
force-pushed
the
dat/feature/pad-functions
branch
from
5bc8c1d to
a196c91
Compare
|
Approved by team for technical review |
MarkvanMents
left a comment
MarkvanMents
left a comment
There was a problem hiding this comment.
Thanks for the PR. I have a few questions:
|
|
||
| #### expression | ||
|
|
||
| `expression` specifies the expression of type `string` to pad. |
There was a problem hiding this comment.
Any special behavior for NULL? For Trim it returns NULL but does this just return a whole load of pad_expression?
There was a problem hiding this comment.
They just return null if either the expression or length are null. If the padding pattern is null, it is usually null (HSQLDB is the exception and throws an error).
And if expression is the empty string or the length is zero, then Oracle returns null, but other databases return the empty string.
And if the padding pattern is the empty string, then Oracle and MariaDB return null, HSQLDB uses the space character, MySQL returns the empty string, and other databases return the original string. It's kind of a mess and I suppose those are cases where things can be described as "it's database dependent", so I didn't add to this page.
| `length_expression` specifies the length of the resulting string. The expression must be of type `integer` or `long` | ||
|
|
||
| {{% alert color="info" %}} | ||
| If `length_expression` is smaller than the length of `expression`, this function truncates it. This behavior is database specific. |
There was a problem hiding this comment.
Truncates the right side, even though we are doing LPAD?
There was a problem hiding this comment.
Weirdly, yes. We were just as confused when implementing. The only exception is HSQLDB, which does the right thing, but possibly by accident given how special it is.
| ```sql | ||
| SELECT LPAD('hello', 10, 'x') AS padded FROM Sales.Order | ||
| ``` | ||
|
|
||
| | padded | | ||
| |:-----------| | ||
| | xxxxxhello | | ||
|
|
There was a problem hiding this comment.
Is it worth an example with a string pad_expression?
SELECT LPAD('hello', 10, 'abc') AS padded FROM Sales.OrderThere was a problem hiding this comment.
Probably a good idea. I can write it as part of the same query (shorter page) or as a separate example (clearer). Which one do you prefer?
| `length_expression` specifies the length of the resulting string. The expression must be of type `integer` or `long` | ||
|
|
||
| {{% alert color="info" %}} | ||
| If `length_expression` is smaller than the length of `expression`, this function truncates it. |
There was a problem hiding this comment.
Still normal truncation - so the same as LPAD?
| | 0.33 | 3.33333333 | | ||
| | 1.17 | 1.17142857 | | ||
|
|
||
| ### RPAD {#rpad-function} |
There was a problem hiding this comment.
Same comments as for LPAD
| | padded | | ||
| |:-----------| | ||
| | hello | |
There was a problem hiding this comment.
This looks wrong when built. May have to think around this ( would work - but still difficult to see that it is space padded rather than right justified)
)
There was a problem hiding this comment.
I suppose we can change the query to
SELECT '|' + LPAD('hello', 10) + '|' AS padded FROM Sales.Order
The resulting string would be | hello|. Would we render it correctly with spaces?
There was a problem hiding this comment.
We could also just render the result as
·····hello
Or something similar and indicate · represents a whitespace.
4 participants
Should be added in 11.11.0Changed to 11.12.0 in a196c91