Another review of URI for libpq, v7 submission - Mailing list pgsql-hackers

From Daniel Farina
Subject Another review of URI for libpq, v7 submission
Date
Msg-id CAAZKuFZ6d5aB8Tt-vq=xdCA4xEcLTDYK_d+G2VunpSuuqyKktA@mail.gmail.com
Whole thread Raw
Responses Re: Another review of URI for libpq, v7 submission
Re: Another review of URI for libpq, v7 submission
List pgsql-hackers
I reviewed this and so far have not found any serious problems,
although as is par for the course it contains some of the fiddly bits
involved in any string manipulations in C.  I made a few edits -- none
strictly necessary for correctness -- that the original author is free
audit and/or include[0]. I did put in some defensive programming
choices (instead of if/else if/elseif/else raise an error, even if the
latter is allegedly impossible) that I think are a good idea.

Loops around pointer increments are very fastidiously checked for
NUL-byteness, and those that aren't are carefully guarded by
invariants that seem like they should prevent an overrun.  The nature
of the beast, I suppose, short of giving libpq a "StringData" like
struct and a small lexer to make it more clear that a subtle overrun
is not creeping in.

One thing I found puzzling was that in the latest revision the tests
appeared to be broken for me: all "@" signs were translated to "(at)".Is that mangling applied by the archives, or
something?

The test suite neatly tries to copy pg_regress's general "make
installcheck" style, but it likes to use my username as the database
rather than the standard "regression" as seen by pg_regress.  It is
nice that a place to test connection strings and such is there, where
there was none before.

I am happy with the range and style of accepted URIs, and I think this
can stem the bleeding of the fragmentation already taking place at
large.

[0]: https://github.com/fdr/postgres/tree/uri, commit
e50ef375b7a731ca79bf5d3ca8b0bd69c97a9e71, aka the 'uri' branch

-- 
fdr


pgsql-hackers by date:

Previous
From: Gabriele Bartolini
Date:
Subject: Re: [PATCH] Support for foreign keys with arrays
Next
From: Yeb Havinga
Date:
Subject: Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my