Thread: Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation
Peter Eisentraut <peter_e@gmx.net> writes:
> Replace duplicate_oids with Perl implementation
> It is more portable, more robust, and more readable.
> From: Andrew Dunstan <andrew@dunslane.net>
What about unused_oids?
regards, tom lane
On 10/11/2013 03:57 AM, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> Replace duplicate_oids with Perl implementation >> It is more portable, more robust, and more readable. >> From: Andrew Dunstan <andrew@dunslane.net> > What about unused_oids? > > Here's a quick version I whipped up along the same lines that you can play with. There's probably a good case for combining them. cheers andrew
Attachment
Andrew Dunstan <andrew@dunslane.net> writes:
> On 10/11/2013 03:57 AM, Tom Lane wrote:
>> What about unused_oids?
> Here's a quick version I whipped up along the same lines that you can
> play with.
> There's probably a good case for combining them.
Meh. To me, those two scripts are used in different scenarios, so
I'm not especially in favor of merging them.
regards, tom lane
On 10/11/13 3:57 AM, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> Replace duplicate_oids with Perl implementation >> It is more portable, more robust, and more readable. >> From: Andrew Dunstan <andrew@dunslane.net> > > What about unused_oids? We are not planning to put unused_oids in to the main build path, so there is much less of a need to make it more portable or robust. Also, as we have just (re-)learned, you cannot rely on /usr/bin/perl being there, so rewriting unused_oids in Perl would arguably make it less usable.
Peter Eisentraut <peter_e@gmx.net> writes:
> On 10/11/13 3:57 AM, Tom Lane wrote:
>> What about unused_oids?
> We are not planning to put unused_oids in to the main build path, so
> there is much less of a need to make it more portable or robust.
> Also, as we have just (re-)learned, you cannot rely on /usr/bin/perl
> being there, so rewriting unused_oids in Perl would arguably make it
> less usable.
I'd argue the opposite --- the existing shell-script version is entirely
useless to developers running on Windows, while they could use a Perl
version. Also, we've pretty much locked in the assumption that developers
will have Perl.
I've not actually looked at Andrew's script yet, but if it works I think
we should replace the shell script.
regards, tom lane
On Sun, Nov 10, 2013 at 1:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'd argue the opposite --- the existing shell-script version is entirely > useless to developers running on Windows, while they could use a Perl > version. Also, we've pretty much locked in the assumption that developers > will have Perl. +1. -- Peter Geoghegan
On 11/10/2013 04:16 PM, Peter Geoghegan wrote: > On Sun, Nov 10, 2013 at 1:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'd argue the opposite --- the existing shell-script version is entirely >> useless to developers running on Windows, while they could use a Perl >> version. Also, we've pretty much locked in the assumption that developers >> will have Perl. > +1. > It might be a bit more portable if we replaced the shebang lines on perl scripts with #!/bin/env perl That's probably worth considering. MSVC users would still have to call "perl scriptname" or possibly "\path\to\perl scriptname", but I think that's OK, and they will have to do that anyway. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> It might be a bit more portable if we replaced the shebang lines on perl
> scripts with
> #!/bin/env perl
Perhaps, if we're worried about people keeping perl somewhere other
than /usr/bin. However, the most likely reason for having a
/usr/local/bin/perl or whatever is that it's a newer and shinier one
than what's in /usr/bin. Since we're only interested in bog-standard
perl, there's no real reason for us to want to pick up the local one.
FWIW, there was a big discussion at Red Hat a few years ago about whether
to run around and do that to all perl/python scripts, and the outcome of
the discussion was that using env was deprecated, not encouraged. I don't
remember the reasoning in detail, but I think the core idea was that if a
distro knows they ship perl in /usr/bin, then inserting env into the
equation doesn't do anything but add cycles and failure modes. I'm not
sure that that argument applies too well to our scenario, but it's out
there. The particular application to this case might be: what makes
you so sure env is in /bin?
regards, tom lane
On Sun, Nov 10, 2013 at 6:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> It might be a bit more portable if we replaced the shebang lines on perl >> scripts with >> #!/bin/env perl > > Perhaps, if we're worried about people keeping perl somewhere other > than /usr/bin. However, the most likely reason for having a > /usr/local/bin/perl or whatever is that it's a newer and shinier one > than what's in /usr/bin. Since we're only interested in bog-standard > perl, there's no real reason for us to want to pick up the local one. > > FWIW, there was a big discussion at Red Hat a few years ago about whether > to run around and do that to all perl/python scripts, and the outcome of > the discussion was that using env was deprecated, not encouraged. I don't > remember the reasoning in detail, but I think the core idea was that if a > distro knows they ship perl in /usr/bin, then inserting env into the > equation doesn't do anything but add cycles and failure modes. I'm not > sure that that argument applies too well to our scenario, but it's out > there. The particular application to this case might be: what makes > you so sure env is in /bin? +1. If we're concerned about non-standard Perl locations, I think the right way to handle that is to design the makefiles to invoke Perl scripts using $(PERL) $(srcdir)/whatever.pl; and to make the Windows build scripts do the equivalent. We are, at least in some places, already doing that. IMV, the role of the #! line is just to cater to the less-likely scenario where someone wants to run one of those scripts outside the build process; if their perl happens to be in the standard location, they can do that as "./whatever.pl" rather than "perl whatever.pl". If their perl does not happen to be at that location, then I think it's anybody's guess what the #! line would need to be to save those three keystrokes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Sun, 2013-11-10 at 18:12 -0500, Tom Lane wrote: > Perhaps, if we're worried about people keeping perl somewhere other > than /usr/bin. However, the most likely reason for having a > /usr/local/bin/perl or whatever is that it's a newer and shinier one > than what's in /usr/bin. Since we're only interested in bog-standard > perl, there's no real reason for us to want to pick up the local one. After the Perl version of duplicate_oids was committed, some non-Windows build farm member failed because it didn't have perl in /usr/bin. So that appears to be a real issue. > The particular application to this case might be: what makes > you so sure env is in /bin? I don't have a /bin/env, but the normal invocation is /usr/bin/env anyway.
On Tue, 2013-11-12 at 10:02 -0500, Robert Haas wrote: > IMV, the role of the #! line is just to cater to > the less-likely scenario where someone wants to run one of those > scripts outside the build process; Let's remember that we are talking about unused_oids here.
On 11/12/2013 09:01 PM, Peter Eisentraut wrote: > On Sun, 2013-11-10 at 18:12 -0500, Tom Lane wrote: >> Perhaps, if we're worried about people keeping perl somewhere other >> than /usr/bin. However, the most likely reason for having a >> /usr/local/bin/perl or whatever is that it's a newer and shinier one >> than what's in /usr/bin. Since we're only interested in bog-standard >> perl, there's no real reason for us to want to pick up the local one. > After the Perl version of duplicate_oids was committed, some non-Windows > build farm member failed because it didn't have perl in /usr/bin. So > that appears to be a real issue. As Robert pointed out, The build process should be, and now is, invoking it via $(PERL), so how is this still an issue? cheers andrew
On Tue, 2013-11-12 at 21:30 -0500, Andrew Dunstan wrote: > As Robert pointed out, The build process should be, and now is, > invoking it via $(PERL), so how is this still an issue? unused_oids is not part of the build process.
On 11/12/2013 09:51 PM, Peter Eisentraut wrote: > On Tue, 2013-11-12 at 21:30 -0500, Andrew Dunstan wrote: >> As Robert pointed out, The build process should be, and now is, >> invoking it via $(PERL), so how is this still an issue? > unused_oids is not part of the build process. > > You quoted me out of context. Your prevuious para referred to duplicate_oids. What exactly is your argument, here? cheers andrew
On 11/12/13, 10:48 PM, Andrew Dunstan wrote: > You quoted me out of context. Your prevuious para referred to > duplicate_oids. ... which was in turn quoted out of context. ;-) > What exactly is your argument, here? If we change unused_oids to a Perl implementation, we will add additional inconvenience to users who don't have /usr/bin/perl in that exact location. Versus allowing use by users who don't have /bin/sh. I don't know what the ratio between those two camps is, among potential users of unused_oids. But most of the discussion so far appeared to be under the impression that unused_oids is called from a makefile, which is not correct.
On 11/13/2013 08:36 AM, Peter Eisentraut wrote: >> What exactly is your argument, here? > If we change unused_oids to a Perl implementation, we will add > additional inconvenience to users who don't have /usr/bin/perl in that > exact location. Versus allowing use by users who don't have /bin/sh. I > don't know what the ratio between those two camps is, among potential > users of unused_oids. According to my count we currently have 30 instances of scripts with this shebang line. That includes things not called from makefiles, such as pgindent. I don't recall this causing an issue. For any small group of people that might exists who don't have /usr/bin/perl, they have a simple workaround to call "perl unused_oids". Can we please get on with dealing with real problems? I don't believe this is one. cheers andrew