On Fri, Sep 27, 2019 at 3:03 PM Tom Lane wrote:
> > Please do.
>
> After looking closer at the code in pg_regress.c, I'm wondering a bit
> about PGSERVICE. A setting for that might certainly bring in a value
> for the database name, but I don't think we can just summarily unset it.
> I don't plan
Peter Geoghegan writes:
> On Fri, Sep 27, 2019 at 2:39 PM Tom Lane wrote:
>> I think I just forgot about this thread. Shall we change it in HEAD
>> and see what happens? Maybe backpatch, but not till after 12.0 is out.
> Please do.
After looking closer at the code in pg_regress.c, I'm wonderi
On 2019-09-27 14:43:00 -0700, Peter Geoghegan wrote:
> On Fri, Sep 27, 2019 at 2:39 PM Tom Lane wrote:
> > I think I just forgot about this thread. Shall we change it in HEAD
> > and see what happens? Maybe backpatch, but not till after 12.0 is out.
>
> Please do.
+1
On Fri, Sep 27, 2019 at 2:39 PM Tom Lane wrote:
> I think I just forgot about this thread. Shall we change it in HEAD
> and see what happens? Maybe backpatch, but not till after 12.0 is out.
Please do.
--
Peter Geoghegan
Peter Geoghegan writes:
> On Sun, Mar 18, 2018 at 5:28 PM Tom Lane wrote:
>> Don't think I like ecpg's tests behaving differently in this respect
>> than the rest of them do; that seems like a recipe for unrecognized
>> security issues.
>>
>> If nobody can think of a positive reason for pg_regre
On Sun, Mar 18, 2018 at 5:28 PM Tom Lane wrote:
> Don't think I like ecpg's tests behaving differently in this respect
> than the rest of them do; that seems like a recipe for unrecognized
> security issues.
>
> If nobody can think of a positive reason for pg_regress not to
> unset PGDATABASE unco
Andres Freund writes:
> On 2018-03-18 19:30:33 -0400, Tom Lane wrote:
>> Is it sane for pg_regress to unset PGDATABASE unconditionally? Not
>> sure, but if we're generally always specifying a value, maybe that's
>> OK.
> I'm not sure either. I wonder whether we should just make ecpg's
> pg_regr
Hi,
On 2018-03-18 19:30:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On March 18, 2018 4:06:18 PM PDT, Tom Lane wrote:
> >> Hm ... pg_regress unsets PGDATABASE, along with the other related
> >> environment variables, when it has a temp installation but not
> >> when it doesn't. So wha
Andres Freund writes:
> On March 18, 2018 4:06:18 PM PDT, Tom Lane wrote:
>> Hm ... pg_regress unsets PGDATABASE, along with the other related
>> environment variables, when it has a temp installation but not
>> when it doesn't. So what I don't understand is why your environment
>> doesn't also
On March 18, 2018 4:06:18 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> I got a bit confused running installcheck-world and seeing ecpg
>> failures like:
>> ...
>> A bit of pondering pointed me towards my environment's
>> PGDATABASE=postgres being to blame. Unsetting that makes the test
>>
Andres Freund writes:
> I got a bit confused running installcheck-world and seeing ecpg
> failures like:
> ...
> A bit of pondering pointed me towards my environment's
> PGDATABASE=postgres being to blame. Unsetting that makes the test
> succeed.
Hm ... pg_regress unsets PGDATABASE, along with th
Hi,
I got a bit confused running installcheck-world and seeing ecpg
failures like:
[NO_PID]: ECPGconnect: opening database on port
for user regress_ecpg_user2
[NO_PID]: sqlca: code: 0, state: 0
-[NO_PID]: ECPGconnect: could not open database: FATAL: database
"regress_ecpg_user2" does
12 matches
Mail list logo
