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
CREATE TABLE reservation (room int, during tsrange);
INSERT INTO reservation VALUES
(1108, '[2010-01-01 14:30, 2010-01-01 15:30)');
-- Containment
SELECT int4range(10, 20) @> 3;
-- Overlaps
SELECT numrange(11.1, 22.2) && numrange(20.0, 30.0);
-- Extract the upper bound
SELECT upper(int8range(15, 25));
-- Compute the intersection
SELECT int4range(10, 20) * int4range(15, 25);
-- Is the range empty?
SELECT isempty(numrange(1, 5));
See Table 9-44 and Table 9-45 for complete lists of operators and
functions on range types.
8.17.3. Inclusive and Exclusive Bounds
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.
In the text form of a range, an inclusive lower bound is represented by
"[" while an exclusive lower bound is represented by "(". Likewise, an
inclusive upper bound is represented by "]", while an exclusive upper
bound is represented by ")". (See Section 8.17.5 for more details.)
The functions lower_inc and upper_inc test the inclusivity of the lower
and upper bounds of a range value, respectively.
8.17.4. Infinite (Unbounded) Ranges
The lower bound of a range can be omitted, meaning that all points less
than the upper bound are included in the range. Likewise, if the upper
bound of the range is omitted, then all points greater than the lower
bound are included in the range. If both lower and upper bounds are
omitted, all values of the element type are considered to be in the range.
This is equivalent to considering that the lower bound is "minus
infinity", or the upper bound is "plus infinity", respectively. But note
that these infinite values are never values of the range's element type,
and can never be part of the range. (So there is no such thing as an
inclusive infinite bound — if you try to write one, it will
automatically be converted to an exclusive bound.)
"
The part that is problematic is the overloaded use of empty to mean a
range without bounds (a value) and a means to specify an infinite bound
(an input). Using "omitted" for the input case would probably add clarity.
I eventually figured it out. I just thought it might make it easier
for others to make the distinction clearer.
Suggestions welcomed
Understood. Will see what I can come up with.
All that said it is taken for granted that you cannot have an
empty function
argument so ('val',) is invalid on its face. The question
becomes whether
you should use ('val','') or ('val',NULL). The only place that
is answered
is a single example. It should be in the body of the text too.
Well I spend my time in Python for the most part so:
def test_fnc(a, b=None):
print a, b
In [12]: test_fnc('a',)
a None
I will have to plead ignorance on C.
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. 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:)
David J.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
