> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers