On Mon, Aug 5, 2019 at 11:13 PM Tom Lane wrote:
> > Right. Besides, adding something along the lines Michael described
> > necessitates fixing the problems that it creates. We'll run out of
> > blocks of 5 contiguous OIDs (or whatever) far sooner than we'll run
> > out of single OIDs.
>
> Well,
Peter Geoghegan writes:
> On Mon, Aug 5, 2019 at 10:41 PM Tom Lane wrote:
>> But as long as the script
>> tells you how many OIDs are available, what's the problem? Just run
>> it again if you want a different suggestion, or make your own choice.
> Right. Besides, adding something along the
On Mon, Aug 5, 2019 at 10:41 PM Tom Lane wrote:
> There was some discussion of that upthread, and Peter argued that many
> patches only need one OID anyway so why try harder. I'm not totally
> sure I buy that --- my sense is that even simple patches tend to add
> several related functions not
Peter Geoghegan writes:
> On Mon, Aug 5, 2019 at 8:47 PM Michael Paquier wrote:
>> Wouldn't it be better to keep some room at the end of the allowed
>> array? Or at least avoid suggesting ranges where there is less than
>> 3-5 OIDs available consecutively.
> Not in my view. There is value in
On Mon, Aug 5, 2019 at 8:47 PM Michael Paquier wrote:
> So it would be possible to get 9998- as suggestion. In which
> case, one can basically finish with this message:
> Suggested random unused OID: (1 consecutive OID(s) available
> starting here)
I strongly doubt that this will ever
On Mon, Aug 05, 2019 at 09:00:26PM +0200, Julien Rouhaud wrote:
> Thanks!
What you have committed does that:
+do
+{
+ $suggestion = int(8000 + rand(2000));
+} while (grep(/^$suggestion$/, @{$oids}));
So it would be possible to get 9998- as suggestion. In which
case, one can basically
On Mon, Aug 5, 2019 at 8:51 PM Peter Geoghegan wrote:
>
> Pushed a version with similar wording just now.
Thanks!
On Fri, Aug 2, 2019 at 1:28 PM Julien Rouhaud wrote:
> I'm fine with it!
Pushed a version with similar wording just now.
Thanks!
--
Peter Geoghegan
On Sat, Aug 3, 2019 at 7:48 PM Michael Paquier wrote:
> Why choosing a random position within [8000,]? This leads to the
> following messages for example with multiple runs, which is confusing:
> Suggested random unused OID: 9473 (527 consecutive OID(s) available
> Suggested random unused
On Sat, Aug 03, 2019 at 11:40:24AM +0200, Julien Rouhaud wrote:
> I probably write less perl than Michael, but it looks just fine to me.
Indentation with pgperltidy complains with the attached diff (based on
top of v4).
+printf "Patches should use a more-or-less consecutive range of OIDs.\n";
On Sat, Aug 3, 2019 at 2:40 AM Peter Geoghegan wrote:
>
> On Fri, Aug 2, 2019 at 3:52 PM Tom Lane wrote:
> > Better ... but I'm the world's second worst Perl programmer,
> > so I have little to say about whether it's idiomatic.
>
> Perhaps Michael can weigh in here? I'd rather hear a second
On Fri, Aug 2, 2019 at 3:52 PM Tom Lane wrote:
> Better ... but I'm the world's second worst Perl programmer,
> so I have little to say about whether it's idiomatic.
Perhaps Michael can weigh in here? I'd rather hear a second opinion on
v4 of the patch before proceeding.
--
Peter Geoghegan
Peter Geoghegan writes:
> How about the attached? I've simply removed the "if ($oid > $prev_oid
> + 2)" test.
Better ... but I'm the world's second worst Perl programmer,
so I have little to say about whether it's idiomatic.
regards, tom lane
On Fri, Aug 2, 2019 at 3:19 PM Tom Lane wrote:
> The "if ($oid > $prev_oid + 2)" test seems unnecessary.
> It's certainly wrong to keep iterating beyond the first
> oid that's > $suggestion.
Sorry. That was just carelessness on my part. (Being the world's worst
Perl programmer is no excuse.)
Peter Geoghegan writes:
> Attached is v3, which implements your suggestion, generating output
> like the above. I haven't written a line of Perl in my life prior to
> today, so basic code review would be helpful.
The "if ($oid > $prev_oid + 2)" test seems unnecessary.
It's certainly wrong to
On Fri, Aug 2, 2019 at 2:52 PM Isaac Morland wrote:
> Noob question here: why not start with the next unused OID in the range, and
> on the other hand reserve the range for sequentially-assigned values?
The general idea is to avoid OID collisions while a patch is under
development. Choosing a
On Fri, 2 Aug 2019 at 16:49, Tom Lane wrote:
> Peter Geoghegan writes:
> > I've taken your patch, and changed the wording a bit. I think that
> > it's worth being a bit more explicit. The attached revision produces
> > output that looks like this:
>
> > Patches should use a more-or-less
On Fri, Aug 2, 2019 at 1:49 PM Tom Lane wrote:
> Maybe s/make a/start with/ ?
> Also, once people start doing this, it'd be unfriendly to suggest
> 9099 if 9100 is already committed. There should be some attention
> to *how many* consecutive free OIDs will be available if one starts
> at the
Peter Geoghegan writes:
> I've taken your patch, and changed the wording a bit. I think that
> it's worth being a bit more explicit. The attached revision produces
> output that looks like this:
> Patches should use a more-or-less consecutive range of OIDs.
> Best practice is to make a random
Le ven. 2 août 2019 à 20:12, Peter Geoghegan a écrit :
> On Fri, Aug 2, 2019 at 1:42 AM Julien Rouhaud wrote:
> > Trivial patch for that attached.
>
> Thanks!
>
> > The output is now like:
> >
> > [...]
> > Using an oid in the 8000- range is recommended.
> > For instance: 9427
> >
> >
On Fri, Aug 2, 2019 at 1:42 AM Julien Rouhaud wrote:
> Trivial patch for that attached.
Thanks!
> The output is now like:
>
> [...]
> Using an oid in the 8000- range is recommended.
> For instance: 9427
>
> (checking that the suggested random oid is not used yet.)
I've taken your patch,
On Fri, Aug 2, 2019 at 6:21 AM Michael Paquier wrote:
>
> On Thu, Aug 01, 2019 at 06:59:06PM -0700, Peter Geoghegan wrote:
> > Seems like I should propose a patch this time around. I don't do Perl,
> > but I suppose I could manage something as trivial as this.
>
> Well, that new project policy is
On Thu, Aug 01, 2019 at 06:59:06PM -0700, Peter Geoghegan wrote:
> Seems like I should propose a patch this time around. I don't do Perl,
> but I suppose I could manage something as trivial as this.
Well, that new project policy is not that well-advertised then, see
for example the recent
Peter Geoghegan writes:
> Is it within the discretion of committers to not use the reserved
> range? It seems preferable for everybody to consistently use the
> reserved OID range.
I think it's up to the committer in the end. But if someone submits
a patch using high OIDs, I for one would not
On Thu, Aug 1, 2019 at 1:57 PM Julien Rouhaud wrote:
> Huge +1. Last time I had to pick a new oid it took me ages to find
> the correct range for that. The script could even suggest a random
> free oid in the range, for extra laziness as you also suggested in the
> almost exact same mail at
>
On Thu, Aug 1, 2019 at 10:37 PM Peter Geoghegan wrote:
>
> I pushed a commit that required a new pg_proc entry today. Had I not
> been involved with the work that became commit a6417078, I would
> definitely not have used an OID from the range reserved for devel
> system catalogs (8000 - 8999).
I pushed a commit that required a new pg_proc entry today. Had I not
been involved with the work that became commit a6417078, I would
definitely not have used an OID from the range reserved for devel
system catalogs (8000 - 8999). As I understand it, this is now
standard practice.
Perhaps
27 matches
Mail list logo
