Skip site navigation (1) Skip section navigation (2)

Re: Range Types, constructors, and the type system

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Range Types, constructors, and the type system
Date: 2011-06-29 16:34:06
Message-ID: BANLkTi=cGF2s0Y=UCQtLDityppVO2jdJ4w@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Jun 29, 2011 at 11:41 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> Robert didn't really seem to like the idea of throwing an error though
> -- Robert, can you expand on your reasoning here?

I guess I don't have any terribly well-thought out reasoning - maybe
it's fine.  It just seems strange to have a type that you can't
display.

But now that I'm thinking about this a little more, I'm worried about this case:

CREATE TABLE foo AS RANGE('something'::funkytype, 'somethingelse'::funktype);
DROP TYPE funkytype;

It seems to me that the first statement had better fail, or else the
second one is going to create a hopeless mess (imagine that a new type
comes along and gets the OID of funkytype).

It also seems a bit strange to me that we're contemplating a system
where users are always going to have to cast the return type.
Generally, casts are annoying and we want to minimize the need for
them.  I'm not sure what the alternative is, though, unless we create
separate constructor functions for each type: int8range_cc(1, 2).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2011-06-29 16:34:54
Subject: Re: Inconsistency between postgresql.conf and docs
Previous:From: Merlin MoncureDate: 2011-06-29 16:15:17
Subject: Re: patch: Allow \dd to show constraint comments

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group