Formatting of warning about using ident
The warning about using ident for authorization or access control is using a with an rather than a , making it look quite different from the rest of the manual, and less like a warning IMO. https://www.postgresql.org/docs/devel/auth-ident.html The attached turns it into a and removes the (this was the sole place used in the docs) to make the docs more consistent for formatting of warnings. cheers ./daniel ident_warning.patch Description: Binary data
SPITupleTable members missing in docs
Commit 3d13623d75d3206c8f009353415043a191ebab39 added the next and subid fields to the SPITupleTable struct, but they never made it into the documentation. While these are internal members, we already document several other internal ones (with a sentence on not using them) so add these too to make the documentation match reality. Since this makes the number of internal members far outnumber the public ones, also reword the statement about which fields can be used to try and improve clarity. cheers ./daniel spitupletable.patch Description: Binary data
Re: ATTACH/DETACH partitions and locking
On 13.06.2019 23:07, Alvaro Herrera wrote: On 2019-Jun-13, Pavel Luzanov wrote: Hello, According to patch[1] and after playing with v12 beta1 I think that this item can be dropped from "5.11.3. Implementation Using Inheritance" section of v12 docs: "Some operations require a stronger lock when using declarative partitioning than when using table inheritance. For example, adding or removing a partition to or from a partitioned table requires taking an ACCESS EXCLUSIVE lock on the parent table, whereas a SHARE UPDATE EXCLUSIVE lock is enough in the case of regular inheritance." Hmm ... while you're correct that ALTER TABLE ATTACH PARTITION no longer uses AccessExclusive lock, ALTER TABLE DETACH PARTITION continues to. So we could remove the "adding to" bit of the paragraph, but not remove it completely. https://www.postgresql.org/message-id/CA%2BTgmoY13KQZF-%3DHNTrt9UYWYx3_oYOQpu9ioNT49jGgiDpUEA%40mail.gmail.com You are right, I missed the point with DETACH. Does it make sense to change this way? "Some operations require a stronger lock when using declarative partitioning than when using table inheritance. For example, removing a partition from a partitioned table requires taking an ACCESS EXCLUSIVE lock on the parent table, whereas a SHARE UPDATE EXCLUSIVE lock is enough in the case of regular inheritance." - Pavel Luzanov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Re: SPITupleTable members missing in docs
Daniel Gustafsson writes:
> Commit 3d13623d75d3206c8f009353415043a191ebab39 added the next and subid
> fields
> to the SPITupleTable struct, but they never made it into the documentation.
> While these are internal members, we already document several other internal
> ones (with a sentence on not using them) so add these too to make the
> documentation match reality.
> Since this makes the number of internal members far outnumber the public ones,
> also reword the statement about which fields can be used to try and improve
> clarity.
I wonder if we should just show the public fields in the docs? Something
like
typedef struct
{
...
TupleDesc tupdesc;/* row descriptor */
HeapTuple *vals; /* rows */
...
} SPITupleTable;
(The struct contains additional fields that should not be touched
by users of SPI.)
Not wedded to that, but it would reduce the risks of future mistakes
of this same sort.
regards, tom lane
Re: SPITupleTable members missing in docs
> On 14 Jun 2019, at 16:15, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Commit 3d13623d75d3206c8f009353415043a191ebab39 added the next and subid
>> fields
>> to the SPITupleTable struct, but they never made it into the documentation.
>> While these are internal members, we already document several other internal
>> ones (with a sentence on not using them) so add these too to make the
>> documentation match reality.
>
>> Since this makes the number of internal members far outnumber the public
>> ones,
>> also reword the statement about which fields can be used to try and improve
>> clarity.
>
> I wonder if we should just show the public fields in the docs? Something
> like
>
>typedef struct
>{
>...
>TupleDesc tupdesc;/* row descriptor */
>HeapTuple *vals; /* rows */
>...
>} SPITupleTable;
>
>(The struct contains additional fields that should not be touched
>by users of SPI.)
>
> Not wedded to that, but it would reduce the risks of future mistakes
> of this same sort.
Yeah, that’s clearly an alternative. If we go down this route, then perhaps
the docs should be swept for other instances (if any) and handle them all to
keep things consistent? (and yes, I volunteer if we want to opt for that.)
cheers ./daniel
Re: Mistake in documentation for CREATE STATISTICS
PG Doc comments form writes: > The example on https://www.postgresql.org/docs/11/sql-createstatistics.html > seems wrong: instead of "EXPLAIN ANALYZE SELECT ..." it should say "EXPLAIN > SELECT ...". If changed that way, the query optimizer estimates the number > of rows at 1 and then 100 after statistics are created which is indeed how > many the query returns. In the current wording, with ANALYZE, the query > optimizer estimates the number of rows at 100 for both the first and second > select. I think you're mistaking actual rows for estimated rows in the output of EXPLAIN ANALYZE. The point of using EXPLAIN ANALYZE here is just to make it easier to see that the estimate is indeed wrong, by providing the actual count alongside the estimate. I don't think that taking out ANALYZE would be an improvement. For instance, in the first EXPLAIN I get Gather (cost=1000.00..11675.10 rows=1 width=8) (actual time=1.215..45.218 rows =100 loops=1) which without ANALYZE would just be Gather (cost=1000.00..11675.10 rows=1 width=8) The rows=1 estimate is equally wrong either way, but you don't get to see the correct value without ANALYZE. regards, tom lane
