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 supported in 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 current
version of Chili!Soft, it currently only supports Postgresql 6.5.2. I don't have the
option of upgrading. My DB is used 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 user is 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 the version is use. This is not intended to be a
flame against this particular reply, just an observation is general. While stating the
version that a particular solution is available is not completely inappropriate, every
attempt should be made 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" <[EMAIL PROTECTED]> 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?
>
