I wrote:
>> Anyway, I think we're out of time to do anything about the issue for
>> 9.1. I think what we'd better do is force a downcast in the context
>> of matching to an ANYARRAY parameter, and leave the other cases to
>> revisit later.
> Attached is a draft patch to do the above. It's only l
On Tue, Jun 7, 2011 at 9:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane wrote:
>>> Note that I changed coerce_type's behavior for both ANYARRAY and ANYENUM
>>> targets, but the latter behavioral change is unreachable since the other
>>> routines in parse
Robert Haas writes:
> On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane wrote:
>> Note that I changed coerce_type's behavior for both ANYARRAY and ANYENUM
>> targets, but the latter behavioral change is unreachable since the other
>> routines in parse_coerce.c will not match a domain-over-enum to ANYENUM.
On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane wrote:
> I wrote:
>> Anyway, I think we're out of time to do anything about the issue for
>> 9.1. I think what we'd better do is force a downcast in the context
>> of matching to an ANYARRAY parameter, and leave the other cases to
>> revisit later.
>
> Att
I wrote:
> Anyway, I think we're out of time to do anything about the issue for
> 9.1. I think what we'd better do is force a downcast in the context
> of matching to an ANYARRAY parameter, and leave the other cases to
> revisit later.
Attached is a draft patch to do the above. It's only lightly
Peter Eisentraut writes:
> What you are looking for is the SQL feature called "distinct types".
> The makers of the SQL standard have sort of deprecated domains in favor
> of distinct types, because distinct types address your sort of use case
> better, and prescribing the behavior of domains beco
On fre, 2011-06-03 at 13:53 -0500, Kevin Grittner wrote:
> Another long-range nicety would be something which I have seen in
> some other databases, and which is consistent with the inheritance
> theme, is that you can't compare or assign dissimilar domains -- an
> error is thrown. So if you try to
Tom Lane wrote:
> A domain constraint is a constraint that is specified for a
> domain.
> It is applied to all columns that are based on that domain, and
> to all values cast to that domain.
>
> If you take that literally, it means that domain constraints are
> applied
> (1) in an assignmen
"Kevin Grittner" writes:
> Another long-range nicety would be something which I have seen in
> some other databases, and which is consistent with the inheritance
> theme, is that you can't compare or assign dissimilar domains -- an
> error is thrown. So if you try to join from the eye color column
BTW, a possibly relevant point here is that SQL:2008 says (in 4.12)
The purpose of a domain is to constrain the set of valid values
that can be stored in a column of a base table by various
operations.
and in 4.17.4
A domain constraint is a constraint that is spec
Robert Haas wrote:
> The real crux of the issue here is: under what circumstances
> should we look through the domain wrapper around an underlying
> type, and under what circumstances should we refrain from doing
> so?
I don't know if this is the intent of domains in the SQL standard,
but I fi
Robert Haas writes:
> The real crux of the issue here is: under what circumstances should we
> look through the domain wrapper around an underlying type, and under
> what circumstances should we refrain from doing so?
That's half of it. The other half is: when we *do* look through the
wrapper, i
On Fri, Jun 3, 2011 at 1:00 PM, David E. Wheeler wrote:
> On Jun 3, 2011, at 8:22 AM, Robert Haas wrote:
>
>> Well, as Bill Clinton once said, "it depends on what the meaning of
>> the word 'is' is". I think of array types in PostgreSQL as meaning
>> "the types whose monikers end in a pair of squ
On Fri, Jun 03, 2011 at 10:42:01AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Fri, Jun 03, 2011 at 12:27:35AM -0400, Robert Haas wrote:
> >> and we
> >> treat the call as a request to smash bar to the underlying array type.
>
> > No, there's no need to do that. The domain "is" an array,
On Jun 3, 2011, at 8:22 AM, Robert Haas wrote:
> Well, as Bill Clinton once said, "it depends on what the meaning of
> the word 'is' is". I think of array types in PostgreSQL as meaning
> "the types whose monikers end in a pair of square brackets".
Man, range types are going to fuck with your br
On Fri, Jun 03, 2011 at 11:22:34AM -0400, Robert Haas wrote:
> On Fri, Jun 3, 2011 at 1:14 AM, Noah Misch wrote:
> > No, there's no need to do that. The domain "is" an array, not merely
> > something
> > that can be coerced to an array. Therefore, it can be chosen as the
> > polymorphic
> > ty
On Fri, Jun 3, 2011 at 1:14 AM, Noah Misch wrote:
> No, there's no need to do that. The domain "is" an array, not merely
> something
> that can be coerced to an array. Therefore, it can be chosen as the
> polymorphic
> type directly. Indeed, all released versions do this.
Well, as Bill Clint
Noah Misch writes:
> On Fri, Jun 03, 2011 at 12:27:35AM -0400, Robert Haas wrote:
>> and we
>> treat the call as a request to smash bar to the underlying array type.
> No, there's no need to do that. The domain "is" an array, not merely
> something that can be coerced to an array. Therefore, it
On Fri, Jun 03, 2011 at 12:27:35AM -0400, Robert Haas wrote:
> But in this case I really don't quite understand why you don't like
> the proposed behavior. AIUI, the case we're talking about is a
> function foo that takes, say, anyarray, and returns anyarray.
>
> Now, let us say we attempt to cal
On Thu, Jun 2, 2011 at 8:25 PM, Noah Misch wrote:
> I don't doubt that's usable, and folks would find the behavior of their
> applications acceptable given that approach. However, it's an arbitrary (from
> the user's perspective) difference in behavior compared to the interaction of
> polymorphic
On Thu, Jun 02, 2011 at 06:56:02PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, May 24, 2011 at 02:00:54PM -0400, Noah Misch wrote:
> >> I took your lack of any response as non-acceptance of the plan I outlined.
> >> Alas, the wrong conclusion. I'll send a patch this week.
>
> > See a
Noah Misch writes:
> On Tue, May 24, 2011 at 02:00:54PM -0400, Noah Misch wrote:
>> I took your lack of any response as non-acceptance of the plan I outlined.
>> Alas, the wrong conclusion. I'll send a patch this week.
> See attached arrdom1v1-polymorphism.patch. This currently adds one syscach
Robert Haas writes:
> On Tue, May 24, 2011 at 2:54 PM, Tom Lane wrote:
>> I'm starting to think that maybe we should separate the two cases after
>> all. If we force a downcast for ANYARRAY matching, we will fix the loss
>> of functionality induced by the bug #5717 patch, and it doesn't seem
>>
On Tue, May 24, 2011 at 2:54 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On May 24, 2011, at 11:30 AM, Tom Lane wrote:
>>> I guess that the question that's immediately at hand is sort of a
>>> variant of that, because using a polymorphic function declared to take
>>> ANYARRAY on a domain-
On Tue, May 24, 2011 at 02:00:54PM -0400, Noah Misch wrote:
> On Tue, May 24, 2011 at 01:28:38PM -0400, Tom Lane wrote:
> > Noah Misch writes:
> > > On Tue, May 24, 2011 at 12:12:55PM -0400, Tom Lane wrote:
> > >> This is a consequence of the changes I made to fix bug #5717,
> > >> particularly th
"David E. Wheeler" writes:
> On May 24, 2011, at 11:30 AM, Tom Lane wrote:
>> I guess that the question that's immediately at hand is sort of a
>> variant of that, because using a polymorphic function declared to take
>> ANYARRAY on a domain-over-array really is using a portion of the base
>> type
On May 24, 2011, at 11:30 AM, Tom Lane wrote:
> Well, if they actually were first-class types, they probably wouldn't
> be born with an implicit cast to some other type to handle 99% of
> operations on them ;-). I think the hard part here is having that cake
> and eating it too, ie, supporting do
"David E. Wheeler" writes:
> On May 24, 2011, at 10:11 AM, Tom Lane wrote:
>> On the other hand it feels like we'd be taking yet another step away
>> from allowing domains to be usefully used in function declarations.
> I agree. It sure seems to me like DOMAINs should act exactly like any
> other
On May 24, 2011, at 10:11 AM, Tom Lane wrote:
> regression=# select negate(42::pos);
> ERROR: return type mismatch in function declared to return pos
> DETAIL: Actual return type is integer.
> CONTEXT: SQL function "negate" during inlining
>
> If we smashed to base type then this issue would g
On Tue, May 24, 2011 at 01:28:38PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, May 24, 2011 at 12:12:55PM -0400, Tom Lane wrote:
> >> This is a consequence of the changes I made to fix bug #5717,
> >> particularly the issues around ANYARRAY matching discussed here:
> >> http://archives
Noah Misch writes:
> On Tue, May 24, 2011 at 12:12:55PM -0400, Tom Lane wrote:
>> This is a consequence of the changes I made to fix bug #5717,
>> particularly the issues around ANYARRAY matching discussed here:
>> http://archives.postgresql.org/pgsql-hackers/2010-10/msg01545.php
> We discussed t
Merlin Moncure writes:
> On Tue, May 24, 2011 at 11:12 AM, Tom Lane wrote:
>> 1. If a domain type is passed to an ANYARRAY argument, automatically
>> downcast it to its base type (which of course had better then be an
>> array).
> Does that mean that plpgsql %type variable declarations will see
"David E. Wheeler" writes:
> On May 24, 2011, at 9:12 AM, Tom Lane wrote:
>> An alternative rule we could use in place of #2 is just "smash domains
>> to base types always, when they're matched to ANYELEMENT". That would
>> be simpler and more in keeping with #1, but it might change the behavior
On Tue, May 24, 2011 at 12:12:55PM -0400, Tom Lane wrote:
> In http://archives.postgresql.org/pgsql-bugs/2011-05/msg00171.php
> Regina Obe complains that this fails in 9.1, though it worked before:
>
> regression=# CREATE DOMAIN topoelementarray AS integer[];
> CREATE DOMAIN
> regression=# SELECT
On May 24, 2011, at 9:12 AM, Tom Lane wrote:
> An alternative rule we could use in place of #2 is just "smash domains
> to base types always, when they're matched to ANYELEMENT". That would
> be simpler and more in keeping with #1, but it might change the behavior
> in cases where the historical
On Tue, May 24, 2011 at 11:12 AM, Tom Lane wrote:
> 1. If a domain type is passed to an ANYARRAY argument, automatically
> downcast it to its base type (which of course had better then be an
> array). This would include inserting an implicit cast into the
> expression tree, so that if the functio
In http://archives.postgresql.org/pgsql-bugs/2011-05/msg00171.php
Regina Obe complains that this fails in 9.1, though it worked before:
regression=# CREATE DOMAIN topoelementarray AS integer[];
CREATE DOMAIN
regression=# SELECT array_upper(ARRAY[[1,2], [3,4]]::topoelementarray, 1);
ERROR: functi
37 matches
Mail list logo
