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

TODO: Fix CREATE CAST on DOMAINs

From: Gevik Babakhani <pgdev(at)xs4all(dot)nl>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: TODO: Fix CREATE CAST on DOMAINs
Date: 2006-09-20 13:05:30
Message-ID: 1158757530.22092.35.camel@voyager.truesoftware.net (view raw or flat)
Thread:
Lists: pgsql-hackers
I would like to work on the domain casting problem. I have spent
sometime in order to understand how this whole domain handling works
when it comes to casting and I think I understand why this cannot be
fixed in isolation as Tom has described in:

http://archives.postgresql.org/pgsql-hackers/2006-05/msg00190.php

Perhaps I am way off but I am starting to think we need to handle
domains in more organized and consistent way in order to avoid bugs like
this.


First I would like to know how PG's code looked like without the
domains. I went searching in the release notes and I found the following
regarding the domains:

7.3 	: Add domain support (Rod)
7.3.3	: Fix planner's selectivity estimation functions to handle domains
properly
7.4	: Add check constraints for domains (Rod)
	: Improve automatic type casting for domains (Rod, Tom)
7.4.12  : Properly check DOMAIN constraints for UNKNOWN parameters in
prepared statements (Neil)
8.0.1	: Make ALTER TABLE ADD COLUMN enforce domain constraints in all
cases
8.0.7	: Properly check DOMAIN constraints for UNKNOWN parameters in
prepared statements (Neil)
8.1.4	: Properly check DOMAIN constraints for UNKNOWN parameters in
prepared statements (Neil)


I need to go back and see where and how the domains are handled in a
global sense. Then I hope I can gather enough information to be able to
submit a coherent proposal.

If you have any thoughts you would like to share about this, please let
me know.

Regards,
Gevik.




Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2006-09-20 13:09:43
Subject: Re: [HACKERS] Incrementally Updated Backup
Previous:From: Matthew T. O'ConnorDate: 2006-09-20 13:04:21
Subject: Re: pdfs of the conference

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