Re: Range Types
От | Jeff Davis |
---|---|
Тема | Re: Range Types |
Дата | |
Msg-id | 1315903296.7281.107.camel@jdavis обсуждение исходный текст |
Ответ на | Re: Range Types (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Range Types - typo + NULL string constructor
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: