Martijn van Oosterhout wrote:
On Wed, Sep 20, 2006 at 10:56:08AM -0700, Mark Dilger wrote:
If the system chooses cast chains based on a breadth-first search, then the
existing int2 -> int8 cast would be chosen over an int2 -> int4 -> int8
chain, or an int2 -> int3 -> int4 -> int8 chain, or in f
On Wed, Sep 20, 2006 at 10:56:08AM -0700, Mark Dilger wrote:
> If the system chooses cast chains based on a breadth-first search, then the
> existing int2 -> int8 cast would be chosen over an int2 -> int4 -> int8
> chain, or an int2 -> int3 -> int4 -> int8 chain, or in fact any chain at
> all, b
> Trying to design this stuff purely according to abstract notions of
> elegance of the cast rules isn't going to work out well --- we have
> both spec requirements and backwards compatibility to worry about.
>
> Now we do have the flexibility to alter the default contents of pg_cast
> --- there c
Tom Lane wrote:
Now we do have the flexibility to alter the default contents of pg_cast
--- there could be more or fewer entries in there than there are now,
if the type coercion rules are altered to do less or more automatically
than they do now. But the end-result behavior needs to wind up bei
Martijn van Oosterhout writes:
> My question is whether there should be any implicit casts that are not
> safe. Your example int8 -> float8 being implicit is I think an error
> and we should wonder why that cast implicit now anyway.
Because the SQL spec requires it. You are not required to write
On Wed, Sep 20, 2006 at 10:26:55AM -0700, Mark Dilger wrote:
> I have thought about this some more. I think these are indeed SAFE. The
> distinction between SAFE and IMPLICIT should not, I think, be whether the
> storage type is identical, but rather whether there is any possible loss of
> pre
On Wed, Sep 20, 2006 at 09:31:48AM -0700, Mark Dilger wrote:
> Perhaps we need to be able to register casts with more information than
> just IMPLICIT vs. EXPLICIT. Perhaps we also need something like SAFE or
> some other term, and then have a rule that no chain of casts chosen by the
> system
Mark Dilger <[EMAIL PROTECTED]> writes:
> If the system chooses cast chains based on a breadth-first search,
> then the existing int2 -> int8 cast would be chosen over an int2 ->
> int4 -> int8 chain, or an int2 -> int3 -> int4 -> int8 chain, or in
> fact any chain at all, because the int2 -> int8
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
Mark Dilger wrote:
Casts from int2 -> int4, int2 -> int8, and int4 -> int8 would all be
SAFE, I think, because they are not lossy. But perhaps I have not
thought enough about this and these should be IMPLICIT rather than SAFE.
I have t
Mark Dilger <[EMAIL PROTECTED]> writes:
> Mark Dilger wrote:
>> Casts from int2 -> int4, int2 -> int8, and int4 -> int8 would all be
>> SAFE, I think, because they are not lossy. But perhaps I have not
>> thought enough about this and these should be IMPLICIT rather than SAFE.
> I have thought
Mark Dilger wrote:
Casts from int2 -> int4, int2 -> int8, and int4 -> int8 would all be
SAFE, I think, because they are not lossy. But perhaps I have not
thought enough about this and these should be IMPLICIT rather than SAFE.
I have thought about this some more. I think these are indeed SAF
Tom Lane wrote:
Rereading what I just wrote, it might be as simple as allowing a
two-step cast in certain cases, only if the first step is a domain to
base type coercion (which we assume would be specially marked in
pg_cast). But the devil is in the details ... and anyway there might
be a cleane
Tom Lane wrote:
So the hard part of this doesn't really require any understanding of
code at all. What we need is a proposal for an algorithm that loosens
the casting rules "just enough" to make explicit pg_cast entries for
domains work the way we would like them to, without wholesale breakage
o
Gevik Babakhani <[EMAIL PROTECTED]> writes:
> First I would like to know how PG's code looked like without the
> domains.
IIRC, as far as the datatype coercion and operator/function resolution
code were concerned, the domain patch basically consisted of dropping
getBaseType() calls in at a bunch o
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-0
15 matches
Mail list logo
