Re: [HACKERS] Documentation epub format
I would second Tom on this, and if ePub is really a longer term goal of the documentation, the various eBook formats have differing levels of support for hyperlinking that would merit retaining everything in a single book that can be linked from direct references. Dru On May 1, 2013, at 1:52 PM, Tom Lane t...@sss.pgh.pa.us wrote: Joshua D. Drake j...@commandprompt.com writes: Once upon a time we had multiple books as documentation, then at some point we merged them. It was quite a few years ago. I would agree at this point that we need to consider breaking them up again. The documentation is unwieldy. The reason we merged them was to allow hyperlink cross-references between different parts of the docs. I would be sad to lose that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation epub format
On May 1, 2013, at 2:11 PM, Joshua D. Drake j...@commandprompt.com wrote: On 05/01/2013 10:52 AM, Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: Once upon a time we had multiple books as documentation, then at some point we merged them. It was quite a few years ago. I would agree at this point that we need to consider breaking them up again. The documentation is unwieldy. The reason we merged them was to allow hyperlink cross-references between different parts of the docs. I would be sad to lose that.\ Defintely. Is there no way to cross reference multiple documents? Peter? The weakness (IMO) is that you are trading off one large file for several smaller ones. The documentation is unwieldily because of the depth and breadth, not the size of the file. Thinking in terms of common use cases, you would have the the published document on an offline device. For external linking you would have to assume a directory structure, or multiple files all local in the same directory, and that's assuming the various formats for doing the linking. While there is fairly broad support for link points within a document, or to an http(s) url in formats like epub and pdf. file:// uri's are far less robust in support, and it is quite hit or miss in the various readers. Other than local HTML, I cannot think of a format that has good local file/relative path support for linking multiple documents, and broad device/platform support. Dru -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] API for Managing pg_hba and postgresql.conf
Looking at the list history, I see this has been discussed in the past, but it has been long enough that perhaps it is time to revisit it. It would appear from my own support queues, that one of the most prevalent issues with PostgreSQL installations is not a functional one, but an administrative one. For obvious reasons, the secure by default installation is the correct choice, but it presents a problem. With the proliferation of PostgreSQL onto platforms where security isn't natural, there are hurdles that have to be dealt with. What I'm seeing is a default installation protects the Data directory properly, but in so doing means that altering the configuration files, pg_hba.conf and postgresql.conf require database administrators, who should not necessarily have a level of rights to become superuser at the file system level to alter the mentioned files. Rather than change the fundamental file layout or location, I would propose that we expose an API or Schema in the database to better allow manipulation of these configuration structure from within PostgreSQL. This would allow a DBA to make changes to the configuration without the need to be a machine administrator, or even to run with escalated privilege at the OS level. My concern over tackling this is that of security. What would be the appropriate way to protect this API. Should it be a collection of functions or s a schema? Should it be part of the INFORMATION_SCHEMA? Should it be an entirely different schema, say CONFIGURATION_SCHEMA? Should the Schema or functions be restricted to a specific database (say postgres) rather than part of every database? Since most changes would require a SIGHUP, should the server process itself be alter to allow for a dynamic restart from within the environment? While I have opinions and have tinkered with the idea a bit, I'll be the first to admit that this is functionality that needs to be discussed and structure in a generally supportable way rather than a platform specific hack, so I'm looking for thoughts and opinions of an educated variety. A huge portion of the motivation here is to allow for easy to graphical administration interfaces, making the system more approachable, and to make remote administration of these files less cumbersome. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Including PL/PgSQL by default
Speaking as someone who is all about packaging PG for end users, and in truth could care less what is included by default, I can tell you that the top 3 requests I get from end users that don't want to muck around with building and installing themselves are for pl/pgsql, tsearch2 (now included) and PostGIS. The reasons are that most people don't want to have to know all the little details just to get started. Reading through this thread, the arguments really seem to boil down to 'it's added default bloat that is not required' and 'it is the procedural language of the platform and should be included'. (all the security concerns really boil down to implementation details, SQL injection with standard SQL is just as dangerous) As a packager, I respond to customer pressure by solving their needs, so I pre-package those contrib's as needed, but I do feel that they should be reviewed as potential core inclusions Andrew Satori - Owner Janitor Druware Software Designs Business Solutions for Small Business http://www.druware.com/ On Feb 22, 2008, at 11:09 AM, Andrew Dunstan wrote: Roberts, Jon wrote: However, you can not create anything in Oracle without being given permission to create it. The notion that you can create a function because you have connect rights to the database is foreign to me. Connect should mean connect, not connect AND create. Include the language by default and remove CREATE on the public schema. You'd need more than that. For example, since we don't support temp functions, we should probably ban the creation of functions in temp schemas (which I found was possible). cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend smime.p7s Description: S/MIME cryptographic signature
