Re: Range type bounds

On Wednesday, November 26, 2014, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 11/26/2014 12:34 PM, David Johnston wrote:
>
>>
>> I guess what is confusing to me is the transition between the text
>> mode and the constructor mode is not clear. In particular the page
>> starts with examples using the constructor mode but then goes to
>> explanations that actually apply to the text mode before getting
>> back to explaining the constructor mode.
>>
>>
>> They are contained in separate subsections of the documentation...the
>> syntax described in each section only applies to that section. The
>> concept of empty doesn't apply to constructor functions at all.
>>
>
> You get that from this?:
>
> "
>
> 8.17.2. Examples
>
>
Examples do not constitute syntax specifications so while this useful for
understanding it is not enough to generalize from.

> Every non-empty range has two bounds, the lower bound and the upper bound.
> All points between these values are included in the range. An inclusive
> bound means that the boundary point itself is included in the range as
> well, while an exclusive bound means that the boundary point is not
> included in the range.

Use of empty as a value.

>
> The lower bound of a range can be omitted,

Omit is the best concept - implemented by a lack of value in a literal or a
null in a function call.

It gets to be very verbose if we try to anticipate cross-language
>> differences and preemptively explain them away...
>>
>
> Agreed. My example was as a counterpoint to your statement:
>
> "All that said it is taken for granted that you cannot have an empty
> function argument so ('val',) is invalid on its face."
>
> It is not invalid on its face, just for this use case.

Less a use case than a language/system. I do not recall any case where you
can call a function defined in PostgreSQL and leave an argument position
defined but empty. You can skip providing the given position and use
defaults but dangling commas are not allowed. That is taken for granted by
the people writing documentation.

> I am not saying explain all the exceptions, just the rule. In other words
> for the purpose of this function at least two arguments must be provided. I
> realize it does get covered in 8.17.6., but that is after the section I
> quoted at the top which would seem to imply different. Have spent too much
> time on this already, time to actually implement the suggestions:)
>
>
Yes, examples before definition is not all the common in the docs...

David J.