Jeff Davis <pgsql@j-davis.com> writes:
> 2. We need to use the subtype's IO functions, but those may not be
> immutable. So, rather than create new IO functions for each range type,
> I was thinking that I'd use just three (anyrange_i_in, anyrange_s_in,
> and anyrange_v_in), and select the right one at definition time, based
> on the subtype's IO functions' volatility. That seems like a bit of a
> hack -- any better ideas?
You should just do what we do for arrays and records, ie, mark the I/O
functions stable. There is no reason for anyrange to have a more
complicated approach to this than the existing composite-type structures
do. See discussion thread here
http://archives.postgresql.org/pgsql-hackers/2010-07/msg00932.php
and commit here
http://archives.postgresql.org/pgsql-committers/2010-07/msg00307.php
> 3. Right now I allow user-defined parse/deparse functions to be
> specified. In almost all cases, I would think that we want the text
> format to be something like:
> [ 2010-01-01, 2011-01-01 )
> where the brackets denote inclusivity, and the left and right sides can
> be optionally double-quoted. Is it even worth having these parse/deparse
> functions, or should we just force the "obvious" format?
+1 for forcing a single consistent format. I compare this to the
Berkeley-era decision to let types specify nondefault array delimiters
--- that was flexibility that didn't help anybody, just resulted in
over-complicated code (or code that would fall over if someone tried
to actually use a delimiter other than comma...)
regards, tom lane
