Excerpts from Tom Lane's message of dom may 08 23:00:27 -0400 2011:
> For
> example, if you start noticing an occasional integer overflow that
> didn't happen before, it might be pretty darn difficult to figure out
> that the problem is that an operation that was formerly resolved as int4
> + int4
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom and I:
>>> BTW, not to rain on the parade or anything, but I'll bet that
>>> rejiggering anything at all here will result in whining that puts the
>>> 8.3-era removal of a few implicit casts to shame.
>> I'll take that bet, as it's really h
"Greg Sabino Mullane" writes:
> Tom Lane wrote:
>> BTW, not to rain on the parade or anything, but I'll bet that
>> rejiggering anything at all here will result in whining that puts the
>> 8.3-era removal of a few implicit casts to shame.
> I'll take that bet, as it's really hard to imagine anyth
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
> BTW, not to rain on the parade or anything, but I'll bet that
> rejiggering anything at all here will result in whining that puts the
> 8.3-era removal of a few implicit casts to shame.
I'll take that bet, as it's really hard
On fre, 2011-05-06 at 18:38 -0300, Alvaro Herrera wrote:
> I remember that one of the problems put forth against this idea was
> that stuff like int2+int2 which currently returns int2 would have to
> be changed to return int4, otherwise it risks overflow which it
> currently doesn't (not because th
2011/5/6 Tom Lane :
> Robert Haas writes:
>> 2011/5/4 Tom Lane :
>>> Perhaps it would be adequate to allow automatic resolution of an
>>> overloading conflict only when one of the available alternatives
>>> dominates all others, ie, none of the argument positions requires a
>>> "longer distance" c
Robert Haas writes:
> 2011/5/4 Tom Lane :
>> Perhaps it would be adequate to allow automatic resolution of an
>> overloading conflict only when one of the available alternatives
>> dominates all others, ie, none of the argument positions requires a
>> "longer distance" cast than is used in that po
2011/5/4 Tom Lane :
> Perhaps it would be adequate to allow automatic resolution of an
> overloading conflict only when one of the available alternatives
> dominates all others, ie, none of the argument positions requires a
> "longer distance" cast than is used in that position by any other
> avail
Excerpts from Tom Lane's message of mié may 04 17:14:25 -0300 2011:
> Robert Haas writes:
> > It's not clear to me whether in any of this there is a solution to the
> > problem of int2 being a second-class citizen.
>
> I've always felt that the basic problem int2 has got is that the parser
> ini
Robert Haas writes:
> ... One of the big, fat problems
> with typispreferred is that it totally falls apart when more than two
> types are involved. For example, given a call f(int2), we can't
> decide between f(int4) and f(int8), but it seems pretty clear (to me,
> at least) that we should prefe
On Tue, May 3, 2011 at 3:06 PM, Tom Lane wrote:
> I wrote:
>> Alvaro Herrera writes:
>>> The interesting discussion is what happens next. To me, this is all
>>> related to this previous discussion:
>>> http://archives.postgresql.org/pgsql-hackers/2010-09/msg00232.php
>
>> Yeah, there doesn't see
Jim Nasby writes:
> Which begs the question... why do we allow on assignment casting of a float
> to an int?
Because the SQL standard requires it.
In any case, the user's intent in such a case is perfectly clear.
The reasons for not allowing assignment casts to happen in expression
contexts are
On May 4, 2011, at 12:00 AM, Зотов Роман wrote:
>>> F(smallint)
>>> F(integer)
>>> but call like F(float)
>>> i wouldn`t like to fail it.
>> I think this particular example would be a mistake, because that cast
>> would be lossy, so you want to invoke it only when the user explicitely
>> selects it
04.05.2011 0:00, Alvaro Herrera пишет:
Excerpts from Зотов Роман's message of mar may 03 16:31:31 -0300 2011:
but here we can see problem like
F(smallint)
F(integer)
but call like F(float)
i wouldn`t like to fail it.
I think this particular example would be a mistake, because that cast
would b
Excerpts from Зотов Роман's message of mar may 03 16:31:31 -0300 2011:
> but here we can see problem like
> F(smallint)
> F(integer)
> but call like F(float)
> i wouldn`t like to fail it.
I think this particular example would be a mistake, because that cast
would be lossy, so you want to invoke i
03.05.2011 23:06, Tom Lane пишет:
I wrote:
Alvaro Herrera writes:
The interesting discussion is what happens next. To me, this is all
related to this previous discussion:
http://archives.postgresql.org/pgsql-hackers/2010-09/msg00232.php
Yeah, there doesn't seem like much point unless we have
I wrote:
> Alvaro Herrera writes:
>> The interesting discussion is what happens next. To me, this is all
>> related to this previous discussion:
>> http://archives.postgresql.org/pgsql-hackers/2010-09/msg00232.php
> Yeah, there doesn't seem like much point unless we have a clear idea
> what we'r
Excerpts from Tom Lane's message of mar may 03 15:41:27 -0300 2011:
> Alvaro Herrera writes:
> > Excerpts from Зотов Роман's message of lun abr 11 17:39:32 -0300 2011:
> > I had a brief look at this patch, updating it to current HEAD past some
> > pgindent conflicts. It seems sane, but as Zotov s
Alvaro Herrera writes:
> Excerpts from ÐоÑов Роман's message of lun abr 11 17:39:32 -0300
> 2011:
> I had a brief look at this patch, updating it to current HEAD past some
> pgindent conflicts. It seems sane, but as Zotov says, it doesn't do
> anything yet: it only changes typispreferr
Robert Haas wrote:
> On Mon, Apr 11, 2011 at 1:39 PM, ? ? wrote:
> > 11.04.2011 5:19, Robert Haas ?:
> >>
> >> You only sent this to me, I think; I assume you meant to copy the list.
> >>
> >> ...Robert
> >>
> >> On Mar 16, 2011, at 12:46 AM, Zotov ?wrote:
> >
> > I send full patch, pr
On Mon, Apr 11, 2011 at 1:39 PM, Зотов Роман wrote:
> 11.04.2011 5:19, Robert Haas пишет:
>>
>> You only sent this to me, I think; I assume you meant to copy the list.
>>
>> ...Robert
>>
>> On Mar 16, 2011, at 12:46 AM, Zotov wrote:
>
> I send full patch, prev patch could be not so full, because
On Thu, Mar 10, 2011 at 8:12 AM, Zotov wrote:
> Hello, i have an old system where used implicit casting
> float<->integer
> numeric<->float
> numeric<->integer
>
> I want define implicit casts, but postgresql don`t know cast priority
> now postgresql have PREFERRED flag, but only flag
> I can`t d
Hello, i have an old system where used implicit casting
float<->integer
numeric<->float
numeric<->integer
I want define implicit casts, but postgresql don`t know cast priority
now postgresql have PREFERRED flag, but only flag
I can`t define prefer level like
Integer=0
Numeric=1
Float=2
Maybe
tex
23 matches
Mail list logo
