On Wed, 2025-06-18 at 10:43 -0500, Nathan Bossart wrote:
> IIUC the current proposal is to:
>
> * Dump/restore stats by default.
> * Keep the --no-statistics, --no-schema, and --no-data options.
> * Keep the --statistics-only, --schema-only, and --data-only options.
> * Remove the --with-statistic
On Wed, Jun 18, 2025 at 09:53:01AM -0700, Jeff Davis wrote:
> On Wed, 2025-06-18 at 10:43 -0500, Nathan Bossart wrote:
>> IIUC the current proposal is to:
>>
>> * Dump/restore stats by default.
>
> IIUC some people still object to this. Turning stats off by default was
> on the Open Items list. A
On Wed, 2025-06-18 at 10:43 -0500, Nathan Bossart wrote:
> IIUC the current proposal is to:
>
> * Dump/restore stats by default.
IIUC some people still object to this. Turning stats off by default was
on the Open Items list. At this point I think we need a pretty strong
consensus to override that
On Wed, Jun 18, 2025 at 08:29:16AM -0700, Jeff Davis wrote:
> Actually, I take that back, we can't just remove --no-statistics.
> Remember that statistics currently default to "on" for pg_restore even
> though they default "off" for pg_dump.
>
> So pg_restore still needs a way to turn stats off.
On Thu, 2025-06-12 at 08:58 -0700, Jeff Davis wrote:
> On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
> > If the idea is to remove all options for default behavior, we'd be
> > removing
> > --no-statistics, --with-data, and --with-schema at this point.
>
> That's OK with me.
Actually, I
On Mon, 2025-06-16 at 15:35 -0400, Corey Huinker wrote:
>
> I think this is the exact sort of confusion caused by having two of
> the three types default to on in all circumstances, and one default
> to off in one special circumstance.
That's certainly a part of the confusion, but the "--x-only"
On 2025/06/17 9:58, Nathan Bossart wrote:
On Mon, Jun 16, 2025 at 07:09:17PM -0400, Tom Lane wrote:
I find myself increasingly persuaded by Corey's point of view ...
+1
Can you clarify how using on-by-default would simplify things?
I'm not sure it actually makes the options simpler.
Rega
On 2025/06/17 4:35, Corey Huinker wrote:
I noticed that --statistics (i.e., the current --with-statistics) causes
statistics to be dumped even when used with --data-only or --schema-only.
So, as far as I understand, here are the possible combinations of dump
targets and options
On Mon, Jun 16, 2025 at 07:09:17PM -0400, Tom Lane wrote:
> I find myself increasingly persuaded by Corey's point of view ...
+1
--
nathan
Jeff Davis writes:
> Does it make any sense to be off by default in 18 and on in some later
> release?
Probably not, especially if part of the argument for on-by-default
is to allow simplification of the switch set. We don't get that
benefit if we ship with off-by-default, and we won't be able t
On Mon, 2025-06-16 at 16:09 -0500, Nathan Bossart wrote:
> So perhaps there's not as strong of a
> consensus as we thought. Maybe we should ask for any new/updated
> votes.
Does it make any sense to be off by default in 18 and on in some later
release?
Regards
Jeff Davis
On Mon, Jun 16, 2025 at 03:35:48PM -0400, Corey Huinker wrote:
> I think this is the exact sort of confusion caused by having two of the
> three types default to on in all circumstances, and one default to off in
> one special circumstance.
I revisited the main thread to see how folks voted. Ther
>
> I noticed that --statistics (i.e., the current --with-statistics) causes
> statistics to be dumped even when used with --data-only or --schema-only.
> So, as far as I understand, here are the possible combinations of dump
> targets and options:
>
Those should also be mutually exclusive, and I'
On 2025/06/14 5:32, Nathan Bossart wrote:
On Fri, Jun 13, 2025 at 08:58:04AM -0700, Jeff Davis wrote:
On Fri, 2025-06-13 at 09:39 +0900, Fujii Masao wrote:
By the way, if we keep --with-statistics in pg_dump, are we planning
to
continue using the --with-xxx naming pattern for new options tha
>
>
> Good point. Now that we are getting rid of some of the other options,
> we don't need to worry about consistency with them, and I think we
> should just use "--statistics".
The point of the --with flags was to future proof commands to preserve
behavior in case the defaults ever changed.
Th
>
> One of the challenges in the current case is that it is not obvious how
> --with-data, --no-data, --data-only etc. are connected. If that were
> clearer, then the way these options should combine or conflict would
> hopefully follow somewhat naturally.
>
They all should be mutually exclusive,
On Fri, Jun 13, 2025 at 08:58:04AM -0700, Jeff Davis wrote:
> On Fri, 2025-06-13 at 09:39 +0900, Fujii Masao wrote:
>> By the way, if we keep --with-statistics in pg_dump, are we planning
>> to
>> continue using the --with-xxx naming pattern for new options that
>> specify extra data to dump?
>
>
On Fri, 2025-06-13 at 09:39 +0900, Fujii Masao wrote:
> By the way, if we keep --with-statistics in pg_dump, are we planning
> to
> continue using the --with-xxx naming pattern for new options that
> specify extra data to dump?
Good point. Now that we are getting rid of some of the other options,
On Fri, 2025-06-13 at 07:22 +0200, Peter Eisentraut wrote:
> > I don't think it's simple to start using "last option wins"
> > behavior
> > now ...
> It makes sense to raise an error if the specified options cannot be
> consolidated in an obvious way.
To me, "last option wins" means that you don'
> On 13 Jun 2025, at 02:39, Fujii Masao wrote:
> By the way, if we keep --with-statistics in pg_dump, are we planning to
> continue using the --with-xxx naming pattern for new options that
> specify extra data to dump? I just wondered because pg_dump already has
> other naming styles like --seque
On 12.06.25 23:20, Jeff Davis wrote:
On Thu, 2025-06-12 at 21:16 +0200, Peter Eisentraut wrote:
Do we have other options that are order-sensitive?
I think most of them are. For example:
psql -p 5432 -p 5433
initdb --data-checksums --no-data-checksums
postgres --shared-buffers=1GB --shared-bu
On Thu, Jun 12, 2025 at 4:12 PM Corey Huinker
wrote:
(peacefully skimming thread...)
...
> If we're hot to remove options, how about we remove the sections flags?
> Their utility is reliant upon the user understanding exactly which things
> go in which section, and further assumes that everything
On 2025/06/12 23:52, Nathan Bossart wrote:
On Thu, Jun 12, 2025 at 10:18:56AM -0400, Robert Haas wrote:
On Fri, Jun 6, 2025 at 11:40 AM Nathan Bossart wrote:
On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
What is the purpose of the --with-data option? Dumping the data i
On 2025/06/13 6:12, Jeff Davis wrote:
On Thu, 2025-06-12 at 15:57 -0500, Nathan Bossart wrote:
FWIW I don't have a tremendously strong opinion about --statistics-
only.
Same here. I won't cast a vote on this particular issue, as long as the
functionality is available.
I prefer keeping it
On Thu, 2025-06-12 at 21:16 +0200, Peter Eisentraut wrote:
> > Do we have other options that are order-sensitive?
>
> I think most of them are. For example:
>
> psql -p 5432 -p 5433
> initdb --data-checksums --no-data-checksums
> postgres --shared-buffers=1GB --shared-buffers=2GB
Interesting. I
On Thu, 2025-06-12 at 15:57 -0500, Nathan Bossart wrote:
> FWIW I don't have a tremendously strong opinion about --statistics-
> only.
Same here. I won't cast a vote on this particular issue, as long as the
functionality is available.
Regards,
Jeff Davis
On Thu, Jun 12, 2025 at 04:39:00PM -0400, Corey Huinker wrote:
> On Thu, Jun 12, 2025 at 4:22 PM Nathan Bossart
> wrote:
>> I do think this is useful functionality, I only suggested removing it
>> because AFAICT it is redundant, i.e., you can accomplish the same thing
>> with --with-statistics --n
On Thu, Jun 12, 2025 at 4:22 PM Nathan Bossart
wrote:
> On Thu, Jun 12, 2025 at 04:12:35PM -0400, Corey Huinker wrote:
> > The use case for --statistics-only is to extract the existing statistics
> > for the tables and indexes that are involved in a given query that is
> > giving you problems, al
On Thu, Jun 12, 2025 at 04:12:35PM -0400, Corey Huinker wrote:
> The use case for --statistics-only is to extract the existing statistics
> for the tables and indexes that are involved in a given query that is
> giving you problems, allowing you to apply those statistics to an existing
> QA/dev dat
On Thu, Jun 12, 2025 at 1:36 PM Robert Haas wrote:
> On Thu, Jun 12, 2025 at 11:58 AM Jeff Davis wrote:
> > On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
> > > If the idea is to remove all options for default behavior, we'd be
> > > removing
> > > --no-statistics, --with-data, and --w
On Thu, Jun 12, 2025 at 10:07:05PM +0200, Laurenz Albe wrote:
> I must be missing something, but I think --no-statistics is sorely needed.
> How else can I get the effect of
>
> pg_dump --no-statistics mydb
This was recently changed to be the default behavior (see commit 34eb2a8).
--
nathan
On Thu, 2025-06-12 at 13:36 -0400, Robert Haas wrote:
> On Thu, Jun 12, 2025 at 11:58 AM Jeff Davis wrote:
> > On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
> > > If the idea is to remove all options for default behavior, we'd be
> > > removing
> > > --no-statistics, --with-data, and --
On 12.06.25 17:14, Jeff Davis wrote:
On Thu, 2025-06-12 at 15:47 +0200, Peter Eisentraut wrote:
My initial guess was that --with-data can override --no-data. That
would have been pretty standard "last option wins" behavior. But
pg_dump rejects that. Personally, I think that is kind of wrong.
On Thu, Jun 12, 2025 at 11:58 AM Jeff Davis wrote:
> On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
> > If the idea is to remove all options for default behavior, we'd be
> > removing
> > --no-statistics, --with-data, and --with-schema at this point.
>
> That's OK with me.
Same.
> >
On Thu, Jun 12, 2025 at 08:58:15AM -0700, Jeff Davis wrote:
> On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
>> If the idea is to remove all options for default behavior, we'd be
>> removing
>> --no-statistics, --with-data, and --with-schema at this point.
>
> That's OK with me.
>
>>
On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
> If the idea is to remove all options for default behavior, we'd be
> removing
> --no-statistics, --with-data, and --with-schema at this point.
That's OK with me.
> Maybe we
> could go a step further and even rip out --statistics-only (i
On Thu, 2025-06-12 at 10:18 -0400, Robert Haas wrote:
> Am I too late to propose ripping this out?
As long as we keep the functionality, I'm fine changing the
options/names around at this point.
Regards,
Jeff Davis
On Thu, 2025-06-12 at 15:47 +0200, Peter Eisentraut wrote:
> My initial guess was that --with-data can override --no-data. That
> would have been pretty standard "last option wins" behavior. But
> pg_dump rejects that. Personally, I think that is kind of wrong.
Do we have other options that a
On Thu, Jun 12, 2025 at 10:18:56AM -0400, Robert Haas wrote:
> On Fri, Jun 6, 2025 at 11:40 AM Nathan Bossart
> wrote:
>> On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
>> > What is the purpose of the --with-data option? Dumping the data is the
>> > default. Is this to overri
On 2025/06/12 22:47, Peter Eisentraut wrote:
On 06.06.25 17:39, Nathan Bossart wrote:
On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
We have
-a, --data-only dump only the data, not the schema or statistics
--no-data do not dump data
--with-data
On Fri, Jun 6, 2025 at 11:40 AM Nathan Bossart wrote:
> On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
> > We have
> >
> > -a, --data-only dump only the data, not the schema or statistics
> > --no-datado not dump data
> > --with-data dump the data
On 06.06.25 17:39, Nathan Bossart wrote:
On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
We have
-a, --data-only dump only the data, not the schema or statistics
--no-datado not dump data
--with-data dump the data # this one is new
(and the
On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
> We have
>
> -a, --data-only dump only the data, not the schema or statistics
> --no-datado not dump data
> --with-data dump the data # this one is new
>
> (and there is also --section=data), and t
43 matches
Mail list logo
