At Sat, 30 Jul 2022 10:24:39 -0400, Tom Lane wrote in
> Alvaro Herrera writes:
> > On 2022-Jul-30, Michael Paquier wrote:
> >> PG_VERSION would be simpler. Looking at postmaster.pid would require
> >> a lookup at external_pid_file, and as it is not set by default you
> >> would need to add some
Alvaro Herrera writes:
> On 2022-Jul-30, Michael Paquier wrote:
>> PG_VERSION would be simpler. Looking at postmaster.pid would require
>> a lookup at external_pid_file, and as it is not set by default you
>> would need to add some extra logic in the tests where
>> external_pid_file = NULL <=> PG
On 2022-Jul-30, Michael Paquier wrote:
> PG_VERSION would be simpler. Looking at postmaster.pid would require
> a lookup at external_pid_file, and as it is not set by default you
> would need to add some extra logic in the tests where
> external_pid_file = NULL <=> PGDATA/postmaster.pid.
Hmm, no
On Fri, Jul 29, 2022 at 11:35:36PM -0400, Tom Lane wrote:
> Hm. I considered reading PG_VERSION instead, or postmaster.pid.
> PG_VERSION would be a very boring test case, but it should certainly
> be present in $PGDATA.
PG_VERSION would be simpler. Looking at postmaster.pid would require
a looku
Michael Paquier writes:
> On Fri, Jul 29, 2022 at 03:44:25PM -0400, Tom Lane wrote:
>> Pushed after some fooling with the docs and test cases. (Notably,
>> I do not think we can assume that pg_hba.conf exists in $PGDATA; some
>> installations keep it elsewhere. I used postgresql.auto.conf instea
On Fri, Jul 29, 2022 at 03:44:25PM -0400, Tom Lane wrote:
> Pushed after some fooling with the docs and test cases. (Notably,
> I do not think we can assume that pg_hba.conf exists in $PGDATA; some
> installations keep it elsewhere. I used postgresql.auto.conf instead.)
Are you sure that this la
Kyotaro Horiguchi writes:
> Please find the attached. I added some regression tests for both
> pg_read_file() and pg_read_binary_file().
Yeah, I definitely find this way cleaner even if it's a bit more verbose.
I think that the PG_RETURN_NULL code paths are not reachable in the
wrappers that do
Thanks for taking a look!
At Thu, 28 Jul 2022 16:22:17 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > - Simplified the implementation (by complexifying argument handling..).
> > - REVOKEd EXECUTE from the new functions.
> > - Edited the signature of the two functions.
>
> >> - pg_rea
Kyotaro Horiguchi writes:
> - Simplified the implementation (by complexifying argument handling..).
> - REVOKEd EXECUTE from the new functions.
> - Edited the signature of the two functions.
>> - pg_read_file ( filename text [, offset bigint, length bigint [, missing_ok
>> boolean ]] ) →
At Tue, 07 Jun 2022 17:29:31 +0900 (JST), Kyotaro Horiguchi
wrote in
> pg_read_file(text, bool) makes sense to me, but it doesn't seem like
> to be able to share C function with other variations.
> pg_read_binary_file() need to accept some out-of-range value for
> offset or length to signal that
At Tue, 7 Jun 2022 16:33:53 +0900, Michael Paquier wrote
in
> On Tue, Jun 07, 2022 at 04:05:20PM +0900, Kyotaro Horiguchi wrote:
> > If I want to read a file that I'm not sure of the existence but I want
> > to read the whole file if exists, I would call
> > pg_read_binary_file('path', 0, -1, tr
On Tue, Jun 07, 2022 at 04:05:20PM +0900, Kyotaro Horiguchi wrote:
> If I want to read a file that I'm not sure of the existence but I want
> to read the whole file if exists, I would call
> pg_read_binary_file('path', 0, -1, true) but unfortunately this
> doesn't work.
Yeah, the "normal" cases th
12 matches
Mail list logo
