> 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
