I wrote:
> I think that changing pg_config's behavior would be enough to resolve
> the complaints you listed, but perhaps I'm missing some fine points.
Meanwhile I've gone ahead and pushed my v1 patch (plus Munro's
recommendation about _fullpath error handling), so we can see if
the buildfarm
Peter Eisentraut writes:
> On 05.10.22 15:59, Tom Lane wrote:
>> What did you think of the compromise proposal to change only
>> the paths that pg_config outputs? I've not tried to code that,
>> but I think it should be feasible.
> I don't think I understand what this proposal actually means.
On 05.10.22 15:59, Tom Lane wrote:
What did you think of the compromise proposal to change only
the paths that pg_config outputs? I've not tried to code that,
but I think it should be feasible.
I don't think I understand what this proposal actually means. What
would be the behavior of
Peter Eisentraut writes:
> To clarify, this instance is not at all the fault of any code in
> PostgreSQL. But it's another instance where resolving symlinks just
> because we can causing problems.
[ shrug... ] *Not* resolving symlinks when we can causes its
own set of problems, which maybe
On 15.09.22 16:43, Tom Lane wrote:
That seems ... a tad far-fetched, and even more to the point,
it'd be the other package's fault not ours. We have never promised
that those directories point to anyplace that's not PG-specific.
I certainly do not buy that that's a good argument for breaking
Thomas Munro writes:
> I tried lots of crazy stuff[1] to try to get an error out of this
> thing, but came up empty handed. Unlike realpath(), _fullpath()
> doesn't resolve symlinks (or junctions), so I guess there's less to go
> wrong. It still needs the present working directory, which is a
>
On Sun, Sep 4, 2022 at 2:42 PM Tom Lane wrote:
> Here's a draft patch for this. It seems to work on Linux,
> but the Windows code is just speculation. In particular,
> I did
>
> path = _fullpath(NULL, fname, 0);
> if (path == NULL)
> _dosmaperr(GetLastError());
>
Peter Eisentraut writes:
> On 13.09.22 17:16, Tom Lane wrote:
>> What about it does not work?
> The problem is if another package or extension uses pg_config to find,
> say, libdir, includedir, or bindir and integrates it into its own build
> system or its own build products. If those
On 13.09.22 17:16, Tom Lane wrote:
Peter Eisentraut writes:
2) You configure and install with prefix=/usr/local/pgsql-14, and then
symlink /usr/local/pgsql -> /usr/local/pgsql-14; hoping that you can
then use /usr/local/pgsql as if that's where it actually is. We don't
currently support that.
Peter Eisentraut writes:
> 2) You configure and install with prefix=/usr/local/pgsql-14, and then
> symlink /usr/local/pgsql -> /usr/local/pgsql-14; hoping that you can
> then use /usr/local/pgsql as if that's where it actually is. We don't
> currently support that. (Note that it would work
On 13.09.22 01:26, Tom Lane wrote:
Andrew Dunstan writes:
I think the discussion here is a bit tangential to the original topic.
Indeed, because I just wanted to reimplement *how* we resolve the
executable path to absolute, not question whether we should do it at all.
Well, if we decided
Andrew Dunstan writes:
> I think the discussion here is a bit tangential to the original topic.
Indeed, because I just wanted to reimplement *how* we resolve the
executable path to absolute, not question whether we should do it at all.
> The point you make is reasonable, but it seems a bit more
On 2022-09-12 Mo 16:07, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 12.09.22 17:33, Tom Lane wrote:
>>> Are you proposing we give up the support for relocatable installations?
>>> I'm not here to defend that feature, but I bet somebody will. (And
>>> doesn't "make check" depend on it?)
>>
Peter Eisentraut writes:
> On 12.09.22 17:33, Tom Lane wrote:
>> Are you proposing we give up the support for relocatable installations?
>> I'm not here to defend that feature, but I bet somebody will. (And
>> doesn't "make check" depend on it?)
> I'm complaining specifically about the
On 12.09.22 17:33, Tom Lane wrote:
Peter Eisentraut writes:
On 02.09.22 01:39, Tom Lane wrote:
find_my_exec() wants to obtain an absolute, symlink-free path
to the program's own executable, for what seem to me good
reasons.
I still think they are bad reasons, and we should kill all that
Peter Eisentraut writes:
> On 02.09.22 01:39, Tom Lane wrote:
>> find_my_exec() wants to obtain an absolute, symlink-free path
>> to the program's own executable, for what seem to me good
>> reasons.
> I still think they are bad reasons, and we should kill all that code.
> Just sayin' ...
Are
On 02.09.22 01:39, Tom Lane wrote:
find_my_exec() wants to obtain an absolute, symlink-free path
to the program's own executable, for what seem to me good
reasons.
I still think they are bad reasons, and we should kill all that code.
Just sayin' ...
Here's a draft patch for this. It seems to work on Linux,
but the Windows code is just speculation. In particular,
I did
path = _fullpath(NULL, fname, 0);
if (path == NULL)
_dosmaperr(GetLastError());
but I'm not really sure that the _dosmaperr bit is needed,
I wrote:
> Andrew Dunstan writes:
>> These days there seem to be library functions that do this, realpath(3)
>> and canonicalize_file_name(3). The latter is what seems to be called by
>> readlink(1). Should we be using one of those?
> Oh! I see realpath() in POSIX, but not
Andrew Dunstan writes:
> On 2022-09-01 Th 19:39, Tom Lane wrote:
>> find_my_exec() wants to obtain an absolute, symlink-free path
>> to the program's own executable, for what seem to me good
>> reasons. However, chasing down symlinks is left to its
>> subroutine resolve_symlinks(), which does
On 2022-09-01 Th 19:39, Tom Lane wrote:
> find_my_exec() wants to obtain an absolute, symlink-free path
> to the program's own executable, for what seem to me good
> reasons. However, chasing down symlinks is left to its
> subroutine resolve_symlinks(), which does this:
>
> * To resolve a
Isaac Morland writes:
> On Thu, 1 Sept 2022 at 19:39, Tom Lane wrote:
>> This code was mine originally (336969e49), but I sure don't
>> remember why I wrote it like that.
> Does this happen in a context where we need to worried about the directory
> structure changing under us, either
On Thu, 1 Sept 2022 at 19:39, Tom Lane wrote:
This code was mine originally (336969e49), but I sure don't
> remember why I wrote it like that. I know we didn't have a
> robust version of canonicalize_path() then, and that may have
> been the main issue, but that offhand comment about mount
>
find_my_exec() wants to obtain an absolute, symlink-free path
to the program's own executable, for what seem to me good
reasons. However, chasing down symlinks is left to its
subroutine resolve_symlinks(), which does this:
* To resolve a symlink properly, we have to chdir into its directory
24 matches
Mail list logo
