Обсуждение: Operator for int8 array
Dear All, I need operator for int8 array. I tried changing the code in contrib/ and compiled. When I tried executing the query, it is dumping. Kindly tell me if there is alternative to overcome the problem. I am using postgresql 7.1.3 version. -- regards, Deepa K
"K.Deepa" <kdeepa@midascomm.com> writes: > I need operator for int8 array. I tried changing the code in contrib/ > and compiled. > When I tried executing the query, it is dumping. Kindly tell me if there > is alternative > to overcome the problem. I am using postgresql 7.1.3 version. 7.1.3? Egad. Get yourself onto some remotely modern version of PG. 7.1 is nearly five years old and has many known serious bugs, of both data-loss and security flavors. You didn't say exactly what you needed to do with an int8 array, but you may well find that 8.1 can do it already. The array support is far superior now to what it was in 7.1. regards, tom lane
Dear sir, We are already in the process of migrating toward 8.1 . For existing support, we like to support with 7.1.3 . Along with 7.1.3 release, contrib/array has been given for array iterator support for int4 type array. It is working fine. We changed it similarly, for int8 type array. It is not working and postmaster receives signal 11. We like to know whether is it feasible or not? thanks and regards, stp. On Fri, 24 Feb 2006, Tom Lane wrote: > "K.Deepa" <kdeepa@midascomm.com> writes: > > I need operator for int8 array. I tried changing the code in contrib/ > > and compiled. > > When I tried executing the query, it is dumping. Kindly tell me if there > > is alternative > > to overcome the problem. I am using postgresql 7.1.3 version. > > 7.1.3? Egad. Get yourself onto some remotely modern version of PG. > 7.1 is nearly five years old and has many known serious bugs, of > both data-loss and security flavors. > > You didn't say exactly what you needed to do with an int8 array, but you > may well find that 8.1 can do it already. The array support is far > superior now to what it was in 7.1. > > regards, tom lane >
On Mon, 27 Feb 2006, S.Thanga Prakash wrote: > Dear sir, > > We are already in the process of migrating toward 8.1 . > For existing support, we like to support with 7.1.3 . > > Along with 7.1.3 release, contrib/array has been given for array iterator > support for int4 type array. It is working fine. > We changed it similarly, for int8 type array. > It is not working and postmaster receives signal 11. > > We like to know whether is it feasible or not? why not ? > > thanks and > regards, > stp. > > > > On Fri, 24 Feb 2006, Tom Lane wrote: > >> "K.Deepa" <kdeepa@midascomm.com> writes: >>> I need operator for int8 array. I tried changing the code in contrib/ >>> and compiled. >>> When I tried executing the query, it is dumping. Kindly tell me if there >>> is alternative >>> to overcome the problem. I am using postgresql 7.1.3 version. >> >> 7.1.3? Egad. Get yourself onto some remotely modern version of PG. >> 7.1 is nearly five years old and has many known serious bugs, of >> both data-loss and security flavors. >> >> You didn't say exactly what you needed to do with an int8 array, but you >> may well find that 8.1 can do it already. The array support is far >> superior now to what it was in 7.1. >> >> regards, tom lane >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > Regards, Oleg _____________________________________________________________ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83
"S.Thanga Prakash" <thanga@midascomm.com> writes: > We are already in the process of migrating toward 8.1 . > For existing support, we like to support with 7.1.3 . No, just stop right there; your reasonable-sounding premise is utterly not reasonable. You should be making every possible effort to get any existing 7.1 databases decommissioned. NOW. Not tomorrow, not next week. If you have data that is critical enough to worry about having a transition process, get it out of there. Expending further effort to "support" continued use of an inherently unreliable database is a disservice to your customers. Sooner or later it *will* eat their data. (Not "might"; WILL. Are you familiar with the XID wraparound problem?) You've been warned. regards, tom lane PS: if you have application compatibility issues that prevent an immediate migration to 8.*, consider using PG 7.2.8 as a stopgap solution. 7.2.* is not supported anymore either, but at least it avoids the XID wraparound gotcha; and the later 7.2.* releases fix a lot of other critical bugs.