[DOCS] Syntax for changing owner on sequence is not correct

[tarik . dolovac . sa]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/8.4/static/sql-altersequence.html
Description:

Per documentation owner changing should use
owner to
this syntax doesnt work al 9.5 version
owned by 
is working please correct because I spent over 3 hour until I figure out
what is the problem

-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

[DOCS] Further Clarification request

[jym]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/9.6/static/sql-prepare.html
Description:

https://www.postgresql.org/docs/9.6/static/sql-prepare.html

The first example:  Id like to see Hunters Valley in the execute line 
as
escaping isnt mentioned on the page or its links.
Just a suggestion to help us beginners understand how things work.

-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

[DOCS] The reference to 'atacontrol' on FreeBSD is outdated.

[jrekins]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/9.6/static/wal-reliability.html
Description:

Hi,

On this page:
https://www.postgresql.org/docs/9.6/static/wal-reliability.html

... there is a reference to atacontrol on FreeBSD: On FreeBSD, 
IDE drives
can be queried using atacontrol...

This command was deprecated in FreeBSD 9.0 which was released in January
2012. Here is a link to the relevant man page highlighting its obsolesence:
https://www.freebsd.org/cgi/man.cgi?query=atacontrolsektion=8apropos=0manpath=FreeBSD+9.0-RELEASE

The camcontrol is the replacement.

Thanks,
J.

-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Further Clarification request

[David G. Johnston]

On Wed, Aug 9, 2017 at 6:25 AM,  wrote:

> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.6/static/sql-prepare.html
> Description:
>
> https://www.postgresql.org/docs/9.6/static/sql-prepare.html
>
> The first example:  Id like to see Hunters Valley in the execute
> line as
> escaping isnt mentioned on the page or its links.
> Just a suggestion to help us beginners understand how things work.
>

​This is one of hundreds of documentation examples that include literals.
Why is this one special that it needs to provide an example of a literal
containing ​a single quote that requires escaping?

The SQL Command section of the docs properly presumes the reader has
significant familiarity with writing SQL queries in PostgreSQL and is
looking either for understanding what the different kinds of commands are
or, more commonly, needs a refresher as to the exact syntax for less often
used commands.

More precisely, the vast majority of the docs assume you've read "Chapter
4. SQL Syntax".

David J.

Re: [DOCS] Further Clarification request

[David G. Johnston]

On Wed, Aug 9, 2017 at 4:03 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:

> On Wed, Aug 9, 2017 at 3:21 PM, Jym Morton  wrote:
>
>> When I write software, and use a database I don’t need to escape literals
>> if I have a Prepared Statement.  This is a major reason some of us use
>> Prepared Statements.   So, when I looked at this page, I was unclear about
>> was whether it or not I had to do it.
>>
>
> (​pseudo-code)​
> PREPARE 'SELECT $1';
> EXECTUE ('; TRUNCATE pg_catalog');
>
>
​To be clear - you only need to escape the single quote once - to write the
original literal.

EXECUTE ('bob''s niece')​ -- bob's niece, with no risk of SQL injection

David J.

Re: [DOCS] Further Clarification request

[David G. Johnston]

On Wed, Aug 9, 2017 at 3:21 PM, Jym Morton  wrote:

> When I write software, and use a database I don’t need to escape literals
> if I have a Prepared Statement.  This is a major reason some of us use
> Prepared Statements.   So, when I looked at this page, I was unclear about
> was whether it or not I had to do it.
>

(​pseudo-code)​
PREPARE 'SELECT $1';
EXECTUE ('; TRUNCATE pg_catalog');

PostgreSQL is going to ensure the "; TRUCATE pg_catalog" is considered a
single literal value when it execute SELECT $1 and so the final result is
that you get a 1x1 result with the text "; TRUNCATE pg_catalog" instead of
a broken database.  That is the major reason I use prepared statements, to
prevent SQL-injection.

You still have write the literal value within EXECUTE in a manner that
PostgreSQL can parse the command.  That is why you must escape a single
quote in the value otherwise that single quote will mark the end of the
literal and the statement will provoke a syntax error.

EXECUTE ('; bob's niece is 4 years old'); -- '; bob' is the literal and the
stray "s" will a problem.  Chapter 4 covers this dynamic.

There is no material difference compared to the rules to write:

SELECT 'bob''s niece is 4 years old';

and none of the examples on the SELECT page use a literal value with an
embedded single quote...
​

>
>
> Comment “More precisely, the vast majority of the docs assume you've read
> "Chapter 4. SQL Syntax".”
>
>
>
> Response: I don’t have any issue with SQL Syntax.
>

​​
​I'm sorry but your
​suggestion is to have this page of the documentation help clarify a point
of SQL syntax with which you were unfamiliar.  In may be PostgreSQL's
particular flavor of SQL that is in question here but it is still properly
called SQL syntax.


> ​​
>  Unless the vast majority of the docs are sentient beings they can not
> assume.
>
>
​Ok, so "the writers of" the documentation assume some level of knowledge
for the reader so that they can avoid being repetitive.  You may disagree
with what is assumed but I stand by my opinion that whomever wrote this
example did not need to consider that their example would be improved if
they used a value that required escaping.

Ultimately, if someone wanted to act on your suggestion it wouldn't bother
me.  But I see no systematic problem with this example.

David J.