Re: Range Types - typo + NULL string constructor
От | Jeff Davis |
---|---|
Тема | Re: Range Types - typo + NULL string constructor |
Дата | |
Msg-id | 1317535923.1724.19.camel@jdavis обсуждение исходный текст |
Ответ на | Re: Range Types - typo + NULL string constructor (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Range Types - typo + NULL string constructor
|
Список | pgsql-hackers |
On Wed, 2011-09-21 at 10:41 -0400, Tom Lane wrote: > Florian Pflug <fgp@phlo.org> writes: > > On Sep21, 2011, at 14:00 , Robert Haas wrote: > >> Otherwise, anyone > >> who wants to construct these strings programatically is going to need > >> to escape everything and always write ("cat","dog") or however you do > >> that, and that seems like an unnecessary imposition. > > > Unless you fully depart from what arrays you, you'll have to do that anyway > > because leading and trailing spaces aren't considered to be significant in > > non-quoted elements. In other words, '( cat , dog )' represents > > textrange('cat', 'dog', '()'), *not* textrange(' cat ', ' dog ', '()'). > > Keep in mind that the array I/O behavior is widely considered to suck. > When we defined the record I/O behavior, we did not emulate that > whitespace weirdness, nor a number of other weirdnesses. I would argue > that ranges ought to model their I/O behavior on records not arrays, > because that's not as much of a legacy syntax. Done. Now range types more closely resemble records in parsing behavior. Patch attached. Changes: * new parser + doc changes * merged with master * pg_dump now work * various cleanup TODO: * ultimately, there should be a simple cache to avoid repeated syscache lookups. I have put this off mainly to avoid premature optimization, but that code has been pretty stable for a while * support casts and typmod -- this requires the work for the RangeCoerceExpr that I mentioned before Regards, Jeff Davis
Вложения
В списке pgsql-hackers по дате отправления: