ou have to deal with non-ASCII data.
So I'm skeptical that such optimizations are worth much anymore.
regards, tom lane
at. But that's not a performance consideration.
regards, tom lane
;::lquery;
?column?
--
t
(1 row)
contrib_regression=# select 'foo1_br2_baz'::ltree ~ 'foo_bar%*'::lquery;
?column?
--
f
(1 row)
I'd be the first to admit that this paragraph doesn't seem to measure up
to our usual standards of clarity, but I'm not sure about what would be
better wording.
regards, tom lane
g from a
generic backup"? Needs a bit of research into exactly what
pg_basebackup puts into pg_wal/.
2. Should we restructure chapter 26 to pull the how-to-recover
directions into a separate ? If not, we probably at least
need a pointer from 26.2 to 26.3.4.
regards, tom lane
can hold)
I kind of doubt that this is a useful piece of information, because
there are a bunch of other practical limits you're likely to hit
before that one.
regards, tom lane
t; this a typo? Thanks.
I think it's intended. The point is that instead of, say,
tsvector_column @@ 'query here'::tsquery
you could just write
tsvector_column @@ 'query here'
regards, tom lane
the matview's defining query,
the original contents of the matview will be ordered that way;
but REFRESH MATERIALIZED VIEW does not guarantee to preserve
that ordering.
regards, tom lane
em
> to be used in the docs, and with markup).
Pushed, thanks for preparing the patch.
regards, tom lane
ther.
It's misleading and probably a small waste of cycles to
have useless entries in pg_proc and pg_operator.
regards, tom lane
the other uses the non-indexed column z.
regards, tom lane
was never there before, cf
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=710d90da1
I did do something about this recently, though:
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=2ae5d72f0
regards, tom lane
=?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= writes:
> 23 дек. 2021 г., в 18:18, Tom Lane написал(а):
>> I did do something about this recently, though:
>> https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=2ae5d72f0
> I think need to mention that
ling with effective_cache_size is a better way to model
that situation.
regards, tom lane
# show default_text_search_config;
default_text_search_config
pg_catalog.english
(1 row)
I'm betting your default is set to some other language in which
stripping trailing "s" wouldn't make sense.
regards, tom lane
the patch to add "(process)" to them.
> - Auxiliary process
> - Startup process
> - WAL receiver
I think "Auxiliary process (process)" is redundant to the point
of being silly. +1 for addiing it to "WAL receiver", though,
since that's not obviously a process.
regards, tom lane
e are some operations (not only output) that can distinguish
them, so the index can't lump them together.
There are similar issues in some other datatypes, for example
zero and minus zero in the float types.
regards, tom lane
me page are also
rendered with less-than-usual spacing around them (to my eye
anyway); though this is the only one that looks like it has no
space at all.
regards, tom lane
d idea, done.
regards, tom lane
ading" code that fails to
conform to the JSON RFC, so I'm disinclined to work harder than that.
regards, tom lane
ably close to zero, and they are likely to be familiar enough to not
> need our preface to enlighten them.
Maybe time to drop the Tcl reference altogether? I like that language,
but I fear it's next door to dead, so it certainly doesn't need to be
mentioned outside the pltcl docs.
regards, tom lane
Bruce Momjian writes:
> How is this patch?
I'd still drop the Tcl bit, or if you must have it, move it to
pltcl.sgml. Otherwise OK by me.
regards, tom lane
Bruce Momjian writes:
> OK, updated patch attached. I don't think we even show TCL syntax
> anywhere anymore, so I removed that text, rather than moving it.
WFM.
regards, tom lane
stion
marks, rather than brackets, to indicate an optional element in a
syntax synopsis.
regards, tom lane
ding it, and that could
> be made a lot more clear.
I dunno, the section already makes it perfectly clear that there
are two functions. I could get behind documenting the more modern
one first, though.
I wonder if it's time to remove the references to PG 8.1?
regards, tom lane
Daniel Gustafsson writes:
>> On 30 Jan 2022, at 16:52, Tom Lane wrote:
>> I could get behind documenting the more modern
>> one first, though.
> +1
Proposed patch attached.
>> I wonder if it's time to remove the references to PG 8.1?
> I think it's tim
frames" useful enough to
include in the report?
regards, tom lane
the only function that acts that way.
regards, tom lane
"Daniel Westermann (DWE)" writes:
> which rules do we follow for writing hot standby?
The original author liked to capitalize it, but that's since been
followed only intermittently. Personally I'd just as soon lose
the caps.
regards, tom lane
7;s OID + trigger's name.
Schemas don't enter into it.
regards, tom lane
it now.
A larger issue is that blind "mkdir -p" may not produce the ownerships
and permissions you want for the parent directories. That's not a
topic to get into in a one-line summary, though.
regards, tom lane
bout just inserting a parenthetical remark at the first usage?
... leader process requests shared locks (ACCESS SHARE) on the ...
Possibly we could make the "ACCESS SHARE" be a without causing
problems in man format.
regards, tom lane
"
doesn't work here, because it's not the inverse of "whatever IS NULL".)
regards, tom lane
/systemd/man/systemd.service.html#TimeoutStartSec=,
> this should be set to "infinity" to disable the timeout.
Hmm ... maybe zero works too, or worked when this was written?
But you're right that "infinity" is now the documented way
to do it. Will fix, thanks for the report.
regards, tom lane
Justin Pryzby writes:
> On Sun, Mar 20, 2022 at 12:11:19PM -0400, Tom Lane wrote:
>> Hmm ... maybe zero works too, or worked when this was written?
>> But you're right that "infinity" is now the documented way
>> to do it. Will fix, thanks for the report.
l_indexes.idx_scan instead the second
> time. I.e. bitmap scans do not increment idx_scan.
Um ... you did notice that the mentions of idx_tup_fetch apply to two
different views, pg_stat_all_tables vs pg_stat_all_indexes?
regards, tom lane
tml
role-attributes.html is not intended to be a substitute for that.
regards, tom lane
nt
Google from continuing to find that 9.1 page when the search terms
include GIN and GIST. I suspect it's keying off those terms appearing
in the page title :-(
After the recent changes discussed on the -www list, it's possible
that Google will eventually stop indexing the 9.1 page altogether,
but I'm not holding my breath.
regards, tom lane
Peter Geoghegan writes:
> On Tue, Apr 12, 2022 at 12:49 PM Tom Lane wrote:
>> I think we should take the index type names out of the section title
>> entirely, and name it something generic like "Preferred Index Types for
>> Full Text Search".
> Agreed.
Prop
Peter Geoghegan writes:
> On Tue, Apr 12, 2022 at 1:28 PM Tom Lane wrote:
>> Proposed patch attached. The existing text already says "GIN indexes are
>> the preferred text search index type", so I'm not sure we need to go
>> further than that about
pd_linp[FLEXIBLE_ARRAY_MEMBER]; /* line pointer array */
...
regards, tom lane
't you need a similar statement on every single
one of our program man pages?
>> The page could use a hyperlink/cross-reference to the pg_hba.conf
>> documentation.
> That's easily fixed. How about the attached patch?
That part's OK, but personally I'd only have cited the link once.
regards, tom lane
four levels of keyword reserved-ness in Postgres,
and a simple highlighted-or-not scheme is not going to capture any of
that nuance.
regards, tom lane
on the same page.
Hmm, this was fixed recently in HEAD, but it should have been
back-patched to v14 and was not.
Will fix, thanks for noticing!
regards, tom lane
potting it.
I wonder whether we should update this or just remove it --- it's
clearly something that's likely to get missed again.
regards, tom lane
considered to be within any
schema: extensions have unqualified names that must be unique
database-wide. But objects belonging to the extension can be within
schemas."
I hardly see how we could make this any plainer.
regards, tom lane
"Jonathan S. Katz" writes:
> On 5/31/22 10:55 AM, Tom Lane wrote:
>> I wonder whether we should update this or just remove it --- it's
>> clearly something that's likely to get missed again.
> While burdensome, +1 for updating. We don't want users to g
('{1,2,2,3,1,1}'::integer[])
+{1,2,3,1}
uniq(sort('{1,2,3,2,1}'::integer[]))
regards, tom lane
Daniel Gustafsson writes:
>> On 3 Jun 2022, at 17:34, Tom Lane wrote:
>> .. there's no longer any reason we have
>> to limit ourselves to one example. I propose this:
> +1
Done like that, then.
regards, tom lane
f pl/pgsql:
https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW
regards, tom lane
Bruce Momjian writes:
> +not occur at certain isolation levels; higher
The docs toolchain is not gonna like that.
regards, tom lane
ision
to make it a stopword.
Use the index.
regards, tom lane
I seem to recall some discussion of letting the commit info pop up
as a tooltip. Not sure that that counts as "unobtrusive", though.
regards, tom lane
urally belong there.
The NOTE you mention is gone altogether as of v15.
regards, tom lane
ng Time: 0.109 ms
Execution Time: 1830.390 ms
(13 rows)
The parentheses are actually optional here, if memory serves --- to get
the ORDER BY to be applied inside the second sub-select, you'd have to
use parens as Shay had it.
regards, tom lane
nt above is not correct. I tried creating a PK or unique
> key index on a CITEXT column. It checks uniqueness in case-insensitivity.
That paragraph is talking about what happens when you *don't* use citext.
regards, tom lane
omparisons yield
> true (including the case where the array has zero elements)."
I don't see any conflict there.
regards, tom lane
ough about Windows to guess at exactly what.
regards, tom lane
ption without going into detail.
regards, tom lane
Bruce Momjian writes:
> I have written the attached patch to mention this issue about sql_body
> functions.
Spell-check, please. Seems OK otherwise.
regards, tom lane
uot; in
> the docs with all other instances using "case-insensitive{ly}". I'm inclined
> to fix those four to use a dash while at it to be consistent across all pages.
+1
regards, tom lane
vidently the OP didn't realize that.
This is a job for the glossary, perhaps?
regards, tom lane
ome from
an untrusted source, you must ...
Or maybe even better, just drop "shell command" from that phrase
altogether.
Probably also s/passing/including/ in the next sentence.
regards, tom lane
opping "specifying" works fine with fewer words.
> The attached includes all the above suggestions.
LGTM.
regards, tom lane
ion for "Most
common Values' Frequencies". (Summing the MCVs themselves isn't
sensible; they might not even be numeric.)
I'd vote for replacing mvf in both places with something a bit more
spelled-out, perhaps "mcv_freqs".
regards, tom lane
urn 20 bolts.
> I agree, based on the attached test.
> ...
> Doc patch attached.
Pushed, thanks.
regards, tom lane
There's been an ongoing effort to create a respectable substitute,
but it still hasn't gotten across the finish line [1].
regards, tom lane
[1] https://commitfest.postgresql.org/39/1608/
s returned.
It's also a single column, which is more relevant to the point being
made. Compare this to the immediately preceding example.
regards, tom lane
#x27;t seem terribly
useful to document such a thing separately for each affected extension.
regards, tom lane
ell
patterns, and that's completely correct because they *are* standard
regular expression notations. So I think being consistent with that
is more useful than writing something else. Also, we have five
cross-references to Patterns on that page already, so I don't think
a sixth would add much.
regards, tom lane
is palatable. If the conversion is sufficiently automated,
that might not be a big lift. (If it's *not* automated, I think
the change would never get off the ground even for HEAD, because
the docs are too much of a moving target.)
regards, tom lane
Laurenz Albe writes:
>> I think that adding "bpchar(n)" in table 8.4 would be a good thing.
> Here is a patch for that.
There would need to be some mention of it in the paras below, too.
regards, tom lane
Laurenz Albe writes:
> On Wed, 2022-09-28 at 10:48 -0400, Tom Lane wrote:
>> There would need to be some mention of it in the paras below, too.
> True. I think the attached should be sufficient.
Pushed. I failed to resist the temptation to do some further cleanup
in t
.)
This is documented in the macOS-specific installation notes.
regards, tom lane
IP_FREEBIND on
Linux, as suggested at [1] ... although that hobbles error
detection, so I'm not really sold that it's such a great idea.)
regards, tom lane
[1] https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
y considered for implementation.
Hah! Look a bit further back :-(
regards, tom lane
-CONFIG-LOGGING-JSONLOG-KEYS-VALUES
> Yeah, that's a typo. Patch attached.
Shouldn't it be "integer"?
regards, tom lane
`jit` is
> not included in the documentation.
Really? Doesn't work for me:
$ psql "host=localhost port=5432 jit=off"
psql: error: invalid connection option "jit"
regards, tom lane
uot;jit"
I suspect something in your client environment is stripping off the &...
stuff.
regards, tom lane
Stefan Badenhorst writes:
> I am using a prometheus exporter:
> https://github.com/prometheus-community/postgres_exporter/
Hmm, well, maybe prometheus is doing something with that part of the URL.
There's no such behavior in Postgres itself, though.
regards, tom lane
Justin Pryzby writes:
> f2d0c7f18 should be backpatched to v15.
Agreed, done.
regards, tom lane
ATA() or
VARDATA_ANY(), as in the concat_text() example further down.
Maybe the best fix is to leave the example as it stands but add
a note that this is an oversimplified example?
regards, tom lane
e of FILTER would have served better.
I'll go do something about that --- thanks for the report!
regards, tom lane
jian he writes:
> seems pg_column_is_updatable, pg_relation_is_updatable not documented.
I think they're not documented because they're only intended as
support for some information_schema views.
regards, tom lane
errable when they
> are not.
It's not a mistake, we are simply not trying to make the syntax diagram
reflect that particular implementation restriction. I doubt that making
it do so would be an improvement: we'd have to have two kinds of
column_constraint in the diagram.
regards, tom lane
d trimming irrelevant
material is to make it easier on the readers. Failing to do that is
discourteous: it shows that you consider a few seconds of your time
to be worth more than a similar amount of time expended by each of
(possibly) thousands of other people.
regards, tom lane
he repaired text at
https://www.postgresql.org/docs/devel/tutorial-agg.html
but it won't propagate to the released-version docs until
our next releases (scheduled for February).
regards, tom lane
oesn't sound like this is in any way unique to crosstab.
Any underqualified reference to a user-defined object can cause
problems during dump/restore, because of the restricted search_path
we use during restore.
regards, tom lane
uot;setval()" to readjust the sequence.
I don't believe we have such detail around very many, if indeed any,
of our other functions' documentation.
regards, tom lane
ed working examples, making sure
that they execute as a script is good discipline.
regards, tom lane
minology). Sadly, that is not what IEEE has established as
best practice for floating-point rounding, so round(float8)
acts differently.
regards, tom lane
> portion of the index that has to be scanned.
> "so they save visits to the table proper" should be "so they save visits to
> the table heap".
Doesn't seem like an improvement from here, especially not with one
eye on the non-heap table AMs that are being wo
pressions, aren’t those expressions over table column?
> e.g., “CREATE INDEX idx_lower_last_name ON users(LOWER(last_name))”,
> “last_name" is a column rather than a row.
Consider
CREATE INDEX idx_lower_name ON users(LOWER(last_name || ' ' || first_name));
regards, tom lane
ser to what we write elsewhere.
regards, tom lane
cture can do all the same testing tricks that the makefiles
can, and for sure it's not documented how.
regards, tom lane
uences view,
so it's not separately documented. There are a fair number of other
view-supporting functions that we don't document either.
regards, tom lane
> index with the appropriate query clause and then AND together the index
> results to identify the result rows".
> You mean "WHERE x = 5 OR y = 6"?
No; the query says AND. Unioning the index results would be
appropriate if it said OR, but that's a different topic.
regards, tom lane
ns
don't have to document their exact behavior". (If it said
"implementation-defined", that would mean we should.) So not
documenting it is expected. I think we have indeed changed the
details around this in the past.
regards, tom lane
hich plan nodes
> with initPlans were allowed to be parallel-safe.
I think you're right. Thanks for catching that!
regards, tom lane
u might get most of the way there, but
there will be input that plpgsql will accept that you won't.
regards, tom lane
PG Doc comments form writes:
> Method `next` of an iterator should be named `__next__` instead.
This was reported and fixed recently [1], but thanks for the report!
regards, tom lane
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=2ff7c913d
601 - 700 of 713 matches
Mail list logo
