Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fEZrk-0002wr-2k for pgsql-hackers@arkaria.postgresql.org; Fri, 04 May 2018 12:31:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fEZri-0001qm-DU for pgsql-hackers@arkaria.postgresql.org; Fri, 04 May 2018 12:31:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fEZri-0001qc-45 for pgsql-hackers@lists.postgresql.org; Fri, 04 May 2018 12:31:10 +0000 Received: from mail-lf0-x243.google.com ([2a00:1450:4010:c07::243]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fEZrZ-00014w-OI for pgsql-hackers@postgresql.org; Fri, 04 May 2018 12:31:09 +0000 Received: by mail-lf0-x243.google.com with SMTP id y14-v6so30312111lfy.12 for ; Fri, 04 May 2018 05:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=B6i59+iDztH+Wz9wz1s9rnZtHh+dX3ydnUCJIDF3LPQ=; b=HtWFjPA/DBHAeMGJW2y2lf2+m+yUdqO0AZhDmhOWWKcxBOzw82ExZNnf6qg9UaSU5p Elp9XKij7DPpiXI5P2KxBRAoqiTAYy8InAzO2sYLP6uGwF/c9tyReVIrqXbsOb20w6WS OSecg3f64pSmsYprKOn+XZBGdZGEBJgcXCcvsjAXTsghHbKU1qJLq9IqLjSd5TOH1kj+ AV1wmu3k2hnyiLQxSEZRLAptBN2YflP7Ys9sBBahsQdZs5x9vCFG8YJgnk198AKltE/F Svc6FJnUdPPumw+PiI6EFV+wZf1KcUlKCuK55VBUVOQ/juJmZ7fYlpnX+Cchldmzxpzz oNTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=B6i59+iDztH+Wz9wz1s9rnZtHh+dX3ydnUCJIDF3LPQ=; b=e5qZJ9YjTJpmeYevhtcPiBTE2lXnbeKrTDLkBc5qE8Aa3WLMTwjA86uUy9hg36xyKy v6Ptntj7e2HcHvlvSD/ca3qBf5iF8sNx4X2xbySWUgXY0J95DFfZEhH/CO56N8jRZh+k +80SGnnQW8kTrTxu3eo1fkivKgL8GPTzKofCTH0rGgfl8p999N+RMnxXV1qI8PuARVcl BJvh/o/v2kcLj+JYoSkWCoUMDY8EZU9pxXbWkqYTjXW+8PKdYst6+iSavmugTRPriYSt cVJYPGcyVOEM8A5VDVdjRNkk4xixCp3G6fMMeJ5TnkbhhEeMycOuyCIW9RKfFWueSXD+ D9SQ== X-Gm-Message-State: ALQs6tDsTSw5L5RtR63Evc/faxGIYitux7QibE9DhJMeLOvQojX+t22u QSQBau/zV9b/2bHaEoiwShxMIw== X-Google-Smtp-Source: AB8JxZoVgwflzrEww9VbR5IvNdECqUJlTX8e8VdNsGtdJCtELL8gEVpRYYqb9PWycXTaOOlThyQffA== X-Received: by 2002:a2e:59d4:: with SMTP id g81-v6mr19816808ljf.4.1525437060235; Fri, 04 May 2018 05:31:00 -0700 (PDT) Received: from [1.0.0.7] ([178.155.4.122]) by smtp.gmail.com with ESMTPSA id b65-v6sm244708lff.5.2018.05.04.05.30.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 May 2018 05:30:59 -0700 (PDT) Subject: Re: make installcheck-world in a clean environment To: Robert Haas Cc: "pgsql-hackers@postgresql.org" References: From: Alexander Lakhin Message-ID: Date: Fri, 4 May 2018 15:30:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------121A5275485AD6551E7FA2F8" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------121A5275485AD6551E7FA2F8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 04.05.2018 14:58, Robert Haas wrote: Thanks for your involvement! > Your proposed fix involves inventing something called > USE_INSTALLED_ASSETS, but we don't need that anywhere else, so why do > we need it for ECPG? We need that not only for ECPG, but for libpostgres, libpgport, and libpq too, if we want to check the installed ones (instead of recompiled). Imagine that we will recompile psql (and use it) to perform installcheck for the server instance. It will work but we'll miss an opportunity to check whether the installed psql is working. I believe, it's the same with ecpg (as now, we can even remove installed ecpg and have all the tests passed). > I am not opposed to fixing this, but one might also ask whether it's a > good use of time, since the workaround is straightforward. I'm not seeing a workaround to perform more complete installcheck without modifying makefiles. So for me the question is whether the increasing the testing surface justifies this use of time. Best regards, ------ Alexander Lakhin Postgres Professional: http://www.postgrespro.com The Russian Postgres Company --------------121A5275485AD6551E7FA2F8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
04.05.2018 14:58, Robert Haas wrote:

Thanks for your involvement!

Your proposed fix involves inventing something called
USE_INSTALLED_ASSETS, but we don't need that anywhere else, so why do
we need it for ECPG?
We need that not only for ECPG, but for libpostgres, libpgport, and libpq too, if we want to check the installed ones (instead of recompiled).
Imagine that we will recompile psql (and use it) to perform installcheck for the server instance. It will work but we'll miss an opportunity to check whether the installed psql is working. I believe, it's the same with ecpg (as now, we can even remove installed ecpg and have all the tests passed). 
I am not opposed to fixing this, but one might also ask whether it's a
good use of time, since the workaround is straightforward.

I'm not seeing a workaround to perform more complete installcheck without modifying makefiles. So for me the question is whether the increasing the testing surface justifies this use of time.


Best regards,

------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

--------------121A5275485AD6551E7FA2F8--