Hey Group,

i know what all will say but i need to recreate the = operator for
datatypes varchar and integer in PostgreSQL 8.3.

Our Software Project has Millions of Lines and so it would be difficult
to check all queries and Datatypes. Also it works really fine and we all
know the risk of wrong auto casting.

Anyone knows the Syntax?

Thanks a lot for your great work.


Daniel.

ups;

i have this script but forgott to execute it in the new createt db....
monday morning....

thnx.

Filip Rembiałkowski schrieb:
> 2008/5/5 Daniel Schuchardt <daniel_schuchardt@web.de
> <mailto:daniel_schuchardt@web.de>>:
>
> Hey Group,
>
> i know what all will say but i need to recreate the = operator for
> datatypes varchar and integer in PostgreSQL 8.3.
>
> Our Software Project has Millions of Lines and so it would be
> difficult to check all queries and Datatypes. Also it works really
> fine and we all know the risk of wrong auto casting.
>
> Anyone knows the Syntax?
>
>
>
> http://people.planetpostgresql.org/p...reSQL-8.3.html
>
> PS. you could search archives or even use google.
>
>
> --
> Filip Rembiałkowski

Daniel Schuchardt wrote:
> i know what all will say but i need to recreate the = operator for
> datatypes varchar and integer in PostgreSQL 8.3.
>
> Our Software Project has Millions of Lines and so it would be
> difficult
> to check all queries and Datatypes. Also it works really fine
> and we all
> know the risk of wrong auto casting.
>
> Anyone knows the Syntax?

What do you want to achieve?
Maybe there is already a different way to do what you want.

Yours,
Laurenz Albe

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Mon, May 05, 2008 at 11:18:37AM +0200, Daniel Schuchardt wrote:
> Hey Group,
>
> i know what all will say but i need to recreate the = operator for
> datatypes varchar and integer in PostgreSQL 8.3.
>
> Our Software Project has Millions of Lines and so it would be
> difficult to check all queries and Datatypes.

That technical debt is a risk to your whole project, and you need to
dedicate resources to paying it down.

<http://en.wikipedia.org/wiki/Technical_debt>

There are ways to get those automated casts, but they will only make
your situation worse in the long run.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

David Fetter schrieb:
> That technical debt is a risk to your whole project, and you need to
> dedicate resources to paying it down.
>
> <http://en.wikipedia.org/wiki/Technical_debt>
>
> There are ways to get those automated casts, but they will only make
> your situation worse in the long run.
>
> Cheers,
> David.
>

*g* interesting standpoint and your right but:

it is impossible for us to find all the points where the new 8.3
behavoir would crash at the first time. so our next versions would be
very buggy and our customers wouldn't be happy ;-)
the next problem is that our service personal has to be traineed too;
they dont know much about casting, 81 does it automatically; problems
problems problems.

if it is not possible (i know it is) ;-) to recreate automatic casts in
83 we would not be able to upgrade to 83 the next years. the next
possible date would be in about 3-4 years with the next major release.

PS:
our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views
that all use implicit casting.
and: everything is working fine ;-) :-P

so we have to choose another way.


cheers.

On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote:
> David Fetter schrieb:
>> That technical debt is a risk to your whole project, and you need
>> to dedicate resources to paying it down.
>>
>> <http://en.wikipedia.org/wiki/Technical_debt>
>>
>> There are ways to get those automated casts, but they will only
>> make your situation worse in the long run.
>
> *g* interesting standpoint and your right but:

No buts. If you create those automated casts, you are just putting
off the inevitable.

> it is impossible for us to find all the points where the new 8.3
> behavoir would crash at the first time. so our next versions would
> be very buggy and our customers wouldn't be happy ;-) the next
> problem is that our service personal has to be traineed too; they
> dont know much about casting, 81 does it automatically; problems
> problems problems.
>
> if it is not possible (i know it is) ;-) to recreate automatic casts
> in 83 we would not be able to upgrade to 83 the next years. the next
> possible date would be in about 3-4 years with the next major
> release.

You're just confirming the fact that your project is in existential
trouble.

> PS:
> our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views
> that all use implicit casting. and: everything is working fine ;-)
> :-P

How do you know? 8.3 removed the implicit casts precisely because
they were producing results that could most generously be describe as
"surprising."

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Tino Wildenhain schrieb:
> Hi,
>
> Daniel Schuchardt wrote:
>> David Fetter schrieb:
>>> That technical debt is a risk to your whole project, and you need to
>>> dedicate resources to paying it down.
>>>
>>> <http://en.wikipedia.org/wiki/Technical_debt>
>>>
>>> There are ways to get those automated casts, but they will only make
>>> your situation worse in the long run.
>>>
>>> Cheers,
>>> David.
>>>
>>
>> *g* interesting standpoint and your right but:
>>
>> it is impossible for us to find all the points where the new 8.3
>> behavoir would crash at the first time. so our next versions would be
>> very buggy and our customers wouldn't be happy ;-)
>> the next problem is that our service personal has to be traineed too;
>> they dont know much about casting, 81 does it automatically; problems
>> problems problems.
>>
>> if it is not possible (i know it is) ;-) to recreate automatic casts
>> in 83 we would not be able to upgrade to 83 the next years. the next
>> possible date would be in about 3-4 years with the next major release.
>>
>> PS:
>> our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views
>> that all use implicit casting.
>> and: everything is working fine ;-) :-P
>>
>> so we have to choose another way.
>
> Well err... implicit table joining is also off per default I believe.
> So if you had used it a lot you would have a similar problem.
>
> Comparing int with text in general does not sound like a very good
> idea to me. It should be quite easy to write a script to identify
> such places so you can either change the datatypes (preferred) or
> add the cast. Then rerun your automated regression tests...
>
> Cheers
> T.
it is not possible to do this. we also used automatic casting as a feature:
if a user starts a search, we never check the data type he puts in. in
81 postgresql automatically casts the user input in dependece of the
column. so all our search masks has to be checked to, edit fields need
to get a data type and so on.

example:

user types 1 -> our application automatically starts a search "LIKE '1%'"
user types 12 -> our application automatically starts a search "LIKE
'12%'"

and so on. and it doenst matter if the searchfield is char or integer,
81 does it automatically.
if it is a good or bad thing to do it is another question. it works in
81 and so we used this feature.

cheers.

yeah, its clear that an upgrade from 8.1 to 8.3 is impossible for us
without a major relase.
there are to many changes so the whole project has to be rechecked.

another example:

in 83:

postgres=# SELECT 1::INTEGER||1::INTEGER;
ERROR: operator does not exist: integer || integer at character 18
HINT: No operator matches the given name and argument type(s). You
might need to add explicit type casts.


83 with autocast from peter e:

ERROR: operator is not unique: integer || integer


in 81:

postgres=# SELECT 1::INTEGER||1::INTEGER;
?column?
----------
11
(1 row)

>
> No buts. If you create those automated casts, you are just putting
> off the inevitable.
>
yes but than it will become a future project. (i think with postgres 8,5
or 8,6 :-P )
>
> You're just confirming the fact that your project is in existential
> trouble.
>
no, we would get trouble if we upgrade. now everybody is happy :-).
btw: our first software release was with postgres 7.3 and since this
time we use this feature (about 6 years?).
> How do you know? 8.3 removed the implicit casts precisely because
> they were producing results that could most generously be describe as
> "surprising."
>
yeah thats an old discussion. we know about this and so we look for it.
it is a powerfull feature in 81 (and earlier) and yes if you use it in
the wrong way it will produce "surprising" results but if you use it in
the right way it is very powerfull. and if we get a suprising behavoir
we do in an explicit cast. done. ;-)
> Cheers,
> David.
>

daniel.

David Fetter <david@fetter.org> writes:
> On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote:
>> our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views
>> that all use implicit casting. and: everything is working fine ;-)
>> :-P

> How do you know? 8.3 removed the implicit casts precisely because
> they were producing results that could most generously be describe as
> "surprising."

This should not be underestimated. From the reports we've seen so far,
a very sizable fraction of people who find this kind of failure with 8.3
find out that their application was doing something unexpected in the
cases where it happened. If you've got as many failures as you suggest,
I'd be willing to bet that some of them are bugs in your code, not just
reliance on an implicit feature.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general