n.
Hah! Look a bit further back :-(
regards, tom lane
the macOS-specific installation notes.
regards, tom lane
oing into detail.
regards, tom lane
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
ss at exactly what.
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
hem.
regards, tom lane
tes, else as
> hh:mm:ss. (The third case is not possible with any modern"
"Integral" seems like perfectly good English to me here.
regards, tom lane
he
> 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 worked
ly, that is not what IEEE has established as
best practice for floating-point rounding, so round(float8)
acts differently.
regards, tom lane
ledgement of the fact that some GUCs
act differently than others (cf GUC_LIST_INPUT and GUC_LIST_QUOTE flags).
+1 for examples, for sure.
regards, tom lane
ng sure
that they execute as a script is good discipline.
regards, tom lane
; "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
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
paired 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
and 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
Laurenz Albe writes:
> On Sun, 2023-01-15 at 16:40 -0500, Tom Lane wrote:
>> The documentation is correct, what is broken is the code.
> I see. But what is the reason for that anyway? Why not allow short varlena
> headers if TOAST storage is set to PLAIN?
The orig
ruary.
Thanks for the report, anyway!
regards, tom lane
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git=commitdiff=f05a5e0003edfec027ee10d09082667036862e1c
avert our eyes from the theoretical
inconsistency. Michael, looks like it was your 7a1cd5260
that changed it; what do you think?
regards, tom lane
nce we added gen_random_uuid() to the
core code in v13. pgcrypto's version is now just a deprecated
wrapper for that.
regards, tom lane
lained.
I think changing it now would add more confusion than it subtracts.
> Anyway, attached is a patch for the docs. Thoughts?
Works for me.
regards, tom lane
your version:
These tools are not needed to build from a distribution tarball, because
the files generated using these tools are included in the tarball.
Or possibly "with" instead of "using"?
regards, tom lane
Laurenz Albe writes:
> On Wed, 2023-01-25 at 20:39 -0500, Tom Lane wrote:
>> I'd modify one word in your version:
>>
>> These tools are not needed to build from a distribution tarball, because
>> the files generated using these tools are included in the
nderstand what an old SQL script is doing.
regards, tom lane
Andres Freund writes:
> On 2023-01-15 16:40:27 -0500, Tom Lane wrote:
>> The documentation is correct, what is broken is the code. I'm not
>> sure when we broke it
> I've not thought through this fully. But after a first look, this might be
> hard to fix without incur
he data type. It's blind luck that this
attstorage value isn't used for anything more consequential,
like TOAST decisions.)
regards, tom lane
Andres Freund writes:
> On 2023-01-15 18:08:21 -0500, Tom Lane wrote:
>> ri_newTupleSlot has the tupdesc we want, planSlot is a virtual slot
>> that has the bogus tupdesc, and for some reason heap_form_tuple is
>> getting called with planSlot's tupdesc not ri_newTupleSlot'
ctice, but `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
t something in your client environment is stripping off the &...
stuff.
regards, tom lane
R would have served better.
I'll go do something about that --- thanks for the report!
regards, tom lane
A_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
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
Justin Pryzby writes:
> f2d0c7f18 should be backpatched to v15.
Agreed, done.
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
to be deferrable 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
n give it away
for free.
I do question the practicality and environmental cost of putting such
short-lived material on dead trees, though ...
regards, tom lane
s the operating system user that initialized the database
cluster, unless another name is specified while running initdb.
It is common, but not required, to arrange for this role to be named
postgres.
regards, tom lane
eaking for core, just myself.)
regards, tom lane
ate: 22023
Apparently, you are reading the v15 documentation and expecting it
to be exactly correct for some older server version. The described
behavior came in in v14.
regards, tom lane
his example is pretty shoddy
compared to the one for escape format a little further down.
Will fix, thanks for the report!
regards, tom lane
nce - 100.00 WHERE acctnum = 7534;
> COMMIT;
> The acctnum is expected to be 12345 in both cases.
No, I think that's intentional: the example depicts transferring
$100 from account 7534 to account 12345.
regards, tom lane
|schedule
+---+-
Pam| {2,25001,25002,25003} |
Bill | {1,1,1,1} | {{w,x},{y,z}}
Carol | {2,25000,25000,25000} | {{w,x},{y,z}}
Carolx | {2,25001,25002,25003} | {{w,x},{y,z},{meetingy,lunchy}}
(4 rows)
regards, tom lane
de and its FROM clause in the snippet.
No, I think "form" is exactly what was meant. Maybe we should have
said "second query" or something like that, though.
regards, tom lane
ed" wording isn't really wrong, but an
example that doesn't do what we're saying it does isn't good either.
regards, tom lane
on has been true for awhile.
regards, tom lane
MCF
Most Common Frequency, that is the frequency associated
with some Most Common Value
MCV
Most Common Value, one of the values appearing most often
within a particular table column
regards, tom lane
tation claims. Which it does not, according to my
tests here. I find this a bit disturbing --- did we intentionally
change the behavior of SPI_exec somewhere along the line?
regards, tom lane
"David G. Johnston" writes:
> On Mon, Jul 17, 2023 at 6:22 PM Tom Lane wrote:
>> I think his point is that this example does not behave as the
>> documentation claims. Which it does not, according to my
>> tests here. I find this a bit disturbing --- did we inten
to be one of the subtle points illustrated by
>> this example.
> I concur:
Agreed. Done at 137b131d6.
regards, tom lane
r each pair.)
All the selected operators must be members of some B-tree operator
class, or be the negator of the = member of a B-tree operator
class, meaning that row constructor comparison is only possible
when the operator is
=,
,
,
=,
or
=,
or has semantics similar to one of these.
after which we can go on with the bit about "The = and <> cases work
slightly differently..."
regards, tom lane
you to conclude
otherwise, but going through additional layers like an IDE could
well be confusing matters.
regards, tom lane
Ilya Nenashev writes:
> I totally agree.
> Who and when will put these changes into the documentation pages?
Done at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=15c68cd84a2c80eed9b67ed6746ed5b91baea587
regards, tom lane
| a
(12 rows)
regards, tom lane
[1]
https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-SERIAL
ink the grammar
is a bit shaky". It is what it is.
regards, tom lane
way to get
the XML toolchain to allow line breaks in PDF without putting
invisible characters into other formats, let us know.
regards, tom lane
ce?
> No, the issue is only for committed transactions, not aborted ones.
I think this sentence is formally correct, but it is not very hard to
misparse. Maybe a bit of re-ordering would help? Like
... it never sees either uncommitted data or changes committed by
concurrent transactions during the query's execution.
regards, tom lane
Michael Paquier writes:
> "With multiple decades of development behind it, PostgreSQL.."
+1. It sure seems silly trying to automate changing this.
regards, tom lane
Bruce Momjian writes:
> On Fri, Jun 23, 2023 at 09:16:39PM -0400, Tom Lane wrote:
>> I think this sentence is formally correct, but it is not very hard to
>> misparse. Maybe a bit of re-ordering would help? Like
>> ... it never sees either uncommitted data or changes commi
same page..." sentence altogether.
regards, tom lane
er box handy to doublecheck.
Hmm, any chance of addressing this by expanding out the relevant macros?
regards, tom lane
rrect any errors that may exist in those doc pages.
They're just there for historical reference.
regards, tom lane
bility implications if we change it now.
regards, tom lane
lf, I thought Laurenz's proposed patch is an improvement.
regards, tom lane
t better at it.
I'm a little dubious about the "Technical References" list right below
it, too. The RFC references are probably useful and stable, and maybe
the wikipedia ref is OK, but I have little faith in either the
stability or the long-term relevance of the other two links.
regards, tom lane
Daniel Gustafsson writes:
> On 13 Feb 2024, at 20:42, Tom Lane wrote:
>> I'm a little dubious about the "Technical References" list right below
>> it, too. The RFC references are probably useful and stable, and maybe
>> the wikipedia ref is OK, but I have little f
y!
Indeed. Will fix, thanks for report!
regards, tom lane
in verbose SELECT txt = ch AS txt_ch FROM test;
QUERY PLAN
---
Seq Scan on pg_temp.test (cost=0.00..19.45 rows=630 width=1)
Output: (txt = (ch)::text)
(2 rows)
regards, tom lane
.
Perhaps it'd be better to use different example strings though?
regards, tom lane
See
https://www.postgresql.org/docs/current/contrib.html
regards, tom lane
't help you on that when you provide no details. PG certainly
does work for many other people on Debian+arm64.
regards, tom lane
ill fix, thanks!
regards, tom lane
Bruce Momjian writes:
> Agreed, updated patch attached.
WFM.
regards, tom lane
user
running initdb". I don't like "installation user", that's just about
as vague as could be.
regards, tom lane
ed it. I think there's a patch
in the pipeline to allow it.
regards, tom lane
's done so in
twenty years so I'm not holding my breath.)
regards, tom lane
"David G. Johnston" writes:
> We probably should write the syntax like we do everywhere else:
> [grantee]={privilege[*]}[…]/grantor
> Then define the placeholders in the subsequent paragraph.
Seems reasonable. About like this?
regards, tom lane
d
nother way than reserving
a table column for them? We could give them their own table rows,
or relegate them to footnotes.
The "serial" types need a bit more reflection too, since they
aren't truly types at all: there is no matching pg_type entry.
I'm not sure they belong here.
regards, tom lane
month'::interval;
interval
--
2 mons
(1 row)
regards, tom lane
nce to a
> particular standard, except for ISO 9075 to show that Postgres is
> SQL-standard-compliant?
I think that would remove useful context without actually improving
anything. (The datetime input code would be far simpler if it
meant only to read the exact format mentioned in the SQL spec.)
regards, tom lane
are writing the NOTIFY
queue. If it were a lesser but still exclusive lock type,
it wouldn't make any difference.
explicit-locking.html is really only about locks on tables.
Maybe that should be clarified somewhere?
regards, tom lane
d most other punctuation there, so
we should be able to read nearly any plausible variant.
regards, tom lane
egorian calendar still being in use 18000 years from now,
but it doesn't seem very profitable. What else do you want
to use?
regards, tom lane
"David G. Johnston" writes:
> The request is to fix our documentation to use a valid date for the example
> in the paragraph that describes the separator requirement for years greater
> than 4 digits.
Oh! Got it, that should be fixed.
regards, tom lane
t;anyelement" would.
By the same token, there is just about no use-case for a function
declared to return "any". The parser will not infer some other
data type the way it would do for "anyelement", so you'll end up
with an object that you can't do anything with.
regards, tom lane
as the server proper). I'd check
for a related server package before you go complaining to the
homebrew folks.
regards, tom lane
order returned by the data source, which is probably a pretty safe
assumption. Still, SQL is a set-oriented language which means that
it generally doesn't guarantee anything about row order, with the
sole exception being the immediate output of a SELECT ... ORDER BY.
So I think adding such guarantees isn't a great idea.
regards, tom lane
PG Doc comments form writes:
> It seems the ending clarifying sentence:
> "(Null when most_common_vals is.)"
> should rather be:
> "(Null when most_common_vals is null.)"
I think it's perfectly good English as-is, if a bit terse.
regards, tom lane
server status; however, if
incorrect values are provided, the server will log a failed
connection attempt.
If you don't want log spam about failed connections, you'd need
a user with privilege to connect to the mentioned database.
Otherwise, not.
regards, tom lane
g an example that neither explains the
"disregarded" bit nor highlights the dependency on L being given.
regards, tom lane
ot; instead of "RETURNS real"?
> The docs are correct.
Specifically, that bit is a declaration of the data type of the
function's result, not a specification of how to compute it.
regards, tom lane
Arne Sommerfelt writes:
> I am running on AWS RDS - it says engine version 12.17 i thought that was
> the postgres version. If so, the [] subscripting should be supported
> according to docs.
According to what docs? Generic subscripting was added in v14.
reg
owever, if you're running a moderately old PG version, you need
to make use of the links at the top of the page to go to the
equivalent page in the older version's docs.
regards, tom lane
quot;.
Yup, I think you're right. Thanks for the report!
regards, tom lane
rom https://github.com/docbook/wiki/wiki/DocBookXslStylesheets
to someplace convenient and setting the environment variable
XML_CATALOG_FILES to point there.
regards, tom lane
apter from total
irrelevancy.
regards, tom lane
I happened to come across this:
https://arxiv.org/pdf/1901.01973
I found this to be really interesting reading, so I wonder if
we shouldn't cite it in history.sgml or some such place.
regards, tom lane
=?UTF-8?Q?Sebastian_Ska=C5=82acki?= writes:
> Looks great to me, thanks!
Pushed, thanks.
regards, tom lane
in appendix E. But now, not so much. The simplest fix
would be to change this text to point to
https://www.postgresql.org/docs/release/
regards, tom lane
this setting and always use the
regards, tom lane
that, I'm not sure that substituting "is distinct from
null" in the COALESCE documentation is much better, because it's not
clear to me that we're entirely standards-compliant about what that
means for rowtypes either.
regards, tom lane
501 - 600 of 603 matches
Mail list logo
