From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>, meskes(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Establish conventions about global object names used in regressi |
Date: | 2019-09-22 05:52:17 |
Message-ID: | 22766.1569131537@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Sun, Jul 17, 2016 at 3:43 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-09-22 06:02:18 | Re: [COMMITTERS] pgsql: Establish conventions about global object names used in regressi |
Previous Message | Peter Geoghegan | 2019-09-22 03:45:57 | Re: [COMMITTERS] pgsql: Establish conventions about global object names used in regressi |