Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers