existing material, diving into the
weedy details in even the earliest introductory paras, and so on. I
propose the attached.
regards, tom lane
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 872f7a7fac..25948a7316 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc
ot;leading
columns" per se. That way of looking at it is still sensible when
a partition covers more than one value of the key column.
regards, tom lane
index, rather than "leading
> columns" per se. That way of looking at it is still sensible when
> a partition covers more than one value of the key column.
I changed it like that and pushed.
regards, tom lane
nfiguration.
In any case, I don't think this is a documentation issue ...
regards, tom lane
es.h;h=c48f47e930ad05d3ae2e24b0c0c85662cd058a7b;hb=HEAD#l67
but there's varlena tag overhead:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/postgres.h;h=c48f47e930ad05d3ae2e24b0c0c85662cd058a7b;hb=HEAD#l159
This doesn't seem like appropriate detail for the user docs.
l, but it seems
like more of a datatype limitation than a character set issue.
regards, tom lane
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 5c8a92e250..9eb19a1c61 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -120
Laurenz Albe writes:
> On Mon, 2020-12-07 at 15:27 -0500, Tom Lane wrote:
>> I agree with the submitter that the place one would expect to read about
>> this is in datatype-character.html. So I'd propose the attached.
>> Maybe there's reason to repeat the inf
ve it or make it look like the first one.
regards, tom lane
a recommendation
that it's okay to do it.
regards, tom lane
aningful amount of space, while
restricting how the archive could be used later.
regards, tom lane
ior for any other dead row version?
regards, tom lane
t somewhere with that hint.
regards, tom lane
4+4+4+4+6+2+2+1 = 27
I think you missed the point that t_cid overlays with t_xvac.
regards, tom lane
benj@laposte.net writes:
> Le 22/01/2021 à 17:49, Tom Lane a écrit :
>> I think you missed the point that t_cid overlays with t_xvac.
> So in fact the error (with number 27) was in the documentation for
> version before postgres 8.3.
No, the pre-8.3 docs are also correct,
3 | 3
4 | 4
(4 rows)
Maybe that's a spec violation, or maybe it isn't, but we're not
going to change it. WITH ORDINALITY is implemented independently
of the particular SRF being expanded, so it couldn't take account
of the array subscripts even if we wanted it to.
regards, tom lane
s. But they should be. Will fix. I think there might be
room to say explicitly that is_local is equivalent to SET's LOCAL
option, too.
regards, tom lane
".*"s add nothing
except confusion as to the semantics; but I don't think we need these
very first examples to use a lot of bells and whistles.
Maybe what would be better is to have an example with embedded .*
such as 'thomas' ~ 't.*m'.
regards, tom lane
is,
-Calculates the difference in bytes between two write-ahead log
+Calculates the difference in bytes (lsn1 - lsn2) between two
write-ahead log
Also maybe you should use the lsn1 markup
in the text.
regards, tom lane
PUBLIC } [, ...] [ CASCADE | RESTRICT ]
where privilege_and_object_type is one of:
{ SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON TABLES
... etc etc ...
regards, tom lane
Tatsuo Ishii writes:
> So do you think we should back-patch to existing stable branches?
I'd just fix HEAD and v13. The earlier branches are not friendly
at all to long function descriptions.
regards, tom lane
)
If we're going to have people picking and choosing which parts of that
script they're going to follow exactly, having a step in it that's as
dangerous as "chown -R" just seems like a really bad idea.
regards, tom lane
be an improvement.
regards, tom lane
e in too much of a hurry to do that, because there's been
repeated discussion of removing (or at least obsoleting) most of those
codes in favor of throwing regular errors for the cases that represent
error conditions. Better to wait to change plpython until after that
dust settles.
regards, tom lane
can't cover this; it's the responsibility of each group of packagers to
decide (and document) how their distributions are laid out.
regards, tom lane
Nikolay Samokhvalov writes:
> On Sun, Mar 7, 2021 at 08:43 Tom Lane wrote:
>> Apparently, you didn't install whichever sub-package of the Postgres
>> distribution contains pg_config. Might be postgresql-devel, or
>> postgresql-dev in Debian-flavored distros. Th
rases about "If this value is specified without units, it is taken
as kilobytes", but it's sure more compact.
regards, tom lane
I do not see a useful purpose in obscuring that distinction.
I could see using a couple more words than I suggested before:
work_mem (integer, units of kilobytes)
regards, tom lane
Vik Fearing writes:
> On 3/12/21 2:50 AM, Tom Lane wrote:
>> I could see using a couple more words than I suggested before:
>> work_mem (integer, units of kilobytes)
> This gets a little more complicated with:
> shared_buffers (integer, units of BLOCKSZ)
Given the in-l
PG Doc comments form writes:
> One of executions of "SELECT current_user;" is redundant and can be removed.
Yeah, I think you're right. Done in HEAD.
regards, tom lane
, according to the terminology being used here
(which is baked into the CREATE/ALTER ROLE syntax, so we're not
going to change it lightly).
regards, tom lane
rror message you quote looks a bit like whatever client-side
code you're using has decided that the $1 references in the function
body are query parameters. They are not. The function body is a
dollar-quoted string literal and should be sent unmodified.
regards, tom lane
FOO bar-:DBNAME
regression=# \echo :FOO
bar-regression
As you say, both ways now give the same result. Since it's not the
point of this example to illustrate \set's space-eating behavior,
it might be clearer to revert the addition of the space.
regards, tom lane
hough I think we can be a bit more specific about the float
case. I suggest
... by rounding away from 0. For double precision,
the tie-breaking behavior is platform dependent, but
round to nearest even is the most common rule.
regards, tom lane
more confusing than
helpful.
regards, tom lane
ying
to store an array slice, which requires that you use [m:n] subscript
notation. It'd be correct to write either of
a.fld1[1:4] = '{221,222,223,224}';
a.fld1[1:] = '{221,222,223,224}';
which unfortunately plpgsql doesn't support in released versions
(that's fixed for v14 though).
regards, tom lane
stop
reading after the section's first sentence, but we can't cover
everything in the first sentence.
regards, tom lane
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 7d587b226c..1afd272ff0 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/
e this info into the "Object Identifier Types" section.
regards, tom lane
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 7c341c8e3f..43f99335dc 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -4780,10 +4780,14 @@ SELECT * FR
Laurenz Albe writes:
> On Tue, 2021-05-04 at 19:18 -0400, Tom Lane wrote:
>> So what I was remembering was some text in the section about sequence
>> functions. That probably seemed appropriate when they were the only
>> real use of regclass; but these days we have regclas
"David G. Johnston" writes:
> I did a read through of the patch and I like it; though I suggest changing
> "but non-NULL" to "while non-NULL".
Done that way, thanks.
regards, tom lane
. I think people reading this may have their own ideas about
which version they want. Also, getting the link to be sane in
the devel docs might be problematic.
regards, tom lane
the
best thing for dev work.
regards, tom lane
x27;s been exactly the sort of effort
you mention: run through all the examples in that file and make them
match current reality. I don't think just taking out the version
number is a good idea.
regards, tom lane
was
installed. On most Unix systems, the command locale -a will provide a
list of available locales.
Not sure what more we could say.
regards, tom lane
rong value.
The existing text is perfectly good English; your change
makes it less so. I'm afraid it's been too many years since
high school English for me to remember the exact grammatical
term for this, but "were not" is typical usage when stating
a contrary-to-fact hypoth
Member of
---+--+-
bob | | {sysadmins}
joe | | {sysadmins}
sysadmins | Cannot login | {}
and I think most would agree that titling the column "Members" would
be backwards.
regards, tom lane
nd so on, where the truth is the opposite.
regards, tom lane
ke an improvement.
One thing we could easily do is not use isomorphic examples in the two
sections. For example, instead of illustrating how to spell "data" in
both forms, use "name" as the example for the identifier case.
regards, tom lane
w
different variations on trying to be more precise than that, and
they've apparently all been failures.
regards, tom lane
could make that slightly better by writing
"$HOME/.pg_service.conf", but is that good enough?
regards, tom lane
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 875950b83c..ca231f43c4 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -8091,26 +8091,3
"tanghy.f...@fujitsu.com" writes:
> On Thursday, May 27, 2021 10:58 AM, Tom Lane wrote
>> So I ended up with the attached --- what do you think?
> The doc-fix LGTM.
> But I couldn't apply the patch at HEAD(2941138e60). Maybe you did the fix at
> a branch ot
"tanghy.f...@fujitsu.com" writes:
> On Thursday, May 27, 2021 11:27 PM, Tom Lane wrote
>> No ... "patch -p1 <~/improve-pgservice-docs.patch" works fine for me.
> Oh, never tried "patch -p1" command before but it worked. Thanks!!
> BTW, here is
" is a bit too informal
for this context. I'm too caffeine-deprived to instantly come up
with le mot juste; but perhaps "exist within" would be an improvement?
regards, tom lane
Alvaro Herrera writes:
> On 2021-Jun-01, Tom Lane wrote:
>> +1 for the concept, but I feel that "live in" is a bit too informal
>> for this context. I'm too caffeine-deprived to instantly come up
>> with le mot juste; but perhaps "exist within"
AL.
Hmm, okay. I can support "reside in".
regards, tom lane
E
> db=# CREATE INDEX message_rdtree_idx ON message USING GIST (sections
> gist__int_ops(siglen=32));
> ERROR: unrecognized parameter "siglen"
Yup, that's clearly a thinko. Will fix, thanks for noticing it!
regards, tom lane
ertion
that no such things are necessary anywhere. That seems (a) probably
wrong and (b) not grammatically consistent with the other entries in
that bullet list.
regards, tom lane
hat Python has
no sandboxing mechanism.)
regards, tom lane
do not work and will throw a syntax
>> error.
> You must be misreading something, the new syntax works:
> COPY (SELECT 42 AS x) TO STDOUT (FORMAT 'csv', FORCE_QUOTE (x));
The most probable explanation seems to be that the OP is actually
connecting to an 8.4 (or older) PG se
t time zone abbreviations are not considered
valid values for the TimeZone setting. However, once you add a
numeric offset, the string becomes a valid POSIX-style setting.
regards, tom lane
the host string is a socket path name.
regards, tom lane
nd destroyed the formatting. I agree both
with adding braces and with putting LEAKPROOF on its own line.
The latter is/should be only cosmetic; but the rest of the list
has one line per independent option, and LEAKPROOF is surely
independent of the volatility options.
regards, tom lane
o overload them with this issue would be
wise.
regards, tom lane
> --
> 1920-12-25 00:00:00-06:36:36
> (1 row)
Yeah, fair point. There's a passing mention of fractional-minute
offsets in Appendix B, but the main docs don't cover it at all.
I propose the attached draft patch.
regar
luding "the tz database's LMT offsets should not be considered
> meaningful".
I tried to interest them in dropping the LMT idea altogether [1].
Unsurprisingly, the proposal went nowhere.
regards, tom lane
[1] http://mm.icann.org/pipermail/tz/2021-May/030114.html
what that meant.
regards, tom lane
hought about it.
Of the options we provide in the core distro, plpython is less suitable
because it only comes in an untrusted form (for lack of any workable
sandboxing feature in Python). So plperl or pltcl is what there is.
regards, tom lane
Bruce Momjian writes:
> On Thu, Jul 15, 2021 at 11:12:38PM -0400, Tom Lane wrote:
>> At least two of these changes are flat out wrong. The places
>> that explicitly mention "substring(s)" are not doing so because
>> we failed to think about what that meant.
>
ry
postgresql-version under the current ...
Admittedly, someone who doesn't grok that
version is a variable might be confused
initially, but I think they'd soon figure it out after seeing the
file names on the server.
regards, tom lane
ther the example shouldn't
be assuming that you chose the .bz2 file instead of the .gz one.
regards, tom lane
-QAed version. On the whole though,
I'm having qualms about recommending this in this particular spot,
rather than back in Appendix I. Seems like the wrong audience is
going to be reading this chapter.
regards, tom lane
his is another case of a GNUism that's become close
enough to universal that we don't need to be pedantic about it.
regards, tom lane
Alvaro Herrera writes:
> On 2021-Jul-21, Tom Lane wrote:
>> I'm having qualms about recommending this in this particular spot,
>> rather than back in Appendix I. Seems like the wrong audience is
>> going to be reading this chapter.
> Well, we can remove that first
nable, done at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7fa1e1ef741964eeb50f33d7c72622658bb7e5f4
regards, tom lane
d a coherent proposal though. In the
meantime I'm not much on board with sprinkling cross-references into
random places, if only because those references will be pointing to
the wrong place when/if this refactoring does happen.
regards, tom lane
ormation_schema.sgml were pretty
haphazard. There are 115 references to "domain" in that file
by my count, and there seemed little rationale behind the half
dozen you'd chosen to link-ify. I cut it down to just linking
from the section for the "domains" view, which seemed l
for
views. So it seems unclear whether the statement is meant to apply
to view triggers too.
I think it'd work out best to make this a separate para after the
one that defines before/after/instead-of triggers. How do you
like the attached?
regards, tom lane
dif
e might be curious about, the manual would be
three times its current size, but not more useful.
regards, tom lane
> https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058%3A_Protect_Your_Search_Path
Yeah. I can't get terribly excited about trying to make this one
example unconditionally-secure; there are dozens if not hundreds
of similar cases in our docs. Trying to make them all safe
against insecure search paths would mostly result in unreadable
examples.
regards, tom lane
/ ? Or s/in case/after/ ? It does seem like this
sentence needs more help than just comma-removal.
regards, tom lane
Daniel Gustafsson writes:
> On 27 Aug 2021, at 15:52, Dave Cramer wrote:
>> In my mind "in the event that it crashes" made it clear
> That, or “if it crashes” gets my vote.
Dave's wording sounds good to me.
regards, tom lane
Daniel Gustafsson writes:
> On 27 Aug 2021, at 16:15, Tom Lane wrote:
>> Dave's wording sounds good to me.
> I can go make that happen, backpatched down to 9.6 AFAICT on a quick skim,
> unless you’re already on it.
Feel free, I've got other st
Laurenz Albe writes:
> On Fri, 2021-07-30 at 16:20 -0400, Tom Lane wrote:
>> I think it'd work out best to make this a separate para after the
>> one that defines before/after/instead-of triggers. How do you
>> like the attached?
> That is better, and I like y
ar bloat. Maybe it'd be appropriate to add some text here about
that? But I'm not sure where to stop, because there are lots of things
that are identifiers but an unsophisticated user might think are keywords.
(Index type names, for example.)
regards, tom lane
t's hard
to tell on the basis of what you've said whether the failures you saw
were due to this effect or were implementation-dependent false
positives.)
What I'm inclined to think here is that maybe the docs are not
sufficiently vocal about the fact that you can't avoid serialization
failures altogether.
regards, tom lane
PG Doc comments form writes:
> The first parameter for both lo_truncate and lo_truncate64 is missing an
> "N", it says "PGcon *conn", but should be "PGconn *conn".
Good catch! Will fix, thanks.
regards, tom lane
ang
It could be that that entry for Li is backward, though.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/54ad0e42-770e-dfe1-123e-bce9361ad452%402ndquadrant.com
PG Doc comments form writes:
> please consider adding a short line which clarifies what the default
> behaviour of the `include_dir` paramter is if it is not set.
include_dir is not a parameter, it's a directive that's executed
while reading the file.
regards, tom lane
nested-loop join (David Rowley)
No, "memoize" is the intended spelling.
regards, tom lane
ed, either.
Will fix, thanks for noticing!
regards, tom lane
n 7.4
doesn't mention that.
regards, tom lane
t $2}', this command does not return
> any results with correct pid. Probably /zero/ needs to be updated with
> /anon_hugepage/
The example seems to work as-given for me (testing on a RHEL8 system).
It's of course not guaranteed to work on every flavor of Linux.
regards, tom lane
hout requiring
to be allowed to be empty.
BTW, as it stands, the diagram is ambiguous
because there are two ways to parse
FETCH cursor_name
... is present but empty, or omitted altogether?
regards, tom lane
rir writes:
> On Thu, Oct 07, 2021 at 04:24:16PM -0400, Tom Lane wrote:
>> BTW, as it stands, the diagram is ambiguous
>> because there are two ways to parse
>> FETCH cursor_name
>> ... is present but empty, or omitted altogether?
> I am confident you know what
erminology chosen by the SQL
> standards
... although I think this text is mine, so naturally I'd think
that. Anyone else have an opinion?
regards, tom lane
PG Doc comments form writes:
> The table on information_schema.tables documentation page is broken after
> version 12.
> Instead of three columns in header and body all text is packed inside one.
That's an intentional change.
regards, tom lane
e, so it's just this one mistake.
regards, tom lane
the replica, but it would be
> helpful to have something about this in the official documentation.
I'm a little skeptical about that. By that argument, nearly every one
of our SQL command pages would need a disclaimer saying that you can't
use it on a replica.
regards, tom lane
aterialized view". Which
isn't an unreasonable position, but we haven't done it like that
consistently.
I don't think we need to be similarly exhaustive about enumerating
the kinds of types that there are.
regards, tom lane
"Daniel Westermann (DWE)" writes:
>> "The name of the table must be distinct from the name of any other
>> relation (table, sequence, index, view, materialized view, or foreign
>> table) in the same schema."
> Works for me, +1
Done that way, then.
regards, tom lane
;t updated when we invented template0.
I'll go do something about that --- thanks for the suggestion!
regards, tom lane
501 - 600 of 713 matches
Mail list logo
