> Is it such a bad idea to store the literal text of the extension's
> pieces (control file and corresponding SQL program) in catalogs? I'm
> not sure if I understand why everyone is so interested in a special
> interaction with the file system in some way. By the same token,
> extensions can be dumped in the literal syntax -- even the ones that
> were installed from a file.
>
>> There are certainly easier ways to remember a version number than
>> building support for it into core. If people create their own
>> versioning mechanisms, they can create something which is tailor-made
>> for their particular requirements, rather than relying on decisions
>> which we made in core that may or may not be right for them (e.g. the
>> lack of version ordering, or even that we have versions rather than
>> some more general type of control table).
>
> I understand the desire to avoid investing in something that is not
> what people want. However, in the interest of scoping the discussion
> to the inline extension support, I can't seem to understand the
> objection to supporting what is basically a different transport for
> precisely the same semantic operation as having to ssh into a machine
> and untar some files, except available without the bizarre
> side-channel of ssh and fie system mangling when one is loading
> trustable operators, itself a raft of usability issues if one wishes
> to enable more software reuse.
or with adminpack, and without ssh, but still interaction with filesystem.
Filesystem rw access is a pain for the DBA. There are hacks possible
to get ride of that (but not completely: mount -o ro partitions for
example...)
I am in favor to be able to create extension directly in plain sql,
without file creation or access or system administrators privileges.
Why wouldn't we want that ?!
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
