Re: Bootstrap DATA is a pita

On Wed, Mar 4, 2015 at 2:27 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Andrew Dunstan wrote:
>> On 03/04/2015 09:51 AM, Robert Haas wrote:
>> >On Wed, Mar 4, 2015 at 9:06 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> >>>and make it harder to compare entries by grepping out some common
>> >>>substring.
>> >>Could you give an example of the sort of thing you wish to do?
>> >e.g. grep for a function name and check that all the matches have the
>> >same volatility.
>>
>> I think grep will be the wrong tool for this format, but if we're settling
>> on a perl format, a few perl one-liners should be able to work pretty well.
>> It might be worth shipping a small perl module that provided some functions,
>> or a script doing common tasks (or both).
>
> I was going to say the same thing. We need to make sure that the output
> format of those oneliners is consistent, though -- it wouldn't be nice
> if adding one column with nondefault value to a dozen of entries changes
> the formatting of other entries. For example, perhaps declare that the
> order of entries is alphabetical or it matches something declared at the
> start of the file.
>
> From that POV, I don't like the idea of having multiple columns for a
> sigle entry in a single line; adding more columns means that eventually
> we're going to split lines that have become too long in a different
> place, which would reformat the whole file; not very nice. But maybe
> this doesn't matter if we decree that changing the column split is a
> manual chore rather than automatic, because then it can be done in a
> separate mechanical commit after the extra column is added.
>
> BTW one solution to the merge problem is to have unique separators for
> each entry. For instance, instead of
>
> } -- this is the end of the previous entry
> ,
> {
> oid = 2233,
> proname = array_append,
>
> we could have
> } # array_prepend 2232
> ,
> } # array_append 2233
> oid = 2233,
> proname = array_append,
>
> where the funcname-oid comment is there to avoid busted merges. The
> automatic editing tools make sure that those markers are always present.

Speaking from entirely too much experience, that's not nearly enough.
git only needs 3 lines of context to apply a hunk with no qualms at
all, and it'll shade that to just 1 or 2 with little fanfare. If your
pg_proc entries are each 20 lines long, this sort of thing will
provide little protection.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company