On Mon, 2008-07-21 at 19:19 -0400, Tom Lane wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Are there use cases for just --omit-post-load or --omit-pre-load?
>
> Probably not many. The thing that's bothering me is the
> action-at-a-distance property of the positive-logic switches.
> How a
On Mon, Jul 21, 2008 at 03:43:11AM -0400, Tom Lane wrote:
> daveg <[EMAIL PROTECTED]> writes:
> > On Sun, Jul 20, 2008 at 02:50:50PM -0400, Tom Lane wrote:
> >> In most cases our policy has been that pg_dumpall should accept and pass
> >> through any pg_dump option for which it's sensible to do so.
Stephen Frost <[EMAIL PROTECTED]> writes:
> Are there use cases for just --omit-post-load or --omit-pre-load?
Probably not many. The thing that's bothering me is the
action-at-a-distance property of the positive-logic switches.
How are we going to explain this?
"By default, --schema-pre-
Tom, et al,
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Ah, I see. No objection to those switch names, at least assuming we
> want to stick to positive-logic switches. What did you think of the
> negative-logic suggestion (--omit-xxx)?
My preference is for positive-logic switches in general. The p
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> As far as the documentation/definition aspect goes, I think it should
>> just say the parts are
>> * stuff needed before you can load the data
>> * the data
>> * stuff needed after loading the data
> Even that is
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2008-07-21 at 11:36 +0530, Pavan Deolasee wrote:
>> I think we should try at least one or two possible optimizations and
>> get some numbers before we jump and make substantial changes to the
>> code.
> You know you're suggesting months of tests an
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Thanks for applying patch. I think that hash index "upgradebility" is
> currently broken or it will be with new hash index improvement. But if
> I think about it it does not make sense to break compatibility by this
> patch first.
Right, my point exactly
Tom,
* Tom Lane ([EMAIL PROTECTED]) wrote:
> As far as the documentation/definition aspect goes, I think it should
> just say the parts are
> * stuff needed before you can load the data
> * the data
> * stuff needed after loading the data
> and not try to be any more specific tha
Simon,
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> > I hadn't realized that Simon was using "pre-schema" and "post-schema"
> > to name the first and third parts. I'd agree that this is confusing
> > nomenclature: it looks like it's trying to say that the data is the
> > schema, and the schema is n
On Mon, 2008-07-21 at 11:36 +0530, Pavan Deolasee wrote:
> I think we should try at least one or two possible optimizations and
> get some numbers before we jump and make substantial changes to the
> code.
You know you're suggesting months of tests and further discussion. :-(
I'll fix the bug,
Tom Lane napsal(a):
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
... That macro is actually doing the
same thing as PageGetContents, so I switched to using that. As that
moves the data sligthly on those bitmap pages, I guess we'll need a
catversion bump.
I'm amazed that Zdenek didn't sc
On Mon, 2008-07-21 at 07:46 -0400, Stephen Frost wrote:
> * Simon Riggs ([EMAIL PROTECTED]) wrote:
> > The options split the dump into 3 parts that's all: before the load, the
> > load and after the load.
> >
> > --schema-pre-load says
> > "Dumps exactly what --schema-only would dump, but only th
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Maybe invert the logic?
>> --omit-pre-data
>> --omit-data
>> --omit-post-data
> Please, no. Negative logic seems likely to cause endless confusion.
I think it might actually be less confusing, because with this approach,
each switch
Simon Riggs wrote:
> On Fri, 2008-07-18 at 01:44 -0400, Tom Lane wrote:
> > I agree, this is important for visibility into what's happening.
> > The string isn't getting translated so I don't see any big downside
> > to applying the patch in back branches.
>
> Patches for 8.3 and CVS HEAD.
Appli
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
I also suggested having three options
--want-pre-schema
--want-data
--want-post-schema
so we could ask for any or all parts in the one dump. --data-only and
--schema-only are negative options so don't allow this.
(I don't like those na
Hi,
Here is the lastest WITH RECURSIVE patches against 2007/07/17 CVS (CVS
HEAD won't compile for me).
This version includes regression tests and is almost ready for commit
IMO.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
recursive_query.patch.gz
Description: Binary data
--
Sent via pgsql-patches mai
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> The options split the dump into 3 parts that's all: before the load, the
> load and after the load.
>
> --schema-pre-load says
> "Dumps exactly what --schema-only would dump, but only those
> statements before the data load."
>
> What is it you are sugge
daveg <[EMAIL PROTECTED]> writes:
> On Sun, Jul 20, 2008 at 02:50:50PM -0400, Tom Lane wrote:
>> In most cases our policy has been that pg_dumpall should accept and pass
>> through any pg_dump option for which it's sensible to do so. I did not
>> make that happen but it seems it'd be a reasonable f
On Sun, Jul 20, 2008 at 02:50:50PM -0400, Tom Lane wrote:
> daveg <[EMAIL PROTECTED]> writes:
> > Here is an updated version of this patch against head. It builds, runs and
> > functions as expected. I did not build the sgml.
>
> Applied with mostly minor cosmetic improvements --- the only actual
19 matches
Mail list logo