The admin doing the upgrade can copy the
> existing database wherever they need it: tape, another filesystem, NFS
> mount, etc.
>
> --
> Thomas Swan
>
>
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
--
Dave Smith
CANdata Systems Ltd
416-493-9020
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
For the int2col op value I have this table for when the cast returns NULL
value <0
<, <= ,= int2col=null
>,>= in2col is not null
value > 0
<,<= in2col is not null
=,>,>= int2col=null
Im not sure why pg allows me to do a int2col=null and returns nothing
so I am assuming that internally pg just res
My point was that it was inconstant behavour. What exactly are you
comparing with int2? To me the case without the cast should should throw
the same error as the statement with the cast.
Tom Lane wrote:
Dave Smith <[EMAIL PROTECTED]> writes:
If this is only dealing with constants, w
If this is only dealing with constants, why not just explicitly add a
cast to the constant of the column type at the planner level. It would
solve this problem as well ...
create table test (f int2);
select * from test where f=cast('1981928928921' as int2);
ERROR: pg_atoi: error reading "198192
In Canada we have small claims court. up to 10,1000$ and it only costs
you 50$ to file a claim. They have to file a defense or settle within 30
days. Usally if they owe you the money it forces them to do something,
either settle or *really* drag it out, but it gets the process moving.
Jeroen
Tom Lane wrote:
> "Billy G. Allie" <[EMAIL PROTECTED]> writes:
>
>> ... The DISABLE_COMPLEX_MACRO definition was originally put in to work
>> around a macro size limitation of the UnixWare 2.1 C compiler (and
>> later the SCO UDK (Universal Development Kit)). If the gnu C compiler
>> is being u