Re: WIP: RangeTypes

On Tue, 2011-01-11 at 11:13 -0800, David Fetter wrote:
> > 3. Typmod -- There is still one annoyance about typmod remaining. I need
> > to treat it like an array in find_typmod_coercion_function(), and then
> > create a coercion expression. Is it worth it? Would typmod on a range be
> > confusing, or should I just finish this item up?
>
> Probably not worth it for the first round.

OK, I'll block typmods for range types for now.

> > 4. Docs
>
> Happy to help evenings this week :)
>
> > 5. Tests
>
> Same. What do you have so far?

Great!

I think the best tests would be around the ANYRANGE type mechanism to
see if anything seems wrong or limiting. Particularly, its interaction
with ANYELEMENT.

> > 7. Right now the parse function is quite dumb. Is there some example
> > code I should follow to make sure I get this right?
>
> KISS is a fine principle. Do you really need it smart on the first
> round? :)

Well, it needs to be correct ;)

Specifically, I think there will be a problem if there is a multibyte
character following a backslash. There may be other problems, as well. I
could probably get these fixed, but it might be better to follow
patterns in other code. I'll look into it.

> > 8. In order to properly support the various combinations of ANYRANGE and
> > ANYELEMENT in a function definition (which are all important), we need
> > to be able to determine the range type given a subtype. That means that
> > each subtype can only have one associated range, which sounds somewhat
> > limiting, but it can be worked around by using domains. I don't think
> > this is a major limitation. Comments?
>
> As we get a more nuanced type system, this is one of the things that
> will need to get reworked, so I'd say it's better not to put too much
> effort into things that a refactor of the type system
> <http://wiki.postgresql.org/wiki/Refactor_Type_System> would make much
> better, at least right now.

Sounds good. I don't think this is an actual problem, so I'll consider
this a non-issue unless someone else has a comment.

> > Also related to representation:
> >
> > * Right now I always align the subtypes within the range according to
> > typalign. I could avoid that by packing the bytes tightly, and then
> > copying them around later. Suggestions? And what should the overall
> > alignment of the range type be?
>
> For the first cut, the simplest possible.

OK. It's already about as simple as it can get, but might be fairly
wasteful.

> > * If it's a fixed-length type, we can save the varlena header byte on
> > the overall range; but we lose the ability to save space when one of the
> > boundaries of the range is missing (NULL or INF), and it would
> > complicate the code a little. Thoughts?
>
> Probably not worth complicating the code at this stage. KISS again :)

OK.

Regards,
Jeff Davis