Re: Bootstrap DATA is a pita - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Bootstrap DATA is a pita |
Date | |
Msg-id | CA+TgmoY1on5vbo=4L5aTkgH3XpDTF9SGiChHRakUioXL8WdLtg@mail.gmail.com Whole thread Raw |
In response to | Re: Bootstrap DATA is a pita (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Responses |
Re: Bootstrap DATA is a pita
|
List | pgsql-hackers |
On Wed, Mar 4, 2015 at 2:27 PM, Alvaro Herrera <alvherre@2ndquadrant.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@gmx.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
pgsql-hackers by date: