> > Unfortunately, current version of this patch has some conflicts, could
> you
> > rebase it?
>
> Given this patch has not been updated, I'm marking this as returned with
> feedback.
>
Here's a rebased patch that works with the latest master branch. Very
straightforward.
pgdump-include-table-
>
>
> > pg_dump --where "bar:created_at >= 2018-05-01'"
>
> I am wondering how this works at parsing if the table name, or one of
> the columns includes a colon character :)
>
The proposed patch will handle quoted identifiers. E.g. the following will
work just fine:
pg_dump --where 'table:"c
like:
pg_dump --where "bar:created_at >= 2018-05-01'"
On Mon, Jul 2, 2018 at 11:27 AM, Robert Haas wrote:
> On Fri, Jun 29, 2018 at 8:09 AM, Surafel Temesgen
> wrote:
> > hey,
> > i am reviewing this patch
> > On Thu, May 31, 2018 at 4:49 AM, C
After some consideration, I've created a new patch that addresses even more
of the various concerns.
Most notably, the command-line option is shortened to simply --where, which
is much easier to read and understand,
and matches the earlier proposal [1].
> bool
> -simple_oid_list_member(SimpleO
>
> pg_dump.c:2323:2: warning: ISO C90 forbids mixed declarations and code
> [-Wdeclaration-after-statement]
> char *filter_clause = NULL;
> ^
>
> You need to declare this variable at the top of its scope. If you're
> using GCC or Clang you might consider building with COPT=-Werror so
> that a
Ah yes, thanks. I did in fact have colors enabled.
I've attached a new patch generated by `git format-patch`. Hopefully
that's correct.
On Mon, May 21, 2018 at 4:00 PM, Thomas Munro wrote:
> On Tue, May 22, 2018 at 4:05 AM, Stephen Frost wrote:
> > * Carter Thaxton (carte
> How would you handle foreign keys? It seems easier to produce a dump
> that won't restore.
>
This proposal will not attempt to be smart about foreign keys or anything
like that. I don't believe that would even be expected.
> We have the existing options:
> > --include-table=table(and its
Hello,
I've only taken a quick look but I don't see any regression tests, for
> starters, and it's not clear if this can be passed multiple times for
> one pg_dump run (I'd certainly hope that it could be...).
>
Yes, this will absolutely accept multiple options for one run, which is how
I'd imagi
Many times I've wanted to export a subset of a database, using some sort of
row filter condition on some of the large tables. E.g. copying a
production database to a staging environment, but with some time series
data only from the past month.
We have the existing options:
--include-table=table
