Re: [COMMITTERS] pgsql: Establish conventions about global object names used in regressi
От | Tom Lane |
---|---|
Тема | Re: [COMMITTERS] pgsql: Establish conventions about global object names used in regressi |
Дата | |
Msg-id | 22766.1569131537@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pgsql: Establish conventions about global object names used in regressi (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
Peter Geoghegan <pg@bowt.ie> writes: > On Sun, Jul 17, 2016 at 3:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Establish conventions about global object names used in regression tests. > I gather that this patch was intended to be cosmetic and mechanical. > Why, then, did it result in a certain amount of seemingly > more-than-cosmetic test output changes for certain ecpg tests? Hm ... it's been awhile, but I think what was happening there is that the previous coding created both a user and a database named "connectdb", and then checked if exec sql connect to @localhost as main user connectdb; would work. The naming convention I was putting in didn't allow for identical DB and user names, and it didn't seem to me that it was worth overriding that convention to keep this particular test result the same. The error output still proves that ecpg *tried* to connect to the database named the same as the user, which is the only real point of this test case as compared to its siblings. And why not test the error path, anyway? > I'm asking about this because I find that "make installcheck-world" > sometimes fails at this point when run against my local installation > -- the test "test connect/test" reliably fails. Um, you're confusing me ... is it "sometimes", or is it "reliably"? It does seem like there might be something to poke at here. We never did figure out quite what the other reporter was seeing. Given the lack of overlap of user and database names, we can be pretty darn certain that the test case shouldn't accidentally succeed due to timing issues. I wonder if there could be some kind of uninitialized-variable bug inside ecpg that lets it sometimes connect to the wrong DB name (perhaps one it'd previously connected to) if the DB name is omitted from the command? regards, tom lane
В списке pgsql-committers по дате отправления: