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
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 inconve
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
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
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 on
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.
--
Sent via pgsql-hackers
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
On Sun, Nov 10, 2013 at 6:12 PM, Tom Lane wrote:
> Andrew Dunstan 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
Andrew Dunstan 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
On 11/10/2013 04:16 PM, Peter Geoghegan wrote:
On Sun, Nov 10, 2013 at 1:07 PM, Tom Lane 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 assumpt
On Sun, Nov 10, 2013 at 1:07 PM, Tom Lane 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 Eisentraut 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/p
On 10/11/13 3:57 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Replace duplicate_oids with Perl implementation
>> It is more portable, more robust, and more readable.
>> From: Andrew Dunstan
>
> What about unused_oids?
We are not planning to put unused_oids in to the main build path, so
the
Andrew Dunstan 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
On 10/11/2013 03:57 AM, Tom Lane wrote:
Peter Eisentraut writes:
Replace duplicate_oids with Perl implementation
It is more portable, more robust, and more readable.
From: Andrew Dunstan
What about unused_oids?
Here's a quick version I whipped up along the same l
Peter Eisentraut writes:
> Replace duplicate_oids with Perl implementation
> It is more portable, more robust, and more readable.
> From: Andrew Dunstan
What about unused_oids?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Thu, Oct 10, 2013 at 8:23 PM, Peter Eisentraut wrote:
> Replace duplicate_oids with Perl implementation
>
> It is more portable, more robust, and more readable.
smilodon seems unhappy with this:
cd ../../../src/include/catalog && ./duplicate_oids
sh: ./duplicate_oids: not found
--
Robert Ha
17 matches
Mail list logo
