On Sun, Jun 01, 2008 at 08:50:13PM -0400, Stephen Frost wrote:
> * daveg ([EMAIL PROTECTED]) wrote:
> > The feature that the proposed patch enables is to create pg_dump custom
> > format archives for multiple tables with a predicate. No amount of csv or
> > xml will do that. Contrived example:
>
>
Okay,
Because I'm hardheaded as well as anxious to implement my own ideas
for the challenge of it :) ...
I've extended the the -t/--table option to optionally accept a WHERE
clause expression following the table pattern.
The user can, for example, run:
pg_dump -t "tab1:col1>15" -t "tab
Davy Durham <[EMAIL PROTECTED]> writes:
> On Sun, 2008-06-01 at 22:19 -0400, Stephen Frost wrote:
>> or so. I suppose it might be interesting to consider an 'insert-format'
>> output for COPY, which pg_dump could possibly be refactored to use when
>> requested.
> And sure.. pg_dump could then be
On Sun, 2008-06-01 at 22:19 -0400, Stephen Frost wrote:
>
> or so. I suppose it might be interesting to consider an 'insert-format'
> output for COPY, which pg_dump could possibly be refactored to use when
> requested. It'd be nice if it was easier to have COPY support more
> formats but right
Davy Durham <[EMAIL PROTECTED]> writes:
> To reiterate, it is not possible to use the COPY command to create
> standard SQL INSERT statements that can be conveniently loaded by
> another db. No?
Fair point, but the question here is about how useful this incremental
feature really is compared to it
* Davy Durham ([EMAIL PROTECTED]) wrote:
> No, the database I'm loading into is not PostgreSQL, but that's okay. I
> think that was someone else.
This gets back to the other question then- what database is it and does
it support CSV or XML imports?
> > Of course, on the other hand, you *could* u
On Sun, 2008-06-01 at 22:02 -0400, Stephen Frost wrote:
> * Davy Durham ([EMAIL PROTECTED]) wrote:
> > To reiterate, it is not possible to use the COPY command to create
> > standard SQL INSERT statements that can be conveniently loaded by
> > another db. No?
>
> Erm, thankfully, PostgreSQL (what
* Davy Durham ([EMAIL PROTECTED]) wrote:
> To reiterate, it is not possible to use the COPY command to create
> standard SQL INSERT statements that can be conveniently loaded by
> another db. No?
Erm, thankfully, PostgreSQL (what you're loading the data into?) can
take more than just SQL INSERT st
On Sun, 2008-06-01 at 20:53 -0400, Stephen Frost wrote:
> * Davy Durham ([EMAIL PROTECTED]) wrote:
> > The code is not all that much to maintain as it is, and making it an
> > addition to an existing parameter instead of a new one may not increase
> > the code size by much more at all.
>
> I'm gen
* Davy Durham ([EMAIL PROTECTED]) wrote:
> The code is not all that much to maintain as it is, and making it an
> addition to an existing parameter instead of a new one may not increase
> the code size by much more at all.
I'm generally in favor of 'creature-comfort' kind of additions, but I
have
* daveg ([EMAIL PROTECTED]) wrote:
> The feature that the proposed patch enables is to create pg_dump custom
> format archives for multiple tables with a predicate. No amount of csv or
> xml will do that. Contrived example:
Uh, pg_dump's custom format really isn't particularly special, to be
hones
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
[ improved patch ]
Still a couple quibbles:
[ more good feedback ]
All valid complaints, and noticeably improved/simplified code as a
result. Third patch attached.
Joe
Index: dblink.c
=
Joe Conway <[EMAIL PROTECTED]> writes:
> [ improved patch ]
Still a couple quibbles:
> + ereport(level,
> + (errcode(sqlstate),
> + errmsg(message_primary),
This *must* be errmsg("%s", message_primary), else you have big problems
with % in the text. Also, I think it
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Here is my proposed patch -- as suggested for cvs tip only.
A few comments:
[...great comments as usual...]
Thanks for the excellent feedback! I think the attached addresses it all.
I haven't been around enough lately to be sure I unde
On Sun, Jun 01, 2008 at 04:40:15PM -0400, Andrew Dunstan wrote:
> daveg wrote:
> >
> >I can't imagine many of my clients ever writing another C program or even
> >being willing to pay me to do so. While modularizing pg_dump is a fine
> >idea,
> >I don't think it addresses the same set of use case
daveg wrote:
ISTM this would be better off waiting until we turn large parts of
pg_dump into a library, as has been often discussed, at which point it
should be relatively simple to write a custom client to do what the OP
wants. I agree that it does not at all belong in pg_dump.
I c
On Sun, 2008-06-01 at 15:47 -0400, Tom Lane wrote:
> Davy Durham <[EMAIL PROTECTED]> writes:
> > So, if this patch is not acceptable as-is, what would you feel about
> > this:
> > I could enhance the -t/--table=NAME option to accept more than a
> > simple NAME. Rather it could acc
On Sun, Jun 01, 2008 at 04:13:34PM -0400, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> >Davy Durham <[EMAIL PROTECTED]> writes:
> >
> >>So, if this patch is not acceptable as-is, what would you feel about
> >>this:
> >>I could enhance the -t/--table=NAME option to accept more than a
Tom Lane wrote:
Davy Durham <[EMAIL PROTECTED]> writes:
So, if this patch is not acceptable as-is, what would you feel about
this:
I could enhance the -t/--table=NAME option to accept more than a
simple NAME. Rather it could accept something in the form:
Davy Durham <[EMAIL PROTECTED]> writes:
> So, if this patch is not acceptable as-is, what would you feel about
> this:
> I could enhance the -t/--table=NAME option to accept more than a
> simple NAME. Rather it could accept something in the form:
> --table
Joe Conway <[EMAIL PROTECTED]> writes:
> Here is my proposed patch -- as suggested for cvs tip only.
A few comments:
Don't use errstart/errfinish directly. A reasonable way to deal with
the type of situation you have here is
ereport(ERROR,
(errcode(...),
On Sun, 2008-06-01 at 10:43 -0400, Tom Lane wrote:
> Davy Durham <[EMAIL PROTECTED]> writes:
> > I have added a new parameter, -w/--where=EXPR
> > This lets you specify an expression that will be used in a WHERE
> > clause when the data is dumped.
>
> This seems pretty poorly thought out. It
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Yeah, the dblink code should probably try a bit harder to propagate the
original error fields.
Sounds reasonable. Do you think this is a bug fix or an 8.4 enhancement?
8.4 enhancement I think, since a behavioral change
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
This replace xlog.h with xlogdefs.h in bufpage.h. All other changes are
forgotten include somewhere. It reduce e.g. bloat to half in itup.h. But,
There are still unresolved problems. htup should include bufpage.h,
because it needs PageHeader size
Zdenek Kotala wrote:
> This replace xlog.h with xlogdefs.h in bufpage.h. All other changes are
> forgotten include somewhere. It reduce e.g. bloat to half in itup.h. But,
> There are still unresolved problems. htup should include bufpage.h,
> because it needs PageHeader size, but there is still
Davy Durham <[EMAIL PROTECTED]> writes:
> I have added a new parameter, -w/--where=EXPR
> This lets you specify an expression that will be used in a WHERE
> clause when the data is dumped.
This seems pretty poorly thought out. It can hardly work in a dump
of more than one table, which means
26 matches
Mail list logo
