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  (Shridhar Daithankar <shridhar_daithankar@persistent.co.in>)
Re: Possible bug on insert  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Re: Possible bug on insert  (Andrew Sullivan <andrew@libertyrms.info>)
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:

Previous
From: dipak_bhandari@afgsoftware.com.au
Date:
Subject: ...
Next
From: "John Wells"
Date:
Subject: Humor me: Postgresql vs. MySql (esp. licensing)