egards, tom lane
But yes, that's exactly
what it is. I'll go improve the docs.
regards, tom lane
ing on the grounds
of "it's unimportant" ... but now that it's done, I wouldn't revert it,
on the same grounds.
regards, tom lane
hanged a bit in v11, so be careful
you are reading docs that correspond to the pg_restore version
you are using. I don't think this specific thing changed, but
the overall division of labor between pg_dump and pg_dumpall
changed.
regards, tom lane
Peter Eisentraut writes:
> On 2020-04-26 21:13, Tom Lane wrote:
>> "" renders poorly in our PDF docs: as shown in the attached
>> screenshot, it doesn't line up on the baseline.
> The real problem here is that the default font (Times or Times New
> Roman) embed
an-page-format output.
regards, tom lane
Peter Eisentraut writes:
> On 2020-04-29 21:58, Tom Lane wrote:
>> I think making the built documentation depend on nonstandard fonts
>> is a truly awful idea. It'd be okay perhaps if the requirement only
>> applied to people building the docs, but won't the requirement
deled on what we did for function-table entries.
Thoughts?
regards, tom lane
[1] https://www.postgresql.org/docs/devel/catalog-pg-attrdef.html
ack. In this particular area, I think Matlab's
precedent is at least as strong as Wikipedia's.
regards, tom lane
nt was just that changing the back-branch documentation would
require doing additional testing to verify that the proposed value is
an improvement in those branches.
regards, tom lane
k this might be a better
answer, although it's still subject to problems if anyone's logorrhea gets
any worse in naming wait conditions: "SerializablePredicateLockListLock"
is still going to force manually tweaking the column widths.
I sorted the names here, too.
; part).
BTW, for the purposes of this patch I just abused the
func_table_entry/func_signature role values. We could invent new ones,
but I'm not sure if it's worthwhile for just one table.
regards, tom lane
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index
window is...
but the way it's supposed to be read is
string || non-string
or
non-string || string
The devel version of the docs forces the two cases to be on separate
lines, which hopefully will stem the confusion.
regards, tom lane
"(references ...)" text.
regards, tom lane
chapter preface?
The same issue exists for the sub-sub-tables-of-contents for s,
though it's less bad because few of those have grown enormous lists
of 's.
regards, tom lane
ssed to show anybody the code though ;-) ... it was just a brute
force hack.
regards, tom lane
catalog-reformat.patch.gz
Description: catalog-reformat.patch.gz
--- main.css~ 2020-05-10 12:18:39.773129302 -0400
+++ main.css 2020-05-09 21:46:22.424776849 -04
those specific keywords extra space, but it would look weird
in renderings where there's plenty of room anyway.
We're within hailing distance of zero "exceeds the available area"
warnings, so I'd like to get these things resolved.
Comments, better ideas?
regards, tom lane
at('Testing %3$s, %2$s, %s', 'one', 'two',
'three');
-
+
-
+
encode
encode ( bytes
bytea,
so I propose doing that.
regards, tom lane
OGIN defined.
ISTM those statements are contradictory. The two privileges could
only be called orthogonal if it's possible to make use of one without
having the other. As things stand, REPLICATION without LOGIN is an
entirely useless setting.
regards, tom lane
ref
page as such.
regards, tom lane
commit and get it out in the wild.
> ...and so I did. Committed[1].
Thanks, I'll push the docs change in a bit.
regards, tom lane
o need this.)
regards, tom lane
hose columns in a consistent
> with the view definition. Patch attached. Thought?
I already fixed this in my pending patch to restructure the catalog
docs [1].
regards, tom lane
[1] https://www.postgresql.org/message-id/14810.1589128043%40sss.pgh.pa.us
the same
as we are using in s, which this layout is based on.
regards, tom lane
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> ISTM those statements are contradictory. The two privileges could
>> only be called orthogonal if it's possible to make use of one without
>> having the other. As things stand, REPLICATION without LOGIN is a
ide:
https://www.postgresql.org/docs/devel/error-style-guide.html
(see under "Present vs. Past Tense"). I believe we largely conform
to that guideline, though of course exceptions sneak in from time
to time.
regards, tom lane
error message.
regards, tom lane
Bruce Momjian writes:
> On Sun, Mar 22, 2020 at 03:05:01PM -0400, Tom Lane wrote:
>> I don't really think this is an improvement, mainly because that
>> error message is inventing a notation that we do not use in any
>> other error message.
> What do you sugge
Peter Eisentraut writes:
> On 2020-03-24 15:31, Tom Lane wrote:
>> The problem seems to be that cedffbdb8
>> introduced some broken table markup. I wonder why xmllint
>> failed to catch it?
> It's not a validity issue in the DocBook markup. The error comes from
> F
nput and then
try to eyeball what's wrong with it.
Fix pushed.
regards, tom lane
rom pg_ts_parser;
prsname | prsnamespace
-+--
default | pg_catalog
(1 row)
I think you are confusing the parser with something else maybe.
There is a support function named ts_debug ...
regards, tom lane
e past, but I don't immediately see
anything there that's not per the new design.
regards, tom lane
the DB you want to connect to.
regards, tom lane
?
OK by me --- that, too, would be more like the existing catalogs
chapter.
regards, tom lane
ng an existing example with an
unrelated comment.
regards, tom lane
Fujii Masao writes:
> On 2020/05/20 22:32, Tom Lane wrote:
>> OK by me --- that, too, would be more like the existing catalogs
>> chapter.
> Yeah, so I'd like to propose the attached patch.
Hmmm ... I'm not exactly convinced about sticking xreflabels onto
the s as you've done
added some text about the pg_stat_slru view
and just automatically added it above the table, not noticing that that
wasn't what the surrounding stuff did.
regards, tom lane
Daniel Gustafsson writes:
>> On 2 Sep 2020, at 18:43, Tom Lane wrote:
>> I took a stab at doing it that way, as attached. (I couldn't resist
>> the temptation to do some minor editing on adjacent material, too.)
> LGTM. I didn't try to build the docs with this appl
Daniel Gustafsson writes:
> On 30 Aug 2020, at 17:21, Tom Lane wrote:
>> Do you have a feeling one way or the other about whether to repeat
>> some of this text in each of the relevant sub-sections? I initially
>> didn't want to do that, but thinking about how people con
e page not the top. I dunno
how to do that, though.)
regards, tom lane
irectory location
and one wrapper script.
regards, tom lane
Magnus Hagander writes:
> Yeah, that makes a lot of sense. How about like this?
Isn't this pretty duplicative of d2511d713?
regards, tom lane
ould
describe your unspecified reasons for not updating to 12.4?
I'm afraid I'm not a telepath.
regards, tom lane
ers call it "from_json" or "json_in". I'm not real sure
which of those names is preferable, but inconsistency is not preferable.
regards, tom lane
ay that way for long, because nobody else is
really going to care about it.
(FWIW, I generally write a comma myself. But I'm not going
to cry about text that hasn't got one.)
regards, tom lane
e operator names within a cell. IIRC, it's possible to do
that, though the exact incantation isn't coming to mind right now.
> I suppose a commit would change all the index AMs where we document this
> kind of thing.
Yeah, we should make all these sorts of tables consistent.
regards, tom lane
"David G. Johnston" writes:
> On Mon, Aug 17, 2020 at 10:11 AM Tom Lane wrote:
>> Yeah, me either. So here's a proposed patch, fixing a couple other
>> things:
> LGTM
Pushed, thanks for review.
regards, tom lane
" is not an improvement over "which". Otherwise seems OK.
(The proposed patch for generic subscripting will probably need to
rewrite this completely, but for now this is an improvement.)
regards, tom lane
disagree with that. Wouldn't
> it be better to update all of them?
Yeah, probably. See 47046763c for some policy I'd made up about when
to use --- typedef names definitely don't fit.
regards, tom lane
st the operators with their
input types, maybe we should just do what the OP thought was correct
and delete the duplicate operator names. It's already the case that
the table isn't telling you exactly which input types the operators
accept, so why not be a little bit fuzzier?
regards, tom lane
ch
opclass (its native ones, plus the applicable "loose" operators).
Then we only need two columns, opclass and operators.
regards, tom lane
> >=(integer,integer)
> <=(integer,integer)
Hm, do we care quite that much about explaining this difference?
But you're right that we hardly need the "data type" column
per se when the operator column is repeating the same info.
> Thanks for doing the legwork!
Indeed.
regards, tom lane
ed to stall this
> patch for that, since it's a much smaller issue IMV.
Yeah, I think some fooling with the column widths could improve the PDF
results, but it's a minor point.
regards, tom lane
uot; "your end of the tunnel "
Hm, do you have a suggestion for better wording?
regards, tom lane
age,
so I'm kind of inclined to make an editorial pass over the whole thing.
regards, tom lane
"David G. Johnston" writes:
> On Mon, Aug 17, 2020 at 8:31 AM Tom Lane wrote:
>> So this is just a verbatim statement of the algorithm, which is what
>> I was hoping to avoid :-(. But maybe there's no simpler way.
> I got nothin'.
Yeah, me either. So here's a pro
ny
> point a preferred type is made a candidate then it will be chosen.
So this is just a verbatim statement of the algorithm, which is what
I was hoping to avoid :-(. But maybe there's no simpler way.
regards, tom lane
ng not appearing on the same page
won't get seen.
regards, tom lane
recordset() is instructed to return two columns,
the first integer and the second text. The result of
generate_series() is used directly.
regards, tom lane
t if you are used to the
old layout. But the developer community has been looking at this format
for six months or so now, and I think people grew accustomed to it fairly
quickly.
regards, tom lane
we did experiment with extra vertical whitespace to
separate, but abandoned that, possibly because controlling it was too
painful with DocBook.
regards, tom lane
"Jonathan S. Katz" writes:
> On 9/29/20 3:00 PM, Tom Lane wrote:
>> But I think it's a net benefit for HTML output as well, in that the
>> output does adapt much better than before to smaller window sizes.
>> Not everybody wants to dedicate their whole screen to P
design it again right now. If people are still
unhappy in a year or so, maybe there will be some appetite for a revisit.
regards, tom lane
reason for us to insist on changing it.
>> That said, it might be a good idea to be consistent since we seem to use a
>> mix of different styles of chmod.
There is that. But I think the "og-rwx" style is more recommendable,
if we're going to try to standardize.
regards, tom lane
AD only, since it's so minor). Thanks!
regards, tom lane
ot;hosts that MUST use non-encrypted connections".
If that were actually a useful option, maybe it would be worth lengthening
this description to mention all three options ... but it seems OK as-is to
me.
regards, tom lane
really want the original text, best bet is to keep your schema
creation commands in a VCS or the like, outside the database.
regards, tom lane
fit the older branches that way.
regards, tom lane
nce the info they
are presenting is fundamentally different. I don't honestly see much
wrong with the way it is now.
regards, tom lane
and can't) specify it in the query.
The point of the AS feature is to allow specifying the concrete
record type for record-returning functions that don't have a
predefined result record type, like dblink().
I think this error text was written before we had multiple OUT
parameters, so it was okay at the time; but now it needs to be
more precise.
regards, tom lane
rom
(json_to_recordset('[{"a":1,"b":"foo"},{"a":"2","c":"bar"}]') as (x int, y
text), generate_series(1,3)) as x(a,b,s) ;
a | b | s
---+-+---
1 | foo | 1
2 | | 2
| | 3
(3 rows)
would illustrate all the principles.
regards, tom lane
eds to be
> more precise.
Concretely, perhaps like the attached. I was unsurprised to find
that this error condition isn't exercised in our regression tests.
I added some coverage, but maybe that's overkill?
regards, tom lane
diff --git a/src/backend/pars
ct * from rows from
(json_to_recordset('[{"a":1,"b":"foo"},{"a":"2","b":"bar"}]') as (a int, b
text), generate_series(1,3)) as x(p,q,s);
p | q | s
---+-----+---
1 | foo | 1
2 | bar | 2
| | 3
(3 rows)
regards, tom lane
tty sure you should incorporate verbatim in your MD5 input.
The bytes are just binary data, they're not ASCII or encoded
in some way.
regards, tom lane
Bruce Momjian writes:
> On Tue, Oct 27, 2020 at 12:54:36PM -0400, Tom Lane wrote:
>> The removal only happened in HEAD, so I'm unclear on why you back-patched
>> this doc change?
> Uh, at the top of all my branches, I typed:
> ls */src/tools/thread
>
but I'm not quite sure. The costs are 268.19
> and 292.65, and that's about 9% more expensive?
No, the comparison this has in mind is 224.79 (the indexscan on onek
in the last plan) versus 200.33 (the sort on onek in the previous plan).
So 12% is about right.
regards, tom lane
it's a clerical error, but certainly showing these
operators this way is none too helpful. Perhaps including the input types
in this table (and its siblings elsewhere) would be a good thing.
(Looking at these, I'm reminded anew that the sort ordering used by \dAo
is still questionable ...)
regards, tom lane
mmended to put them into separate databases.
regards, tom lane
rrect note among the various
> possibilities more difficult.
Yeah, that used to be pretty unreadable. I think the reformatting of
these tables that I did for v13 helps a lot, though:
https://www.postgresql.org/docs/devel/functions-json.html
regards, tom lane
relevant for GiST indexes. Perhaps it's talking about a deficiency
that was specific to the old rtree code.
regards, tom lane
(1 row)
regards, tom lane
standard only defines this syntax for certain types
such as TIMESTAMP and INTERVAL; but Postgres allows it for any
type name.
regards, tom lane
which acts like WHOLE_LINE
if the argument starts with "|" (and otherwise is normal AFAICS).
That's used by
\g, \gx
\o
\w
regards, tom lane
Daniel Gustafsson writes:
>> On 11 Jul 2020, at 23:36, Tom Lane wrote:
>> + For example, there may be special scripts for creating a database
>> + cluster. There almost certainly will be a mechanism for starting
>> + the server,
> Aren't we really talkin
epetitive; but it would have
the advantage that people could hardly miss it.
I do agree that we ought to do something here. I think only a small
minority of users build their own Postgres installations anymore.
regards, tom lane
diff --git a/doc/src/sgml/runtime.sgml b/
back.)
regards, tom lane
n actual link would be a good idea).
regards, tom lane
ger functions that can be used
to solve common problems without having to write your own trigger
code. See Section 9.28.
This would have the advantage of covering the other built-in triggers
not only suppress_redundant_updates_trigger.
regards, tom lane
Bruce Momjian writes:
> OK, I didn't think there was enough desire to put it its own paragraph,
> but I like the idea of mentioning all of the trigger functions; patch
> attached.
This one WFM.
regards, tom lane
he report!
regards, tom lane
of
support, and I seriously doubt that there's any bug here either. Please
send more detail to the pgsql-general mailing list, and we'll see if we
can work this out.
regards, tom lane
.
regards, tom lane
"David G. Johnston" writes:
> On Sun, Aug 16, 2020 at 2:26 PM Tom Lane wrote:
>> We had a question about why an ARRAY[] construct was resolving the
>> array's type strangely [1].
> In this specific complaint it strikes me as undesirable to have an lossy
>
rbatim statement of the algorithm.
(I see that I already made one attempt at improving the description,
back in 07daff63c, but it's clearly still not good enough.)
Any ideas?
regards, tom lane
[1]
https://www.postgresql.org/message-id/CAOwYNKYfKPfAL4rgP0AO_w0Mn7h8yiXd_Qi9sw
ms
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
@@ -1209,6 +1209,14 @@
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.
regard
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 info in chars
n.
In any case, I don't think this is a documentation issue ...
regards, tom lane
dation
that it's okay to do it.
regards, tom lane
Bruce Momjian writes:
> On Fri, Oct 30, 2020 at 11:09:58AM -0400, Tom Lane wrote:
>> Thinking about it from the perspective of someone dealing with an
>> installation tree not a source tree, maybe the reference should
>> be to "server/catalog/pg_type_d.h". Tha
201 - 300 of 595 matches
Mail list logo
