Re: Possible bug on insert - Mailing list pgsql-general
From | Rick Gigger |
---|---|
Subject | Re: Possible bug on insert |
Date | |
Msg-id | 004601c38d02$e26cfbb0$0700a8c0@trogdor Whole thread Raw |
Responses |
Re: Possible bug on insert
Re: Possible bug on insert Re: Possible bug on insert |
List | pgsql-general |
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 >
pgsql-general by date: