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
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
On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Jun 7, 2011 at 9:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Note that I changed coerce_type's behavior for both ANYARRAY and ANYENUM
targets, but the latter behavioral change is
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
Peter Eisentraut pete...@gmx.net 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
Noah Misch n...@leadboat.com 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.
On Fri, Jun 3, 2011 at 1:14 AM, Noah Misch n...@leadboat.com 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
On Fri, Jun 03, 2011 at 11:22:34AM -0400, Robert Haas wrote:
On Fri, Jun 3, 2011 at 1:14 AM, Noah Misch n...@leadboat.com 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
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 brainz.
On Fri, Jun 03, 2011 at 10:42:01AM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
On Fri, Jun 3, 2011 at 1:00 PM, David E. Wheeler da...@kineticode.com 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
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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
Kevin Grittner kevin.gritt...@wicourts.gov 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
Tom Lane t...@sss.pgh.pa.us 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
On Tue, May 24, 2011 at 2:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com 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
Robert Haas robertmh...@gmail.com writes:
On Tue, May 24, 2011 at 2:54 PM, Tom Lane t...@sss.pgh.pa.us 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
Noah Misch n...@leadboat.com 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
On Thu, Jun 02, 2011 at 06:56:02PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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.
On Thu, Jun 2, 2011 at 8:25 PM, Noah Misch n...@leadboat.com 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
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 call
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 n...@leadboat.com 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,
On Tue, May 24, 2011 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us 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
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 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
David E. Wheeler da...@kineticode.com 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
Merlin Moncure mmonc...@gmail.com writes:
On Tue, May 24, 2011 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us 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
Noah Misch n...@leadboat.com 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
On Tue, May 24, 2011 at 01:28:38PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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:
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 go away.
David E. Wheeler da...@kineticode.com 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
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
David E. Wheeler da...@kineticode.com 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
36 matches
Mail list logo
