This patch forces the use of 'DROP VIEW' to destroy views.
It also changes the syntax of DROP VIEW to
DROP VIEW v1, v2, ...
to match the syntax of DROP TABLE.
Some error messages were changed so this patch also includes changes to the
appropriate expected/*.out files.
Doc changes for 'DROP TABLE" and 'DROP VIEW' are included.
--
Mark Hollomon
* doc/src/sgml/installation.sgml: ditto.
* src/test/regress/README: Regenerate.
* doc/src/sgml/docguide.sgml: Explain how it was done. Explain how
INSTALL and HISTORY are (now) generated.
* doc/src/sgml/Makefile: Implement HISTORY generation to be analoguous
to INSTALL.
I prepared and tested a patch vs. 7.0.2, and it works fine. I've added
another option which allows users to have their own service file in
~/.pg_service.conf, which might come handy sometimes.
Mario Weilguni
I have noticed that there are some identical files in
postgresql-7.0.2/src/test/regress/expected/
> diff float8-cygwin.out float8-small-is-zero.out #I recommend deleting
float8-cygwin.out
> diff geometry-cygwin-precision.out geometry-solaris-precision.out #I
recommend deleting geometry-cygwin-precision.out
below is the diff of postgresql-7.0.2/src/test/regress/resultmap
that has the above files deleted plus the addition of an alpha regression
test built with alphaev56-dec-osf4.0e/2.95.2/ . The alpha geometry
regression file is attached
11c11
< float8/i.86-pc-cygwin*=float8-cygwin
---
> float8/i.86-pc-cygwin*=float8-small-is-zero
18c18
< geometry/i.86-pc-cygwin*=geometry-cygwin-precision
---
> geometry/i.86-pc-cygwin*=geometry-solaris-precision
21a22
> geometry/alpha.*-dec-osf=geometry-alpha-precision
Ricardo Muggli
Systems Manager
Information and Technology Services
Minnesota State University, Mankato
Only two have shown up on the web site. Even the mbox is missing the
second.
The missing patch is a one-liner, so here it is. I can resend the
whole bug report if wanted.
Pete Forman
As a result, backend/libpq/pqcomm.c and interfaces/libpq/fe-connect.c
fail to compile.
The <netinet/tcp.h> header needs to be preceded by <netinet/in.h>, at
least on IRIX, Solaris and AIX. The simple configure test fails.
(That header on Linux is idempotent.)
The basic problem is that <netinet/tcp.h> is a BSD header. The
correct header for TCP internals such as TCP_NODELAY on a UNIX system
is <xti.h>. By UNIX I mean UNIX95 (aka XPG4v2 or SUSv1) or later.
The current UNIX standard (UNIX98 aka SUSv2) is available online at
<http://www.opengroup.org/onlinepubs/7908799/>.
The fix is to add header support for <xti.h> into configure.in and
config.h.in.
The 2 files which conditionally include <netinet/tcp.h> need also to
conditionally include <xti.h>.
Pete Forman
I have counted 9 differences in the least significant digit compared
with geometry-positive-zeros.out. It would be wise for someone else
to double check.
Pete Forman
it previously. The patch included is against fairly current sources, but
it may apply cleanly against 7.0.2 as well.
On Fri, 6 Oct 2000, Vilson farias wrote:
> I found a irregular behavior with constraints.
>
> I can only set a referencial integrity between these tables when there are
> no data, even if there are no change to referential integrity violation.
couldn't produce a full patch using cvs diff -c this time since I have
created new files and anonymous cvs usage doesn't allow you to
adds. I'm supplying the modified src/interfaces/jdbc as a tarball at :
http://www.candleweb.no/~gunnar/projects/pgsql/postgres-jdbc-2000-10-05.tgz
The new files that should be added are :
? org/postgresql/PGStatement.java
? org/postgresql/ObjectPool.java
? org/postgresql/ObjectPoolFactory.java
There is now a global static pool of free byte arrays and used byte arrays
connected to a statement object. This is the role of the new PGStatement
class. Access to the global free array is synchronized, while we rely on
the PG_Stream synchronization for the used array.
My measurements show that the perfomance boost on this code is not quite as
big as my last shot, but it is still an improvement. Maybe some of the
difference is due to the new synchronization on the global array. I think I
will look into choosing between on a connection level and global level.
I have also started experimented with improving the performance of the
various conversions. The problem here is ofcourse related handle the
various encodings. One thing I found to speed up ResultSet.getInt() a lot
was to do custom conversion on the byte array into int instead of going
through the getString() to do the conversion. But I'm unsure if this is
portable, can we assume that a digit never can be represented by more than
one byte ? It works fine in my iso-latin-8859-1 environment, but what about
other environments ? Maybe we could provide different ResultSet
implementations depending on the encoding used or delegate some methods of
the result set to an "converter class".
Check the org/postgresql/jdbc2/FastResultSet.java in the tarball above to
see the modified getInt() method.
Regards,
Gunnar
for the library. not sure if this will cause problems on other
platforms, but if it does it can be easily fixed. Also remove the
references to the GeekGadgets includes as the majority of users don't
have them installed and they foul the build process. We can document
that adding them if you have them installed is a good idea.
David Reid
> > For a while I though it might be because we are using an alpha TAS in
> > the spinlock rather than the old semaphore. I replaced our spinlock
> > with the standard one and it made no difference. We have been running
> > with our spinlock implementation for nearly 2 months on a production
> > database now without a hitch, so I think it is ok. Did I ever submit
> > any patches for the Alpha spinlock?
>
> Not that I recall. We did get some advice from some Alpha gurus at DEC
> who seemed to think the existing TAS code is OK. What was it that you
> felt needed to be improved?
The current code uses semaphores, which has the advantage that it works
well even on multi-processor machines, but the disadvantage that it is not
the fastest way possible. Writing a spinlock on Alpha for SMP machines is
very difficult, as you need to deal with memory barriers. A real mess. But
then one of the people at Compaq pointed out to us that there is a
ready-made routine on Alpha. We implemented it with the two patches below.
I ran tests with lots of parallel back-ends and got around a 10% speed
increase. I include the two patches. Perhaps some of the other people
running Tru64 can have a look at these as well.
Cheers,
Adriaan Joubert
> this is patch v 0.4 to support transactions with BLOBs.
> All BLOBs are in one table. You need to make initdb.
>
> --
> Sincerely Yours,
> Denis Perchine
