cit acknowledgement 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
ith them.
regards, tom lane
s, 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
7;ll have whatever is the
default attstorage for the 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 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 wit
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_newTupleSl
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 original moti
n
February.
Thanks for the report, anyway!
regards, tom lane
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=f05a5e0003edfec027ee10d09082667036862e1c
ue since 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
to
showing opclass names, and avert our eyes from the theoretical
inconsistency. Michael, looks like it was your 7a1cd5260
that changed it; what do you think?
regards, tom lane
le haven't complained.
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
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 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 t
someone understand what an old SQL script is doing.
regards, tom lane
=> table sal_emp;
name | pay_by_quarter |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
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
Also, this example is pretty shoddy
compared to the one for escape format a little further down.
Will fix, thanks for the report!
regards, tom lane
ok and then 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
ame as 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
peaking for core, just myself.)
regards, tom lane
ates
> ERROR: field position must be greater than zero
> SQL state: 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
ode 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
"not guaranteed" 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
esn't-work
situation has been true for awhile.
regards, tom lane
e
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
rrect any errors that may exist in those doc pages.
They're just there for historical reference.
regards, tom lane
ant to view the same page..." sentence altogether.
regards, tom lane
an older box handy to doublecheck.
Hmm, any chance of addressing this by expanding out the relevant macros?
regards, tom lane
of "I think the grammar
is a bit shaky". It is what it is.
regards, tom lane
of table fruits
| a
(12 rows)
regards, tom lane
[1]
https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-SERIAL
Michael Paquier writes:
> "With multiple decades of development behind it, PostgreSQL.."
+1. It sure seems silly trying to automate changing this.
regards, tom lane
entence?
> 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
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
cumentation 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
t a
different specific operator could be selected for 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
ou did that led 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
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
expressions, however." Not sure if we
cover that explicitly anywhere else.
regards, tom lane
want to document this?
Section 8.5.1.2. Times already says "The appropriate time zone offset
is recorded in the time with time zone value." Maybe that could be
made a little more precise, say "The resolved numeric offset from UTC
is recorded in the time with time zone value."
regards, tom lane
ete --- we don't list any relkind for that anymore.
What probably does deserve to be called out in place of those is
composite types, since their appearance in pg_class might be pretty
surprising to newbies.
regards, tom lane
of "kind" not "type", for consistency with the relkind field name
and the rest of the para.)
regards, tom lane
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index d17ff51e28..e09adb45e4 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/cat
Daniel Gustafsson writes:
>> On 22 Sep 2023, at 19:04, Tom Lane wrote:
>> I propose the attached. (I also modified the para's last sentence to
>> speak of "kind" not "type", for consistency with the relkind field name
>> and the rest o
as we do for some other
feature identifiers?
regards, tom lane
e would, but that
doesn't result in an automatic kill of the server process.
> Do you want to propose a patch?
There are enough environmental dependencies involved here that
any simple description is likely to contain lies. So I'm
hesitant to try to put anything about it into the docs.
regards, tom lane
messages will be reported,
unless --if-exists is also specified.
--if-exists
Use DROP ... IF EXISTS commands to drop objects in --clean mode.
This suppresses "does not exist" errors that might otherwise be
reported. This option is not valid unless --clean is also specified.
regards, tom lane
.org/gitweb/?p=postgresql.git;a=commitdiff;h=75af0f401f905b947ea14401e8a51f1bae4ac265
regards, tom lane
an
fix anything useful.
I wonder though if there's really just one place claiming that
that's how it works. A trawl through the code comments might
be advisable.
regards, tom lane
-WINDOW-FUNCTIONS
> but I think it would be helpful to put some examples in
> https://www.postgresql.org/docs/16/functions-window.html
That page starts out with a link to section 3.5 which is
full of examples. Seems a bit repetitive to put more here.
regards, tom lane
function, or none at all.
See
https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-DISCRETE
regards, tom lane
and
> complete.
Perhaps a parenthetical remark like "(pg_basebackup refers to this as
'spread' mode)" would help?
regards, tom lane
reservation VALUES
> (1108, '[2010-01-01 14:30, 2010-01-01 15:30)');
> there should be ] after 15:30
No, it looks correct as given: that end of the range is open not closed.
regards, tom lane
s-info.html#FUNCTIONS-INFO-SESSION
Yeah, either way has the same result. However, I wonder if we should
change this example to use current_user for clarity. It does look
more like it's intended to be a variable or column reference than
a built-in function.
regards, tom lane
Daniel Gustafsson writes:
>> On 7 Oct 2023, at 22:22, Tom Lane wrote:
>> Yeah, either way has the same result. However, I wonder if we should
>> change this example to use current_user for clarity. It does look
>> more like it's intended to be a variable or column
isn't a good fix.
regards, tom lane
wrong with the existing docs.
The limitation to 1-microsecond precision is spelled out in the
table just above the para you quote.
regards, tom lane
LTER SYSTEM command.
foo.bar = 'baz'
So that feels like a bug: we should not allow ALTER SYSTEM to execute
against a placeholder GUC definition, because the placeholder can't
tell us whether the value is valid. I wonder though if forbidding
this would break any legitimate usage patterns.
regards, tom lane
Laurenz Albe writes:
> On Mon, 2023-10-16 at 12:29 -0400, Tom Lane wrote:
>> So that feels like a bug: we should not allow ALTER SYSTEM to execute
>> against a placeholder GUC definition, because the placeholder can't
>> tell us whether the value is valid. I wonder th
so, that para already mentions that the input can be a
comma-separated list when appropriate, so your add-on para seems
partially repetitive. I think you could just drop the first
sentence of it.
regards, tom lane
was an intention to have some such feature but it never got done?
Anyway, I don't see anything indicating that there's actually
such a concept as "the default connection". I suggest we just
remove those paragraphs.
What *is* treated specially is CURRENT --- but EXEC SQL SET
CONNECTION = CURRENT is effectively a no-op, so it's not very
exciting.
regards, tom lane
ange time_key to be a timestamp or timestamptz value?
regards, tom lane
er, CREATE DATABASE does not copy
+ database-level GRANT permissions attached to the
+ source database. The new database has default permissions.
+
+
There is a second standard system database named
regards, tom lane
like there is anything unclear about the CREATE TABLE error message.
regards, tom lane
Bruce Momjian writes:
> On Wed, Nov 1, 2023 at 06:32:37PM -0400, Tom Lane wrote:
>> But it *is* permissible, unless we add code to reject it during
>> SET as Bruce mentioned. Which seems fairly pointless to me. It's not
>> like there is anything unclear about the
Bruce Momjian writes:
> I found a cleaner improvement, attached.
OK by me. Maybe that doesn't make the point strongly enough,
but we can hope it's enough.
regards, tom lane
"Daniel Westermann (DWE)" writes:
> Creating a table with 1600 bigint columns does work with a 8k blocksize:
Yeah, but populating it would not (unless many of the columns were
NULL).
regards, tom lane
mpact of NULLs, and the fact that usually tables have some
variable-width columns, I doubt that a creation-time warning could be
accurate enough to be useful.
regards, tom lane
put notes about PL/pgSQL features into command
reference pages that have nothing to do with PL/pgSQL.
regards, tom lane
the
first section that mentions partial indexes at all. Somebody
reading the chapter in order would have no idea what we were
talking about.
regards, tom lane
dom users can't see
umoptions.
regards, tom lane
y case,
we accept 'T', 't', '_', and most other punctuation there, so
we should be able to read nearly any plausible variant.
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
ctions that 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
could handle those another 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
ct '2 month'::interval;
interval
--
2 mons
(1 row)
regards, tom lane
rily just
read 4.1.1.
Perhaps it'd be better to use different example strings though?
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
gt; CI)
Can't help you on that when you provide no details. PG certainly
does work for many other people on Debian+arm64.
regards, tom lane
database. See
https://www.postgresql.org/docs/current/contrib.html
regards, tom lane
ill fix, thanks!
regards, tom lane
user
running initdb". I don't like "installation user", that's just about
as vague as could be.
regards, tom lane
lain it here. But nobody's done so in
twenty years so I'm not holding my breath.)
regards, tom lane
Bruce Momjian writes:
> Agreed, updated patch attached.
WFM.
regards, tom lane
et, as you'd find out if you tried it. I think there's a patch
in the pipeline to allow it.
regards, tom lane
the new owner.
For myself, I thought Laurenz's proposed patch is an improvement.
regards, tom lane
fraid of the compatibility implications if we change it now.
regards, tom lane
rows)
regression=# explain 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
likely
that we'll get 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 lit
y!
Indeed. Will fix, thanks for report!
regards, tom lane
...".
Yup, I think you're right. Thanks for the report!
regards, tom lane
27;s worth giving an example that neither explains the
"disregarded" bit nor highlights the dependency on L being given.
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
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
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
ff.
However, 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
the probability of the
Gregorian 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
1 - 100 of 713 matches
Mail list logo
