-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
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, th
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 mo
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 o
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 disc
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 t
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
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 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 doc
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 spe
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
Attached is a patch that makes the specification of parameters to the
PREPARE SQL statement more flexible: the user can specify "unknown" to
have the type of a particular parameter inferred from the context in
which the parameter is used (if possible). If fewer parameter types are
specified than th
12 matches
Mail list logo
