Re: Please add a link to [BRIN] physical block ranges of a table
On Thu, Jun 25, 2020 at 11:41 AM Bruce Momjian wrote: > On Thu, Jun 25, 2020 at 11:39:46AM -0700, Steven Pousty wrote: > > A journey of a thousand miles can start with one step :D > > Yeah, but we have to have consistency. We would need to get approval to > do it in all relevent places, and get someone to do the work. > > --- > > > > > > On Thu, Jun 25, 2020 at 8:45 AM Bruce Momjian wrote: > > > > On Thu, Jun 25, 2020 at 08:37:15AM -0700, Steven Pousty wrote: > > > I was hoping we could turn the words "physical block range" into a > link > > to > > > something like this. > > > https://datacadamia.com/io/drive/sector > > > > > > The idea is to give inexperienced readers access directly to the > > information at > > > the time of reading. > > > > Got it. I do that very often in my blog entries, but we don't do it > > much in the Postgres documentation --- not sure why, but if we did, > we > > would have to do it in a lot more places than just here. > > > > -- > > Bruce Momjian https://momjian.us > > EnterpriseDB https://enterprisedb.com > > > > The usefulness of a cup is in its emptiness, Bruce Lee > > > > > > -- > Bruce Momjian https://momjian.us > EnterpriseDB https://enterprisedb.com > > The usefulness of a cup is in its emptiness, Bruce Lee > > Sorry I forgot to reply all in my original thread. Really, we would have to do all the places at once or slowly add over time. I feel like if it has to be all the places at once we can never make some changes to fix the doc. We have too large of a corpus of doc to try something like this all at once without some herculean effort (or a dedicated doc team).
Re: Please add a link to [BRIN] physical block ranges of a table
On Thu, Jun 25, 2020 at 12:25 PM Bruce Momjian wrote: > On Thu, Jun 25, 2020 at 03:12:44PM -0400, Alvaro Herrera wrote: > > We have a glossary page as of Postgres 13[1]; since it's new, links to it > > have not yet percolated to the rest of the docs, but that should start > > happening in the pg14 cycle. > > > > You're welcome to submit a patch that adds the term you want to link as > > well as a patch that turns the text you want into a link to that term. > > > > A thing I would really like to do is turn the terms in the acronyms > > section into links to the glossary section, where those terms can be > > properly defined and where the links can appear. For example now that > > we have the term "transactions per second" we could add it to acronyms. > > Yes, this is a great direction to go in! > > -- > Bruce Momjian https://momjian.us > EnterpriseDB https://enterprisedb.com > > The usefulness of a cup is in its emptiness, Bruce Lee > > I like the direction as well as long as each of the items in the glossary has an anchor and you can link to it from the rest of the documents. The reader, if they are confused by the term, should be able to go get a quick definition without having to remember there is a glossary and then search for the term. I think you actually said that but I want to confirm. If so then you would like me to: 1. Add the text " physical block range " to acronym page 2. Make it anchor so I can link to it directly 3. Add the definition, which can include links to external sites 4. Then turn the link on the original page to the anchor I created for Physical block range. Is that the correct flow? Will this require me building all the docs on my machine? Thanks Steve
Re: The sub-categories do not have anchors on this page
They certainly do at the top of the page, that's why I sent the second
email. I was hoping to have anchors down the page where that actual topic
is. The rational for this is, when I write a blog post, teach a class, help
someone on slack... I can give them the URL right to the section I want
them to read. This anchor would prevent just giving the url to the whole
page and telling them to search for it.
I guess I could also just copy the link in the TOC at the top of the page
that points to the header I want.
So not a hig priority request but certainly easier if the anchor is right
there to copy when I am reading the section.
Thanks
Steve
On Thu, Dec 10, 2020 at 11:31 AM Alvaro Herrera
wrote:
> Hello
>
> On 2020-Dec-02, PG Doc comments form wrote:
>
> > Page: https://www.postgresql.org/docs/13/plpgsql-statements.html
> > Description:
> >
> > Hey Kind Doc People
> > I was hoping we could add sub-anchors for each of the sections on this
> page.
> > It would make it easier to link to the specific content of interest
>
> Exactly where would you want more anchors in this page? The
> sections ("42.5.6. Doing Nothing At All") already have them.
>
Re: The sub-categories do not have anchors on this page
On Thu, Dec 10, 2020 at 12:42 PM Steven Pousty
wrote:
> They certainly do at the top of the page, that's why I sent the second
> email. I was hoping to have anchors down the page where that actual topic
> is. The rational for this is, when I write a blog post, teach a class, help
> someone on slack... I can give them the URL right to the section I want
> them to read. This anchor would prevent just giving the url to the whole
> page and telling them to search for it.
>
> I guess I could also just copy the link in the TOC at the top of the page
> that points to the header I want.
>
> So not a hig priority request but certainly easier if the anchor is right
> there to copy when I am reading the section.
>
> Thanks
> Steve
>
> On Thu, Dec 10, 2020 at 11:31 AM Alvaro Herrera
> wrote:
>
>> Hello
>>
>> On 2020-Dec-02, PG Doc comments form wrote:
>>
>> > Page: https://www.postgresql.org/docs/13/plpgsql-statements.html
>> > Description:
>> >
>> > Hey Kind Doc People
>> > I was hoping we could add sub-anchors for each of the sections on this
>> page.
>> > It would make it easier to link to the specific content of interest
>>
>> Exactly where would you want more anchors in this page? The
>> sections ("42.5.6. Doing Nothing At All") already have them.
>>
>
Sorry I forgot to put the reply after the quote. Reply on top is the
default behavior in google and I just forget sometimes.
Re: Trusted versus untrusted Pl language
On Wed, Dec 23, 2020 at 2:41 PM Bruce Momjian wrote: > On Wed, Dec 23, 2020 at 08:24:13PM +, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/13/plpython.html > > Description: > > > > Hey all: > > This page & the PL/PERL page are the closest I have seen in the docs > about > > trusted versus untrusted languages. > > > > It would be great if we could add a subtopic and 1 or 2 paragraphs on > this > > page https://www.postgresql.org/docs/current/xplang.html > > Uh, what about this? > > https://www.postgresql.org/docs/13/xplang-install.html > > > Possibly outline: > > A) Explain to users what trusted versus untrusted in terms of language > > extensions. > > 1) Differentiate that from non-risky versus risky > > 2) Explain why, by default, functions written in untrusted languages > > need to be added by superuser. > > B) It would be great to give an example workflow of working with > untrusted > > languages > > 1) Developer uses superuser on their own machine or makes the > language > > trusted > > 2) Send function to the DBA > > 3) Function goes through security review and testing > > 4) If it passes then the DBA installs in a production DB > > C) An example on how to make a language trusted in a db. > > Does that URL need more detail? > > --- > Thanks for pointing that out Bruce. It is really helpful and I must have missed it as I was reading through the doc. I would say the only thing it needs is: 1. A Trusted vs. Untrusted bold header so it catches the eye 2. One or two sentences explaining that trusted and untrusted is not the same thing as risky 3. An example of how to make a pre-installed untrusted langue into a trusted language What do you think? That would have helped me A LOT when I was learning this stuff. I would also love to point this to people when they say PL/Python is untrusted therefore you should never use it. Thanks again Steve
Re: Trusted versus untrusted Pl language
On Wed, Dec 23, 2020 at 4:49 PM Bruce Momjian wrote: > On Wed, Dec 23, 2020 at 07:38:16PM -0500, Tom Lane wrote: > > Steven Pousty writes: > > > 3. An example of how to make a pre-installed untrusted langue into a > > > trusted language > > > > Under what circumstances would that be a good idea? > > > > I can't imagine that we'd really want to recommend end users doing > > that, but an example would surely be taken as a recommendation > > that it's okay to do it. > > Right. The language has to provide some sandbox environment for us to > consider it safe, e.g. Perl, but not Python. PL/pgSQL is safe since it > doesn't have any interface to external resources. > > --- If you consider the application developer or data scientist's perspective it makes total sense. I don't like the pattern of appdevs always working as the postgres user, it encourages bad patterns and can often blow up when you move the application to production. Instead I think a good flow for an appdev or a data scientists to follow when developing their function in Pl/Python or PL/R is: 1) Make the langauge trusted on the appdevs or data scientist's instance of Postgres. Most developers either work on a cluster on their laptop or in a container. 2) Send the finished product to the DBA and security teams for review. 3) If it passes review and testing then you can put it into production. The SQL I am talking about is this: UPDATE pg_language SET lanpltrusted = true WHERE lanname LIKE 'plr'; There should also be a reminder to NOT do this in production. Thanks Steve
Re: Trusted versus untrusted Pl language
Ok David but that is not what I have heard from a lot of other people in the PostgreSQL community. On Thu, Dec 24, 2020 at 1:26 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Thu, Dec 24, 2020 at 1:01 PM Steven Pousty > wrote: > >> The SQL I am talking about is this: >> UPDATE pg_language SET lanpltrusted = true WHERE lanname LIKE 'plr'; >> > > You seem to be missing the point. The language is either trusted, or it's > not. Modifying the catalogs is not part of a "good flow", ever. In short, > "don't use trusted languages ever". If a specific requirement can only be > implemented using a trusted language maybe there is a reason to use it - in > development and production (if your DBA will let you) - but more likely you > are better off writing an out-of-database client application and doing the > "trusted" stuff there. > > David J. > >
