Le 01/07/2024 à 10:07, Daniel Gustafsson a écrit :
On 28 Jun 2024, at 09:06, Philippe BEAUDOIN wrote:
So just looking in public repo covers probably less than 1% of the code.
However, this may give a first idea, especialy if a feature use is already
detected.
Searching for anything on Github
> On 28 Jun 2024, at 09:06, Philippe BEAUDOIN wrote:
> So just looking in public repo covers probably less than 1% of the code.
> However, this may give a first idea, especialy if a feature use is already
> detected.
Searching for anything on Github is essentially a dead end since it reports s
Le 27/06/2024 à 10:38, Matthias van de Meent a écrit :
On Thu, 27 Jun 2024, 07:34 Philippe BEAUDOIN, wrote:
Hi,
I have just tested PG17 beta1 with the E-Maj solution I maintain. The
only issue I found is the removal of the adminpack contrib.
In the emaj extension, which is the heart of the so
On Thu, 27 Jun 2024, 07:34 Philippe BEAUDOIN, wrote:
>
> Hi,
>
> I have just tested PG17 beta1 with the E-Maj solution I maintain. The
> only issue I found is the removal of the adminpack contrib.
>
> In the emaj extension, which is the heart of the solution, and which is
> written in plpgsql, the
I agree that removing adminpack was a bit of a surprise for me as
well. At first I assumed that it was just moved into the core to
accompany the file and directory *reading* functions, until I found
the release notes mentioning that now one of the users of adminpack
does not need it and so it is dr
Hi,
I have just tested PG17 beta1 with the E-Maj solution I maintain. The
only issue I found is the removal of the adminpack contrib.
In the emaj extension, which is the heart of the solution, and which is
written in plpgsql, the code just uses the pg_file_unlink() function to
automatically
