Re: Range Types, constructors, and the type system

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Range Types, constructors, and the type system
Дата
Msg-id 1309969333.3012.114.camel@jdavis
обсуждение исходный текст
Ответ на Re: Range Types, constructors, and the type system  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Range Types, constructors, and the type system
Список pgsql-hackers
On Wed, 2011-07-06 at 09:10 -0400, Robert Haas wrote:
> > There's some slight ugliness around the NULL/infinity business, but I
> > think that I could be convinced. I'd like to avoid confusion between
> > NULL and infinity if possible.
> 
> I was thinking that if you passed 'i' for one of the bounds, it would
> ignore the supplied argument and substitute its special infinity
> value.  But you'd still need to supply some argument in that position,
> which could be NULL or anything else.  It doesn't really seem worth
> having additional constructor functions to handle the case where one
> or both arguments are infinite.

Right, that's what I assumed that you meant. I can't think of anything
better, either, because I like the fact that two arguments are there so
that you can visually see which sides are bounded/unbounded.

I suppose we could have constructors like: range(text, subtype)
and range(subtype, text)
where the text field is used to specify "infinity". But that has the
obvious problem "what if the subtype is text?". So, of course, we make a
special new pseudotype to represent infinity... ;)

But seriously, your idea is starting to look more appealing.

To get into some more details: how exactly would this constructor be
generated on the fly? Clearly we want only one underlying C function
that accepts something like: range_internal(lower, upper, flags, Oid rangetype)
So how do we get the rangetype in there? I suppose a default 4th
argument?

That would be kind of an interesting option, but what if someone
actually specified that 4th argument? We couldn't allow that.

Also, are default arguments always applied in all the contexts where
this function might be called?

Regards,Jeff Davis



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Old postgresql repository
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt