Tom Lane wrote:
Log Message:
---
Get rid of the need for manual maintenance of the initial contents of
pg_attribute, by having genbki.pl derive the information from the various
catalog header files. This greatly simplifies modification of the
bootstrapped catalogs.
This patch finally
On Tue, Jan 5, 2010 at 12:24 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
Tom Lane wrote:
Log Message:
---
Get rid of the need for manual maintenance of the initial contents of
pg_attribute, by having genbki.pl derive the information from the various
catalog header files.
Robert Haas wrote:
On Tue, Jan 5, 2010 at 12:24 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
Tom Lane wrote:
Log Message:
---
Get rid of the need for manual maintenance of the initial contents of
pg_attribute, by having genbki.pl derive the information from the various
Robert Haas robertmh...@gmail.com writes:
Is there by any chance some other, conflicting Catalog.pm on that machine?
Even if there is, shouldn't the use of perl -I ensure our version gets
loaded?
Also, Stefan's log shows that it got through genbki.pl, so whatever the
problem is, I don't think
On Tue, Jan 5, 2010 at 12:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Is there by any chance some other, conflicting Catalog.pm on that machine?
Even if there is, shouldn't the use of perl -I ensure our version gets
loaded?
I would certainly think so.
Robert Haas robertmh...@gmail.com writes:
Beats me. I don't have any other ideas at the moment.
Stefan, could you try adding some debugging printouts to the
Gen_fmgrtab.pl script to see how far it gets before blowing up?
regards, tom lane
--
Sent via pgsql-hackers
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Beats me. I don't have any other ideas at the moment.
Stefan, could you try adding some debugging printouts to the
Gen_fmgrtab.pl script to see how far it gets before blowing up?
did that and it seems the problem is in the loop that
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
did that and it seems the problem is in the loop that does:
foreach my $row (@$data)
{
# To construct fmgroids.h and fmgrtab.c, we need to inspect some
# of the individual data fields. Just splitting on whitespace
Huh. It's
Stefan Kaltenbrunner escribió:
foreach my $row (@$data)
{
# To construct fmgroids.h and fmgrtab.c, we need to inspect some
# of the individual data fields. Just splitting on whitespace
# won't work, because some quoted fields might contain internal
# whitespace. We
Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
did that and it seems the problem is in the loop that does:
foreach my $row (@$data)
{
# To construct fmgroids.h and fmgrtab.c, we need to inspect some
# of the individual data fields. Just splitting on
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
yeah it is probably some strange platform specific issue - however with
some help from the IRC channel I came up with the following patch that
considerable reduces the memory bloat (but still needs ~55MB max) and
allows the build to
Garick Hamlin gham...@isc.upenn.edu writes:
On Tue, Jan 05, 2010 at 02:02:51PM -0500, Tom Lane wrote:
I'm not nearly good enough in Perl to be sure about the semantics
of this loop. Is it possible that it's changing the global contents
of the @$data structure, rather than just hacking a local
On Tue, Jan 05, 2010 at 02:02:51PM -0500, Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
did that and it seems the problem is in the loop that does:
foreach my $row (@$data)
{
# To construct fmgroids.h and fmgrtab.c, we need to inspect some
# of the
Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
yeah it is probably some strange platform specific issue - however with
some help from the IRC channel I came up with the following patch that
considerable reduces the memory bloat (but still needs ~55MB max) and
allows the
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
What about Alvaro's idea of adding
$row = undef;
at the bottom of the loop? That seems marginally less ugly...
not sure I want to argue about the ugliness of perl but that has the
same effect as my patch so either way would do to get
Tom Lane wrote:
I'm not nearly good enough in Perl to be sure about the semantics
of this loop. Is it possible that it's changing the global contents
of the @$data structure, rather than just hacking a local copy of
each row before pushing some values into @fmgr?
That's exactly what it
Andrew Dunstan and...@dunslane.net writes:
Something like:
(my $bkival = $row-{bki_values}) =~ s/[^]*/xxx/g;
my $atts = {};
@{$att...@attnames} = split /\s+/, $bkival;
might work better.
I committed Alvaro's suggestion (undef at the bottom), but feel
free to clean it up if you
17 matches
Mail list logo
