> On Oct 9, 2015, at 2:17 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Oct 8, 2015 at 12:43 PM, David Christensen <da...@endpoint.com> wrote:
>> 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.
> Right, but I think it ought to be Catalog.pm's job to parse the config
> file.  The job of complaining about what it contains is a job worth
> doing, but it's not the same job.  Personally, I hate it when parsers
> take it upon themselves to do semantic analysis, because then what
> happens if you want to write, say, a tool to repair a broken file?
> You need to be able to read it in without erroring out so that you can
> frob whatever's busted and write it back out, and the parser is
> getting in your way.  Maybe that's not going to come up here, but I'm
> just explaining my general philosophy on these things…

Not disagreeing with you in general, but this is a very specific use case and I 
think we lose the niceness of being able to tie back to the specific line 
number for the file in question—the alternative being to track that information 
as well in a separate structure which we then pass around, which seems like 

The only two consumers of the catalog-specific data lines (at least via direct 
access in Perl) are genbki.pl and Gen_fmgtab.pl.  We would need to add these 
checks anyway in both call sites, so to me it seems important to bail early if 
we see any issues, so I think putting the failure as soon as we notice it with 
as much context to fix it (i.e., as written) is the right choice.  We can 
certainly pretty up the messages.

The consistency of the system catalogs in the development state is something 
that is fundamental to whether there is any information that is sensible to 
query, and by definition if we are missing columns in the data rows this is a 
mistake and whatever parsed data in here will be worse than useless (as who 
knows the order of the missing column, data can/will end up being misaligned).  
Thus I don’t believe that we’d want other (hypothetical) Catalog.pm consumers 
to try to use data that we know is bad.
David Christensen
PostgreSQL Team Manager
End Point Corporation

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

Reply via email to