Re: Range type bounds

From: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Range type bounds
Date: 2014-11-26 19:07:01
Message-ID: 1417028821996-5828402.post@n5.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Adrian Klaver-4 wrote
> I will leave it to philosophers to decide whether NULL is empty, but it
> seems the documentation could be more explicit on what constitutes empty
> in the text versus constructor method of creating a range.

Would it be sufficient to simply add another paragraph:

"The lower-bound may be either a string that is valid input for the subtype,
or NULL to indicate no lower bound. Likewise, upper-bound may be either a
string that is valid input for the subtype, or NULL to indicate no upper
bound."

?

@ 8.17.6. Constructing Ranges

I'm not particularly enamored with the title since "Range Input" is a means
of "Constructing [a] Range"...incorporating the word function into that
would seem warranted.

How about: 8.17.6 Functional Range Construction ?

For 8.17.5 The concept of "Input/Output" implies that we are dealing with
string-like literals and while not something an absolute beginner might pick
up on is likely sufficient and thus omitting the word "Literal" is OK by me.

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.

David J.

--
View this message in context: http://postgresql.nabble.com/Range-type-bounds-tp5828396p5828402.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Greg Spiegelberg 2014-11-26 19:19:37 Re: Active/Active clustering in postgres
Previous Message Dev Kumkar 2014-11-26 18:57:42 Re: Lock Management: Waiting on locks