Thread: Re: Possible bug on insert
Do other RDBMSs like Oracle, DB2, mysql, SQLServer, etc usually break
compatibility with applications when changing major versions? I am not
trying to say either way but I would be interested to see what others
experience has been. My experience has been that they do not. At the same
time I switched all of my stuff to postgres a while back and have had so few
problems that I haven't really felt much need to use those other systems.
No offense taken. I am very meticulous about any software upgrades that I
do on my production systems. I'm not quite sure what you mean by "this
business since you have no idea what I am actually doing. For all you know
I am a boy scout developing a public service web site to earn a merit badge
and am not actually in any business. ;-) I suppose that I shouldn't have
said that I don't want to have to test my apps to upgrade to a new version
of postgres. I am used to having to do this for any of the software on my
servers. What I should have said is that I would prefer not to have to go
any change a bunch of code on my production applications immediately. I
realize that in order to make progress it is sometimes neccesary to break
compatibility with old stuff. That being said it would have been nice in my
opinion if there was an option to revert to the old behavior for at least a
while so that I can upgrade sooner rather than later. It is not going to be
a huge problem for me to update the apps but I am probably going to wait
until I am already making other changes and going through a full testing
cycle before I do the upgrade. The whole proccess would just be a lot
smoother if I had the option of using the old behavior with 7.3 for while.
Plus if I have to tell people that we have to spend time and money retesting
all of our apps just to not get stuck on an old version of the database
that's one more thing they might bring up when making the case to switch to
something else. This is why I would like to know about other systems
maintaining backwards compatibility. If I had the option to use the old
behavior it would be a lot easier to make the transition without anyone
noticing. Once again not an insurmountable obstacle but it would be nice.
I am also still confused as to what the rules are that I am breaking. For
instance:
The following will all execute successfully:
CREATE TABLE bugtest ( a int2 );
select '1' union select '2';
insert into bugtest values('1');
insert into bugtest values('2');
But the following will not:
insert into bugtest (a) select '1' union select '2';
Where exactly is the illegal type conversion taking place in the last
statement that is different from the above statements.
I hope that I don't sound like I am complaining. I love postgres and to be
honest I really just want to be able to use pgadmin III sooner than later as
it is so much better than pgadmin II but it doesn't support postgres 7.2.
> Anyhow, Bruce posted a patch to the 7.3 line to allow this behavior
> back, as it was necessary for some apps. However, don't count on it
> for 7.4...
Thanks very much that could very possibly buy me all the time that I will
want. Where do I get this patch?
Thanks again,
Rick Gigger
P.S. I have one more question. Will the following php code work fine inside
a larger transaction:
pg_query($conn, "copy bar from stdin");
pg_put_line($conn, "3\thello world\t4.5\n");
pg_put_line($conn, "4\tgoodbye world\t7.11\n");
pg_put_line($conn, "\\.\n");
pg_end_copy($conn);
That is does doing the weird thing reading from standard input change how it
behaves inside a transaction or do anything else unexpected. And is this
the best and or fastest way to insert multiple tules at a time?
"Vivek Khera" <khera@kcilink.com> wrote in message
news:x7isn16rzx.fsf@yertle.int.kciLink.com...
> >>>>> "RG" == Rick Gigger <rick@alpinenetworking.com> writes:
>
> RG> very often and I will have to undergo a testing cycle for each of them
just
> RG> to maintain compatibility with postgres > 7.2.4. This is not
something I
> RG> really want to do. I would much prefer to just upgrade and have my
legasy
> RG> apps work without modification or testing.
>
> You can't have progress that way. To be fair, it *is* a major version
> number change, and if you don't test your apps across major version
> changes of *anything* you don't need to be in this business. No
> offense ;-)
>
> Anyhow, Bruce posted a patch to the 7.3 line to allow this behavior
> back, as it was necessary for some apps. However, don't count on it
> for 7.4...
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Vivek Khera, Ph.D. Khera Communications, Inc.
> Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
> AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
Rick Gigger wrote: > No offense taken. I am very meticulous about any software upgrades that I > do on my production systems. I'm not quite sure what you mean by "this > business since you have no idea what I am actually doing. For all you know > I am a boy scout developing a public service web site to earn a merit badge > and am not actually in any business. ;-) I suppose that I shouldn't have Well.. Let's leave that part out to keep this discussion technical.:-) > said that I don't want to have to test my apps to upgrade to a new version > of postgres. I am used to having to do this for any of the software on my > servers. What I should have said is that I would prefer not to have to go > any change a bunch of code on my production applications immediately. I > realize that in order to make progress it is sometimes neccesary to break > compatibility with old stuff. That being said it would have been nice in my > opinion if there was an option to revert to the old behavior for at least a > while so that I can upgrade sooner rather than later. It is not going to be > a huge problem for me to update the apps but I am probably going to wait > until I am already making other changes and going through a full testing > cycle before I do the upgrade. The whole proccess would just be a lot > smoother if I had the option of using the old behavior with 7.3 for while. Well.. I haven't work enough on pg to make a migration across versions. But the app. I work on regularly is routinely one year behind a major oracle release and we spend good deal of our time testing oracle bug/feature compatibility and making any changes required. I hope that answers your question. It really depends upon how much mission critical your app. is. If its something that monitors heart beats of patients in a 10000 patient hospital in a central fashion (Just making it up) or controlling a nuke plant, I would rather test everything I can. > > Plus if I have to tell people that we have to spend time and money retesting > all of our apps just to not get stuck on an old version of the database > that's one more thing they might bring up when making the case to switch to > something else. This is why I would like to know about other systems > maintaining backwards compatibility. If I had the option to use the old > behavior it would be a lot easier to make the transition without anyone > noticing. Once again not an insurmountable obstacle but it would be nice. Retesting with application with version upgrade in dependent components is fact of life. It is a must. Its upto you to decide whether you can afford to bypass it, fully or partially. Of course there are business constraints that decides where the trade off settles. If you are happy with the way pg upgrade, good for you. But you should read release notes carefully and work on removing/changing any deprecated features in time. Usually pg makes a feature non-default in one major version and removes it completely in next major version. So you have time of two major releases to take care of any issues. I think that is more than what anybody else can give across versions. Shridhar
On Tue, 7 Oct 2003, Rick Gigger wrote:
> I am also still confused as to what the rules are that I am breaking. For
> instance:
>
> The following will all execute successfully:
>
> CREATE TABLE bugtest ( a int2 );
> select '1' union select '2';
> insert into bugtest values('1');
> insert into bugtest values('2');
Technically speaking, I believe the above inserts would be errors in plain
SQL92 (I don't believe character(1) is assignable to an exact numeric
type). In part because of the flexible type system, we try to treat such
things as the type being assigned to when possible.
> insert into bugtest (a) select '1' union select '2';
>
> Where exactly is the illegal type conversion taking place in the last
> statement that is different from the above statements.
The union requires us to figure out what type it is before we get to
actually doing the insert. It might be possible in union all to avoid
that, but for union, you need to know what rules to use to determine
duplicates, so I really don't think there's any choice there (imagine that
the values were say '1.1' and '1.2'... Are those two distinct values or
not?)
On Tue, Oct 07, 2003 at 12:43:21PM -0600, Rick Gigger wrote:
> Do other RDBMSs like Oracle, DB2, mysql, SQLServer, etc usually break
> compatibility with applications when changing major versions? I am not
I can say for sure that I was involved in a case where the upgrade of
SQL Server required significant additional development efforts to
make an application work. So yes, they sometimes do.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110