have bothered with back-patching 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
Pavel Borisov writes:
> This patch little bit clarifies parsing of operators websearch_to_tqsuery()
> function
I pushed a version of this. Thanks for noticing the omission.
regards, tom lane
apparently that entity isn't loaded yet.)
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index b0afaeb..fdbd4a0 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -1365,7 +1365,7 @@ repeat('Pg', 4) P
Alexander Lakhin writes:
> 26.04.2020 22:13, Tom Lane wrote:
>> Use of a new processing-instruction might not be the most elegant
>> way to do this ... anyone have a better suggestion?
> I would use the phrase tag, which is intended for such uses: [1] [2].
Good idea, don
Alexander Lakhin writes:
> 27.04.2020 18:04, Tom Lane wrote:
>> BTW, I tried to also use this markup inside the template for
>> , so we'd only need one font-switching special case not two.
>> Didn't work though --- apparently templates don't get applied
W, the behavior in this area changed 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)
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 requ
ill happen in man-page-format output.
regards, tom lane
p
would be closely modeled on what we did for function-table entries.
Thoughts?
regards, tom lane
[1] https://www.postgresql.org/docs/devel/catalog-pg-attrdef.html
isinclined to go back. In this particular area, I think Matlab's
precedent is at least as strong as Wikipedia's.
regards, tom lane
ed any change
except for addition of the "(references ...)" text.
regards, tom lane
, instead of having it in front
of the 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
ay it's looked in the past, but I don't immediately see
anything there that's not per the new design.
regards, tom lane
u
also need CONNECT on the DB you want to connect to.
regards, tom lane
has LOGIN 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
ntation is (it looks like) 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
d be too
embarrassed 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
_DEFAULT_TRANSFORM_GROUP"
are keywords at all. We could do something with spanspec or morerows
to give 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
355,9 @@ SELECT format('Testing %3$s, %2$s, %s', 'one', 'two',
'three');
-
+
-
+
encode
encode ( bytes
bytea,
so I propose doing that.
regards, tom lane
uding the "type" 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/sg
oing it that way. I think 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
ion N-minus-several. Certainly, whatever
testing was done to justify the new default wouldn't have been done on old
versions; and there might have been relevant changes.
In short: nope, I'm not on board with blindly back-patching such
recommendations.
regards, tom lane
y point 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
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
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
f
page as such.
regards, tom lane
Bruce Momjian writes:
> On Fri, May 15, 2020 at 09:37:30AM -0400, Tom Lane wrote:
>> Why? Our convention generally is to refer to the command, not to the ref
>> page as such.
> Uh, for the release notes, I am referencing the doc page about the
> feature, and without the xr
7;t seem to need this.)
regards, tom lane
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
on muddying an existing example with an
unrelated comment.
regards, tom lane
se I 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
by adding ?
OK by me --- that, too, would be more like the existing catalogs
chapter.
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 y
s
"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
rwise.)
If you 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
_output =
hex, but I don't plan to retrofit the older branches that way.
regards, tom lane
don't look like the view tables, since the info they
are presenting is fundamentally different. I don't honestly see much
wrong with the way it is now.
regards, tom lane
d making that
an actual link would be a good idea).
regards, tom lane
lt-in trigger 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
anks for the report!
regards, tom lane
pushing further back.)
regards, tom lane
(1 row)
regards, tom lane
8.6 by my count. That seems very repetitive; 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
d
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
gt; FLOAT8 '7.3'
> and that is accepted as well.
IIRC, the SQL standard only defines this syntax for certain types
such as TIMESTAMP and INTERVAL; but Postgres allows it for any
type name.
regards, tom lane
ng, 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
box isn't the right place for this kind 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
oss of functionality.
regards, tom lane
on't think 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
other, it is recommended to put them into separate databases.
regards, tom lane
her it's even
still relevant for GiST indexes. Perhaps it's talking about a deficiency
that was specific to the old rtree code.
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
and other minor annoyances in this page,
so I'm kind of inclined to make an editorial pass over the whole thing.
regards, tom lane
urately.
However, I'm having a hard time coming up with wording that describes
this accurately without being a verbatim 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.)
An
"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
> i
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
"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 he
"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
t 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
't stay 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
en the 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
>(integer,integer)
> >=(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
or each
opclass (its native ones, plus the applicable "loose" operators).
Then we only need two columns, opclass and operators.
regards, tom lane
think we need 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
t; "your end of the tunnel "
Hm, do you have a suggestion for better wording?
regards, tom lane
hat anything not appearing on the same page
won't get seen.
regards, tom lane
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 peopl
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
Magnus Hagander writes:
> Yeah, that makes a lot of sense. How about like this?
Isn't this pretty duplicative of d2511d713?
regards, tom lane
ot the top. I dunno
how to do that, though.)
regards, tom lane
ata directory location
and one wrapper script.
regards, tom lane
#x27;m
pretty 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
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
t * from rows from
(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
now it needs 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 --gi
Better
=# select * 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
to HEAD only, since it's so minor). Thanks!
regards, tom lane
dset() is instructed to return two columns,
the first integer and the second text. The result of
generate_series() is used directly.
regards, tom lane
ular
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
a shock at first 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
'm disinclined to redesign 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
"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
e others 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
ntation should
describe your unspecified reasons for not updating to 12.4?
I'm afraid I'm not a telepath.
regards, tom lane
PG Doc comments form writes:
> Description:
> 02000 no_data
> should read no_data_found
Looks correct as stated to me. plpgsql's ERRCODE_NO_DATA_FOUND
(P0002) is a different animal.
regards, tom lane
'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
ead. Looks like src/template/netbsd has an old reference
too.
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
> an
programming environment
altogether.
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". That might help disabuse
anyone who's expecting to find it at that path in the git tree.
regards, tom lane
e in the
connection parameters.
Also, it looks like there's a special case to consider 'localhost'
as matching a Unix-socket connection, if the socket is in the
installation's default socket directory.
regards, tom lane
umentation here:
> https://www.postgresql.org/account/comments/new/12/plpgsql-transactions.html/,
> the procedure is created without incident. However, when I attempt "CALL
> transaction_test1();", I receive the "invalid transaction termination"
> error.
Hmm, it work
PG Doc comments form writes:
> I would be helpful to add that NULLIF and COALESCE need to be of same data
> type.
That's not actually a correct statement ... which I guess just reinforces
your point that the behavior needs to be documented.
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
Bruce Momjian writes:
> On Tue, Nov 10, 2020 at 06:15:29PM -0500, Tom Lane wrote:
>> That is the path underneath the installation "include" directory
>> at which that file will be found.
> Uh, I don't see it:
> $ ls -w 80 /usr/local/pgsql/inc
401 - 500 of 713 matches
Mail list logo
