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

Re: Domains as Subtypes

From: elein <elein(at)varlena(dot)com>
To: Jim Nasby <jnasby(at)pervasive(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Domains as Subtypes
Date: 2006-03-26 01:09:51
Message-ID: 20060326010951.GH15165@varlena.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Mar 25, 2006 at 07:16:13PM +0100, Jim Nasby wrote:
> On Mar 25, 2006, at 4:14 PM, Tom Lane wrote:
> 
> >"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> >>On Fri, Mar 24, 2006 at 10:49:00PM -0500, Tom Lane wrote:
> >>>I think we've got that one actually.  It's domains as PL-function  
> >>>output
> >>>types that aren't checked.  Also plpgsql fails to enforce domain  
> >>>checks
> >>>on its local variables.
> >
> >>So is this the complete list?
> >
> >No, I don't think so.  IIRC we're also missing domain checks on
> >parameter values in Bind messages, and there might be some other
> >holes too.  See the archives.
> >
> >I made a suggestion about closing all these holes at once by
> >integrating domain checking into the I/O functions for domains,
> >but it's not clear how to do that without a big performance hit.
> 
> Performance hit on just domain handling or overall? Personally, I'd  
> rather see a hit on domain handling that we can work on later rather  
> than the current state of things which seems to smack of MySQL (Get  
> the feature 'checked off the list' first, then worry about doing it  
> the right way).

The three issues I've raised regard the type behavior of domains with
operators and are completely independent of the input/output checks issues.

But I like the idea of centralizing the check in the input/output
functions.  It seems clearer and cleaner.  The procedural language
checks are harder, but may be easier to implement if there were
a centralized check domain functionality.

--elein


> --
> Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
> Pervasive Software      http://pervasive.com    work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>               http://archives.postgresql.org
> 

In response to

Responses

pgsql-hackers by date

Next:From: Luke LonerganDate: 2006-03-26 01:42:28
Subject: Re: 8.2 planning features
Previous:From: Joe ConwayDate: 2006-03-25 21:11:44
Subject: Re: [pgsql-advocacy] Some employment changes ...

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