Re: [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line
От | David Christensen |
---|---|
Тема | Re: [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line |
Дата | |
Msg-id | 66275451-7BCC-4CA4-9DE7-C59A74192EC5@endpoint.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] Teach Catalog.pm how many attributes there
should be per DATA() line
|
Список | pgsql-hackers |
> On Oct 8, 2015, at 11:23 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > On Tue, Oct 6, 2015 at 9:15 AM, David Christensen <david@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 wasunaware 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 statethis condition should never trigger. -- David Christensen PostgreSQL Team Manager End Point Corporation david@endpoint.com 785-727-1171
В списке pgsql-hackers по дате отправления: