Re: Range Types
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: pgsql-hackers@postgresql.org
Date: 2011-09-13T08:41:36Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Replace the "New Linear" GiST split algorithm for boxes and points with a
- 7f3bd86843e5 9.2.0 cited
Attachments
- rangetypes-20110912.gz (application/x-gzip)
Another updated patch is attached. Changes: * support for send/recv * significant cleanup and fixes * test improvements TODO: * pg_dump support. This requires outputting collation names and opclass names (because those are part of the range type definition). Currently, that's only done for indexes through special functions in ruleutils.c. Should I define such functions there as well, or is there a simpler approach? Also, I have to filter out the generated constructor functions because those are created internally when defining a new range type. * some error messages should be improved * Originally, I wasn't sure whether to define a RangeCoerceExpr (similar to ArrayCoerceExpr), because the only use I had was for typmod. But that is necessary for casts as well, so I'll go ahead and do that and we'll get both casts and typmod for range types. * I think I should avoid some syscache lookups for some of the generic range functions. Right now they are done for every invocation, but it would be pretty simple to avoid lookups when looking up the same range type as last time. Review questions: * Do we like the new constructor behavior from the users' standpoint? * Right now, the patch accomplishes that behavior by generating several constructor functions every time a new range type is defined. Is that acceptable? Is there a better way? Regards, Jeff Davis