Re: Parameter types are inferred from context of first use only.
On 2018-08-09 05:24, Bruce Momjian wrote: On Mon, Jul 23, 2018 at 09:14:48AM +, PG Doc comments form wrote: The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/10/static/sql-prepare.html Description: Background can be found on the bugs list (pgsql-bug #15289). It was explained that when a prepared statement parameter needs to have its type inferred then, should the parameter be used more than once, only the first use is considered. (The example in that report is that the type of $1 can be inferred from "($1 = col) or ($1 is null)" but not from "($1 is null) or ($1 = col)".) The documentation as it stands says only that the parameter's type is inferred from the context in which it is used. The "first use only" proviso is not mentioned (hence "context" isn't so broad as to consist of all of the expressions in which the parameter appears). I have developed the attached patch to cover what you found. That says it for me. The third mention of context doesn't need anything because it's referring specifically to the (single) use of $2 in the example. I have to presume the type inference happens before any structural changes that might change the meaning of "first occurrence". Nick
Doc update
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/10/static/sql-grant.html Description: This line: The entries shown by \dp are interpreted thus: Should be updated to: The entries shown by \dp and \l are interpreted thus:
Re: Parameter types are inferred from context of first use only.
On Thu, Aug 9, 2018 at 12:18:27PM +1200, Morgan Owens wrote: > On 2018-08-09 05:24, Bruce Momjian wrote: > >On Mon, Jul 23, 2018 at 09:14:48AM +, PG Doc comments form wrote: > >>The following documentation comment has been logged on the website: > >> > >>Page: https://www.postgresql.org/docs/10/static/sql-prepare.html > >>Description: > >> > >>Background can be found on the bugs list (pgsql-bug #15289). It was > >>explained that when a prepared statement parameter needs to have its type > >>inferred then, should the parameter be used more than once, only the first > >>use is considered. (The example in that report is that the type of $1 can be > >>inferred from "($1 = col) or ($1 is null)" but not from "($1 is null) or ($1 > >>= col)".) > >> > >>The documentation as it stands says only that the parameter's type is > >>inferred from the context in which it is used. The "first use only" proviso > >>is not mentioned (hence "context" isn't so broad as to consist of all of the > >>expressions in which the parameter appears). > > > >I have developed the attached patch to cover what you found. > > > > That says it for me. The third mention of context doesn't need anything > because it's referring specifically to the (single) use of $2 in the > example. I have to presume the type inference happens before any structural > changes that might change the meaning of "first occurrence". Great, patch applied through 9.3. I also changed "used" to "referenced": https://git.postgresql.org/pg/commitdiff/b284262e40424daa1c546ad76f365b31304d7944 -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Parameter types are inferred from context of first use only.
On Thu, Aug 9, 2018 at 10:14:33AM -0400, Bruce Momjian wrote: > On Thu, Aug 9, 2018 at 12:18:27PM +1200, Morgan Owens wrote: > > On 2018-08-09 05:24, Bruce Momjian wrote: > > >On Mon, Jul 23, 2018 at 09:14:48AM +, PG Doc comments form wrote: > > >>The following documentation comment has been logged on the website: > > >> > > >>Page: https://www.postgresql.org/docs/10/static/sql-prepare.html > > >>Description: > > >> > > >>Background can be found on the bugs list (pgsql-bug #15289). It was > > >>explained that when a prepared statement parameter needs to have its type > > >>inferred then, should the parameter be used more than once, only the first > > >>use is considered. (The example in that report is that the type of $1 can > > >>be > > >>inferred from "($1 = col) or ($1 is null)" but not from "($1 is null) or > > >>($1 > > >>= col)".) > > >> > > >>The documentation as it stands says only that the parameter's type is > > >>inferred from the context in which it is used. The "first use only" > > >>proviso > > >>is not mentioned (hence "context" isn't so broad as to consist of all of > > >>the > > >>expressions in which the parameter appears). > > > > > >I have developed the attached patch to cover what you found. > > > > > > > That says it for me. The third mention of context doesn't need anything > > because it's referring specifically to the (single) use of $2 in the > > example. I have to presume the type inference happens before any structural > > changes that might change the meaning of "first occurrence". > > Great, patch applied through 9.3. I also changed "used" to > "referenced": > > > https://git.postgresql.org/pg/commitdiff/b284262e40424daa1c546ad76f365b31304d7944 Sorry, reporting credit should have gone to Nick Farmer. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Doc update
On Thu, Aug 9, 2018 at 08:54:16AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/static/sql-grant.html > Description: > > This line: > > The entries shown by \dp are interpreted thus: > > Should be updated to: > > The entries shown by \dp and \l are interpreted thus: Well, in that line it is referring to the use of \dp in the paragraph above. Looking at src/bin/psql/describe.c: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/psql/describe.c I see many references to printACLColumn(), which prints "Access privileges", specifically calls by: https://doxygen.postgresql.org/describe_8c.html#abd41ba75b2c775de9e9b38815d69cb5c Referenced by describeFunctions(), describeTablespaces(), describeTypes(), listAllDbs(), listDefaultACLs(), listDomains(), listForeignDataWrappers(), listForeignServers(), listLanguages(), listSchemas(), and permissionsList(). so we would need to list _all_ of these uses, which I don't think we want to do. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Release note trimming: another modest proposal
On 06/08/2018 00:57, Tom Lane wrote: > Anyway, I'd like to propose a compromise position that I don't think > has been discussed before: let's drop release notes for branches > that were already EOL when a given branch was released. So for > example, 9.3 and before would go away from v12, due out next year. > Working backwards, we'd drop 9.1 and before from v10, giving the 15% > savings in page count that I showed above. A quick measurement says > that would also trim the size of the v10 tarball by about 4%, which > is not a lot maybe but it's noticeable across a lot of downloads. Why not go further and just ship the release notes of the current major version. If you want to look at the release notes of version 11, read the documentation for version 11. Who reads the documentation of version 12 to get the release notes of version 11? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Release note trimming: another modest proposal
Peter Eisentraut writes: > On 06/08/2018 00:57, Tom Lane wrote: >> Anyway, I'd like to propose a compromise position that I don't think >> has been discussed before: let's drop release notes for branches >> that were already EOL when a given branch was released. > Why not go further and just ship the release notes of the current major > version. If you want to look at the release notes of version 11, read > the documentation for version 11. Who reads the documentation of > version 12 to get the release notes of version 11? Personally, I'd be OK with that, but it seemed to me that that had already been proposed and shot down (on the grounds of not-enough- history) the last time this was discussed. regards, tom lane
Re: Release note trimming: another modest proposal
On Thu, Aug 9, 2018 at 07:45:08PM -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On 06/08/2018 00:57, Tom Lane wrote: > >> Anyway, I'd like to propose a compromise position that I don't think > >> has been discussed before: let's drop release notes for branches > >> that were already EOL when a given branch was released. > > > Why not go further and just ship the release notes of the current major > > version. If you want to look at the release notes of version 11, read > > the documentation for version 11. Who reads the documentation of > > version 12 to get the release notes of version 11? > > Personally, I'd be OK with that, but it seemed to me that that had > already been proposed and shot down (on the grounds of not-enough- > history) the last time this was discussed. We allow people to just several major versions as long as they read the release notes of all the versions they skipped. Shipping all active major version release notes works for that. Personally, I would find a git tree or tarball of all release notes in SGML or HTML format useful. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
