> On Oct 8, 2015, at 11:23 AM, Robert Haas <robertmh...@gmail.com> wrote:
> 
> On Tue, Oct 6, 2015 at 9:15 AM, David Christensen <da...@endpoint.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
da...@endpoint.com
785-727-1171







-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to