Tom Lane wrote:
> Bruce Momjian 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, or are you
Bruce Momjian 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
---(end of broadcast)--
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,
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 aroun
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
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 nu
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
> >>>outp
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
"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
On Fri, Mar 24, 2006 at 10:49:00PM -0500, Tom Lane wrote:
> Josh Berkus writes:
> > 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
Josh Berkus writes:
> 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.
regards
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.
you missed one. Domains as parameters to functions are no
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
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
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 exactl
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 possi
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
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
that type in all other respects. (The fact that PostgreSQL allows you
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 enables
19 matches
Mail list logo
