Not quite as expected. I didn't expect deleting the 2 from the
primary table to fail because the CASCADE DELETE wasn't able to run on
the second (even though no values existed in that table). I suppose
it does run properly (blocks all delete attempts) -- but I just didn't
expect it to error out
integer (float_expression) or int (float_expression) DO work on
RedHat6.2/PostgreSQL6.5 and DO NOT work on Mandrake/PostgreSQL7.0.2
Try using int2()/int4()/int8() instead of integer().
Why is that NOT documented under "Matematical functions"?
Because we haven't received any patches to
"Rod Taylor" [EMAIL PROTECTED] writes:
Not quite as expected. I didn't expect deleting the 2 from the
primary table to fail because the CASCADE DELETE wasn't able to run on
the second (even though no values existed in that table).
But it *doesn't* fail. At least not in the versions I tried.
"Rod Taylor" [EMAIL PROTECTED] writes:
INSERT INTO table [ ( column [, ...] ) ]
{ DEFAULT VALUES | VALUES ( expression [, ...] ) | SELECT query }
The documentation is wrong here, not the code. SQL92 defines the syntax
as
insert statement ::=
INSERT INTO table name insert columns
Thomas Lockhart wrote:
I'll go ahead and start generating hardcopy, though I understand that it
is no longer allowed into the shipping tarball :(
Lamar, do you plan to continue to package the hardcopy somewhere in the
RPMs? If so, I'll have them ready soon.
I didn't for 7.0, IIRC. Or
On Fri, 6 Apr 2001, Thomas Lockhart wrote:
The docs are ready for shipment.
Even better ...
Okay, let's let this sit as RC3 for the next week...
I'll go ahead and start generating hardcopy, though I understand that it
is no longer allowed into the shipping tarball :(
At 2Meg, is there
On Fri, 6 Apr 2001, Thomas Lockhart wrote:
The docs are ready for shipment.
Even better ...
Okay, let's let this sit as RC3 for the next week...
I'll go ahead and start generating hardcopy, though I understand that it
is no longer allowed into the shipping tarball :(
At
Thomas Lockhart wrote:
The docs are ready for shipment.
Even better ...
Okay, let's let this sit as RC3 for the next week...
I'll go ahead and start generating hardcopy, though I understand that it
is no longer allowed into the shipping tarball :(
Lamar, do you plan to
On Fri, 6 Apr 2001, Bruce Momjian wrote:
On Fri, 6 Apr 2001, Thomas Lockhart wrote:
The docs are ready for shipment.
Even better ...
Okay, let's let this sit as RC3 for the next week...
I'll go ahead and start generating hardcopy, though I understand that it
is no
Can we drop TODO.detail from the tarball too? No need to include that,
I think. The web site has nice links to it now. Uncompressed it is
1.314 megs.
That strikes me as an awfully web-centric view of things. Not everyone
has an always-on high-speed Internet link.
If you want to
At 2Meg, is there a reason why we include any of the docs as part of the
standard tar ball? It shouldn't be required to compile, so should be able
to be left out of the main tar ball and downloaded seperately as required
.. thereby shrinking the distribution to 6Meg from its current 8 ...
On Fri, 6 Apr 2001, Tom Lane wrote:
At 2Meg, is there a reason why we include any of the docs as part of the
standard tar ball? It shouldn't be required to compile, so should be able
to be left out of the main tar ball and downloaded seperately as required
.. thereby shrinking the
OTOH, if Marc was only thinking of removing the pre-built docs from the
tarball, I don't object to that. I'm not sure why those weren't
distributed as separate tarballs from the get-go. I just say that the
doc sources are part of the source distribution...
From the get-go, the docs
Thomas, will you be doing .pdf files? I have had requests to put that
in the Debian documentation package.
afaik, I don't have the means to generate pdf directly. Pointers would
be appreciated, if there are mechanisms available on Linux boxes.
We have had lots of offers of help for these
Thomas, will you be doing .pdf files? I have had requests to put that
in the Debian documentation package.
afaik, I don't have the means to generate pdf directly. Pointers would
be appreciated, if there are mechanisms available on Linux boxes.
We have had lots of offers of help for
That strikes me as an awfully web-centric view of things. Not everyone
has an always-on high-speed Internet link.
If you want to make the docs and TODO.detail be a separate chunk of the
split distribution, that's fine with me. But I don't agree with
removing them from the full
On Fri, 6 Apr 2001, Bruce Momjian wrote:
That strikes me as an awfully web-centric view of things. Not everyone
has an always-on high-speed Internet link.
If you want to make the docs and TODO.detail be a separate chunk of the
split distribution, that's fine with me. But I don't
On Fri, Apr 06, 2001 at 09:23:35PM -0400, Bruce Momjian allegedly wrote:
Thomas, will you be doing .pdf files? I have had requests to put that
in the Debian documentation package.
afaik, I don't have the means to generate pdf directly. Pointers would
be appreciated, if there are
Can you use ps2pdf to generate PDF? It is a utility that comes with
ghostscript. I know versions = 6.0 are fine.
PDF files generated from postscript with Adobe Acrobat are usually of
much higher quality than those generated by ghostscript. It seems that
ghostscript encodes rendered
Thanks! I'm not too worried about 1.4.2, but be sure to let us know what
the problem was; it may help out someone else...
NetBSD-1.4.2/i386 passes all tests with 7.1RC3.
My previous test failure on this platform was due to the timezone
information on the test system not being standard; once
Okay, here are my results:
Box 1: C180 (2.0 PA8000), HPUX 10.20
Compile with gcc: all tests pass
Compile with cc: two lines of diffs in geometry (attached)
Box 2: 715/75 (1.1 PA7100LC), HPUX 10.20
Compile with gcc: all tests pass
Compile with cc: all tests pass
I haven't had time
Giles Lean [EMAIL PROTECTED] writes:
I'm not sure how interesting these differences are anymore -- is there
anyone familiar enough with floating point to determine if the results
are acceptable (although currently unexpected :-) or not?
Differences in the last couple of decimal places in the
Hi
I've been running RC3 regression tests, starting with a FreeBSD 4.2-STABLE
and a Solaris 7 Sparc box. Both tests ran without any problems. I tried
Solaris 8 Sparc next: it still suffered from the same unix socket problems.
I had a look at the code and it seems to me that the use of unix
23 matches
Mail list logo
