On Thu, Sep 07, 2006 at 07:12:17PM -0700, Josh Berkus wrote:
Elein,
I may have missed some stuff here. Obviously. For example how to divide
and conquer the various aspects of the issues raised here. But this is a
high, high level proposal at this time.
I'm not quite clear on what in
elein [EMAIL PROTECTED] writes:
Domains and subtypes.
* Create new child type from values in parent type.
* Maintain only checks for constraints
* Create implicit casts from child to parent
This seems a bit content-free, because it's not clear how it differs
from what we do now. We
On Fri, Sep 08, 2006 at 02:33:13PM -0400, Tom Lane wrote:
elein [EMAIL PROTECTED] writes:
Domains and subtypes.
* Create new child type from values in parent type.
* Maintain only checks for constraints
* Create implicit casts from child to parent
This seems a bit
elein [EMAIL PROTECTED] writes:
a) if subtypes/domains can have constraints then the model should
not be different for domains only but for all types. Constraint
checking would only
occur at check constraint points--and there for any type. You
already check for the existance of
On Fri, Sep 08, 2006 at 03:47:23PM -0400, Tom Lane wrote:
elein [EMAIL PROTECTED] writes:
a) if subtypes/domains can have constraints then the model should
not be different for domains only but for all types. Constraint
checking would only
occur at check constraint points--and
elein [EMAIL PROTECTED] writes:
I think what you are saying is that the domain checking (proposed constraint
existence checking) would need to be done in more places and I'm not sure I
understand this.
What I'm complaining about is the need to search the catalogs to see if
a datatype has
On Fri, Sep 08, 2006 at 05:20:18PM -0400, Tom Lane wrote:
elein [EMAIL PROTECTED] writes:
I think what you are saying is that the domain checking (proposed constraint
existence checking) would need to be done in more places and I'm not sure I
understand this.
What I'm complaining about
As many of you know I've been contemplating the implementation
of Domains and subtypes.
DISCLAIMER: This is a proposal only. The actual work needs to
be picked up by someone in a better place to work on the code
than I am. For various reasons, I can only be an active reference
and tester on
Elein,
I may have missed some stuff here. Obviously. For example how to divide
and conquer the various aspects of the issues raised here. But this is a
high, high level proposal at this time.
I'm not quite clear on what in your proposal is different from current Domain
behavior. Or are you
TODO has:
* Allow user-defined functions retuning a domain value to enforce domain
constraints
Is there something we should add to this?
---
Tom Lane wrote:
elein [EMAIL PROTECTED] writes:
On Mon, Mar
Bruce Momjian pgman@candle.pha.pa.us writes:
TODO has:
* Allow user-defined functions retuning a domain value to enforce domain
constraints
Is there something we should add to this?
Yeah, a DONE marker ;-)
regards, tom lane
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
TODO has:
* Allow user-defined functions retuning a domain value to enforce domain
constraints
Is there something we should add to this?
Yeah, a DONE marker ;-)
OK, marked as done. I assume that's what you mean,
elein [EMAIL PROTECTED] writes:
But I like the idea of centralizing the check in the input/output
functions. It seems clearer and cleaner.
I remembered the problem with doing it that way: an input function can't
enforce a domain NOTNULL constraint, because it won't even get invoked
for a null
On Mon, Mar 27, 2006 at 11:41:30AM -0500, Tom Lane wrote:
elein [EMAIL PROTECTED] writes:
But I like the idea of centralizing the check in the input/output
functions. It seems clearer and cleaner.
I remembered the problem with doing it that way: an input function can't
enforce a domain
elein [EMAIL PROTECTED] writes:
On Mon, Mar 27, 2006 at 11:41:30AM -0500, Tom Lane wrote:
I remembered the problem with doing it that way: an input function can't
enforce a domain NOTNULL constraint, because it won't even get invoked
for a null input value. So there seems no way around having
On Fri, Mar 24, 2006 at 10:49:00PM -0500, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
grin you missed one. Domains as parameters to functions are not
enforced.
I think we've got that one actually. It's domains as PL-function output
types that aren't checked. Also plpgsql
Jim C. Nasby [EMAIL PROTECTED] 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
On Mar 25, 2006, at 4:14 PM, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
Background:
Domains lay the groundwork for inherited basetypes
or subtypes. By defining a domain and overriding
operators and possibly creating an operator class, then a domain
can be created which inherits the storage method
and all of the functions of a basetype. The domain
constraint
elein [EMAIL PROTECTED] writes:
Attached is a patch to parse_oper.c which essentially does the
following. The major change is in binary_oper_exact().
Instead of checking only one level of the basetype it checks
all possible combinations of type and parent types for
an exact match (only).
On Fri, Mar 24, 2006 at 03:47:13PM -0500, Tom Lane wrote:
elein [EMAIL PROTECTED] writes:
Attached is a patch to parse_oper.c which essentially does the
following. The major change is in binary_oper_exact().
Instead of checking only one level of the basetype it checks
all possible
On Fri, Mar 24, 2006 at 08:33:51PM +0100, Peter Eisentraut wrote:
elein wrote:
Domains lay the groundwork for inherited basetypes
or subtypes.
Semantically, a domain and a subtype are completely different things. A
domain restricts the possible values of a type but behaves exactly like
elein [EMAIL PROTECTED] writes:
Operators have the single distinction from functions in that when one argument
has an unknown type, then an exact match is tried with the unknown arg
type set to the known type. This code has always been in there.
Yeah, but it's just a fast special case of the
On Fri, Mar 24, 2006 at 06:27:13PM -0500, Tom Lane wrote:
elein [EMAIL PROTECTED] writes:
Operators have the single distinction from functions in that when one
argument
has an unknown type, then an exact match is tried with the unknown arg
type set to the known type. This code has
Elein,
Domains enable people to create basetype subtypes using SQL
and procedural languages only. Current belief is that
this doesn't work. However, all of this has worked
since domains were implemented with three exceptions.
grin you missed one. Domains as parameters to functions are not
Josh Berkus josh@agliodbs.com writes:
grin you missed one. Domains as parameters to functions are not
enforced.
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.
27 matches
Mail list logo
