Operator for int8 array

"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:

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.