On Fri, Jun 4, 2021, at 11:45, Pavel Stehule wrote:
On Fri, Jun 4, 2021, at 08:58, Pavel Stehule wrote:
It is the same as using the command line without the possibility to customize the PATH variable. The advantages and disadvantages are exactly the same.
The reason why we even have PATH in the *nix world,
is not because they *wanted* to separate things (like we want with schemas or extensions),
but because they *needed* to, because /bin was overflowed:
"The UNIX shell gave up the Multics idea of a search path and looked for program names that weren’t
file names in just one place, /bin. Then in v3 /bin overflowed the small (256K), fast fixed-head drive.
Thus was /usr/bin born, and the idea of a search path reinstated." [1]
It's funny - sometimes too restrictive limits are reason for design of longer living concepts
Pavel
Yes, it’s funny, I bet there is some English word for this phenomenon?
I just read an article discussing similar problems in *nix and found the extract below very interesting.
Maybe there are takeaways from this article that can inspire us, when thinking about PostgreSQL The Next 50 Years.
”Unix Shell Programming: The Next 50 Years
…
2 THE GOOD, THE BAD, AND THE UGLY
…
2.2 The Bad
…
U4: No support for contemporary deployments. The shell’s core abstractions were designed to facilitate orchestra- tion, management, and processing on a single machine. How- ever, the overabundance of non-solutions—e.g., pssh, GNU parallel, web interfaces—for these classes of computation on today’s distributed environments indicates an impedance mismatch between what the shell provides and the needs of these environments. This mismatch is caused by shell programs being pervasively side-effectful, and exacerbated by classic single-system image issues, where configuration scripts, program and library paths, and environment vari- ables are configured ad hoc. The composition primitives do not compose at scale.”