Re: [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

From: David Christensen <david(at)endpoint(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line
Date: 2015-10-08 16:43:05
Message-ID: 66275451-7BCC-4CA4-9DE7-C59A74192EC5@endpoint.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On Oct 8, 2015, at 11:23 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Oct 6, 2015 at 9:15 AM, David Christensen <david(at)endpoint(dot)com> wrote:
>> Fixes a build issue I ran into while adding some columns to system tables:
>>
>> Throws a build error if we encounter a different number of fields in a
>> DATA() line than we expect for the catalog in question.
>>
>> Previously, it was possible to silently ignore any mismatches at build
>> time which could result in symbol undefined errors at link time. Now
>> we stop and identify the infringing line as soon as we encounter it,
>> which greatly speeds up the debugging process.
>
> I think this is a GREAT idea, but this line made me laugh[1]:
>
> + warn "No Natts defined yet, silently skipping check...\n";
>
> I suggest that we make that a fatal error. Like "Could not find
> definition Natts_pg_proc before start of DATA”.

That’s fine with me; my main consideration was to make sure nothing broke in the status quo, including dependencies I was unaware of.

> Secondly, I don't think we should check this at this point in the
> code, because then it blindly affects everybody who uses Catalog.pm.
> Let's pick one specific place to do this check. I suggest genbki.pl,
> inside the loop with this comment: "# Ordinary catalog with DATA
> line(s)"

I’m happy to move it around, but If everything is in order, how will this affect things at all? If we’re in a good state this condition should never trigger.
--
David Christensen
PostgreSQL Team Manager
End Point Corporation
david(at)endpoint(dot)com
785-727-1171

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2015-10-08 16:50:12 Re: RLS bug in expanding security quals
Previous Message Robert Haas 2015-10-08 16:33:54 Re: [PATCH] minor doc patch