All-
<soapbox>
While it is not always the case, I see many responses to questions in the form of "Why don't you just upgrade- that's
supportedin version XXX".
Let me give you several reasons why this is not always possible.
1. Support software is not compatible. I use Chili!soft for Linux, a webpage/asp solution. Even tho I use the most
currentversion of Chili!Soft, it currently only supports Postgresql 6.5.2. I don't have the option of upgrading. My DB
isused by this software, so I would break the dependancy if I upgraded.
2. DB Users may not be DBAs. If a user is not responsible for the maintenance of the server or the software running on
it(such as a third party ISP or IS department), upgrading is not a choice. While suggestions can usually be made, the
useris not at liberty to make it happen.
Being that this is an SQL forum for help, it seems appropriate that any reply for assistance should be directed towards
theversion is use. This is not intended to be a flame against this particular reply, just an observation is general.
Whilestating the version that a particular solution is available is not completely inappropriate, every attempt should
bemade to offer help in the version that is being presented by the request.
</soapbox>
Sorry if this seems long-winded- it just seems that someone needed to say it...
Kenn
____________________________________________
Kenn Thompson
Senior Web Architect
Adesta Communications
Work: 402.233.7595
Cell: 402.210.6326
>>> "Francis Solomon" <francis@stellison.co.uk> 12/12/00 04:21AM >>>
Hi Borek,
What version of PostgreSQL are you using? This works fine for me on
7.02. Time to update, maybe?
Hope this helps
Francis
>
> Hello all,
>
> My following problem is:
>
> swports=# select substring(cp from 1 for 4)::int4 from out2cp;
> ERROR: pg_atoi: error in "6.1,": can't parse ".1,"
>
> SQL syntax is apparently OK. When I omit the typecast, the query
> works:
>
> swports=# select substring(cp from 1 for 4) from out2cp;
> substr
> --------
> 3182
> 3182
> 3182
> -8<- text deleted ---
>
> The cp entries are varchars in form NNNN.N, where N is numeral.
> So can someone explain why the parse error?
>