Neil Conway [EMAIL PROTECTED] writes:
On Thu, 2006-01-12 at 10:40 -0500, Tom Lane wrote:
If you're finding yourself writing a large and invasive patch, I think
you're doing it wrong.
I think I might be :-)
Yipes ... this seems far more invasive than I think is justified.
In particular the
Neil Conway [EMAIL PROTECTED] writes:
The only trickiness was allowing UNKNOWN to be specified in the list
of type names in the PREPARE statement. Since UNKNOWN was previously an
unreserved_keyword, this caused reduce/reduce conflicts:
You're doing it wrong. There is no need for any special
On Sun, 2006-01-15 at 12:17 -0500, Tom Lane wrote:
You're doing it wrong. There is no need for any special case whatever
in gram.y --- ordinary lookup of the type name will do fine.
Woops, good point. Attached is a revised patch that doesn't modify the
grammar, and includes updates to the
Neil Conway [EMAIL PROTECTED] writes:
Woops, good point. Attached is a revised patch that doesn't modify the
grammar, and includes updates to the documentation and regression tests.
BTW, I wonder whether it wouldn't be a better idea to declare the
pg_prepared_statement view's parameter_types
On Thu, 2006-01-12 at 19:51 -0500, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
It would also mean that this would produce unexpected results:
PREPARE foo AS SELECT * FROM pg_cursors; EXECUTE foo.
Unexpected in what sense?
Unexpected in the sense that the user would have no
Tom Lane [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] wrote
AbsorbFsyncRequests will be called during the fsync loop in my patch,
so new files might be added to pendingOpsTable and they will be removed
from the table *before* writing the pages belonging to them.
I think
Folks,
Please find attached a patch against CVS TIP which adds an uninstall
script in SQL for each of the things where it would be appropriate.
Contrib modules that already have an uninstall script are left as-is,
as are ones which create stand-alone executeables, as I believe that
we need to
On Sun, 2006-01-15 at 17:33 -0500, Tom Lane wrote:
BTW, I wonder whether it wouldn't be a better idea to declare the
pg_prepared_statement view's parameter_types column as regtype[]
instead of oid[].
Yeah, good point -- I had thought that using type names would be
ambiguous in the presence of
On Sun, 2006-01-15 at 20:08 -0800, David Fetter wrote:
*** contrib/chkpass/Makefile27 Sep 2005 17:13:00 - 1.7
--- contrib/chkpass/Makefile14 Jan 2006 23:16:03 -
***
*** 1,9
! # $PostgreSQL: pgsql/contrib/chkpass/Makefile,v 1.6 2004/08/20
20:13:02 momjian
On Mon, Jan 16, 2006 at 12:13:11AM -0500, Neil Conway wrote:
On Sun, 2006-01-15 at 20:08 -0800, David Fetter wrote:
ifdef USE_PGXS
The change to $PostgreSQL$ is bogus (perhaps due to the way you
setup cvsup?), as are all the other $PostgreSQL$ changes in the
patch. Also, the patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
Attached is a patch to hopefully make pg_dump a lot more useful.
I started out by making it simply able to avoid dumping a single
table, but, inspired by David Fetter's patch last November, also
11 matches
Mail list logo
