be fixed, I wanted to get the report out
ASAP.
--
Mr. F Harvell
First Time Software
407 467-1919
On 10 Dec 2005, at 23:59, Marc G. Fournier wrote:
7.3.12, 7.4.10, 8.0.5 and 8.1.1 ... all should be available on the
ftp mirrors by now ... please take a quick peak at them, and let us
This sounds very much like a memory problem. I would replace all of
the memory with another set of (preferably known good) memory and see
if the problems persist. Also look for other cores that may be
dropped. If there are several, memory is the likely cause. Be aware
that it will likely
On Thu, 25 Apr 2002 15:07:44 EDT, Tom Lane wrote:
> F Harvell <[EMAIL PROTECTED]> writes:
> > This also poses the biggest problem in terms of legacy compatibility.
> > Perhaps the answer is to add a runtime config option (and default it
> > to ANSI) and possib
the biggest problem in terms of legacy compatibility.
Perhaps the answer is to add a runtime config option (and default it
to ANSI) and possibly deprecate the C escaping.
Thanks,
F Harvell
--
Mr. F Harvell Phone: +1.407.673.2529
FTS International Data Syste
strong believer in PostgreSQL, many of my customers have
other demands/requirements. I still want to be able to use my
existing code and libraries when using their database. Sticking with
the "standards" allows me to develop best of class applications and
interface to best of class datab
"new" TIMESTAMP data
type was "created" the interest was to increase the precision. I
would guess, as you have also suggested, that the standards were based
upon existing implementations (along with an interest in backwards
compatibility).
Thanks,
F Harvell
--
ision is not a real
concern for us, however, for portability, I still suggest sticking
with the standard.
Thanks,
F Harvell
On Thu, 04 Oct 2001 20:30:24 -, Thomas Lockhart wrote:
> > The code asserts that SQL99 requires the default precision to be zero,
> > but I do not agree
