nough. It's certainly attractive that this doesn't seem like it'd entail
any manual effort once it's set up initially.
regards, tom lane
o overwrite the wrong table entries,
can we recover?
This doesn't seem insoluble, but it might mean a bit more work to do
to ensure we can revert back to an earlier version of that table.
regards, tom lane
"Jonathan S. Katz" writes:
>> On Aug 6, 2018, at 3:27 PM, Tom Lane wrote:
>> Actually, a concrete reason why that might not be good is that it results
>> in having a single point of failure: once we remove branch N's relnotes
>> from the active branches, t
HTML generated from the XML in some other stuff, but I don't know any
details. If nobody pops up here and answers your question in a reasonable
amount of time, try over at pgsql-www.
regards, tom lane
question is whether this deserves to be cross-referenced from
elsewhere. I agree with Bruce that it seems unlikely to be helpful.
regards, tom lane
7;re getting at here, I think, but that seems like a
completely wrong/misleading statement of the issue. Joe, can you think of
better phraseology?
regards, tom lane
goes against every principle of archiving. Taking old notes files
out of the tree once we've stopped updating them would at least put
a limit on how long they're exposed to historical revisionism.
regards, tom lane
Peter Eisentraut writes:
> On 06/08/2018 00:57, Tom Lane wrote:
>> Anyway, I'd like to propose a compromise position that I don't think
>> has been discussed before: let's drop release notes for branches
>> that were already EOL when a given branch was rele
we could reference there, it'd be
worth doing, but I don't see much value in linking to sample FDWs just
because they happen to be part of the main distribution.
regards, tom lane
t describes creating
any sort of object ought to repeat this information. I doubt that people
would find that to be an improvement.
regards, tom lane
Flavio Henrique Araque Gurgel writes:
> Em ter, 28 de ago de 2018 às 18:21, Tom Lane escreveu:
>> You could as well argue that every single page that describes creating
>> any sort of object ought to repeat this information. I doubt that people
>> would find that to be an
amp" (which will not be subject to any further conversion when
it's displayed).
The existing text is indeed a bit deficient, because it fails to
draw a clear boundary between what the AT TIME ZONE operator is
doing and what is being done by the timestamp(tz) I/O functions.
But you're not making it better.
regards, tom lane
explain this behavior clearly
without mentioning that timestamp with time zone values are always
stored in UTC and what AT TIME ZONE really does is convert between UTC
and the specified zone (in a direction dependent on which type is
supplied as argument).
regards, tom lane
n't. As with the pow() case, this'd
basically be enlarging our exposed surface of frozen API, and I don't
think that's desirable.
regards, tom lane
and will be in the next minor
> releases. Thanks.
If you're thinking of 6f1591955, you don't seem to have back-patched
that further than v11.
regards, tom lane
must be a complete sentence that stands on
> its own.
I am unfamiliar with this grammar "rule", and vigorously dispute that
anyone follows it in the real world.
regards, tom lane
not quite seeing how Makefile.global would end up
doing that, but perhaps it's confused about vpath vs regular build.
Another theory is that configure went wrong somehow and inserted
bogus values into Makefile.global; was there any sign of distress
while running configure?
regards, tom lane
the
> public."myTooImportantTable"
If you want to be sure you drop a temp table and not a regular one, say
DROP TABLE pg_temp.mytable;
There's no need for new syntax.
regards, tom lane
lt
value has been explicitly set will have an entry here".
regards, tom lane
ut that's how the spec is written.)
Is your complaint just that this is inadequately documented?
I see that it's not spelled out in so many words on that page.
regards, tom lane
take that out, because
it's not appropriate here. There might be room for an additional section
later in the chapter that discusses INCLUDE, but we shouldn't be
cluttering the discussion of fundamental concepts like unique indexes
with that.
regards, tom lane
"Jonathan S. Katz" writes:
> On 11/20/18 9:59 AM, Tom Lane wrote:
>> Yes. That was a dumb idea; the correct fix is to take that out, because
>> it's not appropriate here. There might be room for an additional section
>> later in the chapter that di
arlier
in chapter 11. Right now it's near the end because it's mostly
info about an implementation detail; but it wouldn't be hard to
make the argument that covering indexes are more important than,
say, indexes with custom collations. Should we move it, and if
so to where?
regards, tom lane
Alvaro Herrera writes:
> On 2018-Nov-20, Tom Lane wrote:
>> I'm also wondering whether to move that section someplace earlier
>> in chapter 11. Right now it's near the end because it's mostly
>> info about an implementation detail; but it wouldn't be h
ple might not be familiar with that usage,
so I've got no objections to rewriting it more clearly --- any
suggestions?
regards, tom lane
Jeff Janes writes:
> I don't know what to do about the visual misleadingness of single-entry
> TOCs in general, but at least we can make this specific cross reference
> more specific.
Agreed, done.
regards, tom lane
text_to_cstring (PG_GETARG_TEXT_PP (1));
> cnt = PG_GETARG_INT32 (2);
You're right. Will fix, thanks for the report!
regards, tom lane
838fe25a9 of 2002-04-01) but it was changed later
that month (ccfaf9067 of 2002-04-29) when we added schema permissions
checks. Evidently I forgot to update the docs to match :-(
Will fix, thanks for noticing!
regards, tom lane
ease-11.html#RELEASE-11-ACKNOWLEDGEMENTS
Seems reasonable, but note the lag time --- unless somebody does
something out of the ordinary, those pages won't actually have
such tags till after the February minor releases.
regards, tom lane
ite the contrary. And, btw,
> client_min_messages accept both value.
I don't see anything particularly wrong here. The reason INFO is not
listed for client_min_messages is that it's not a useful setting:
INFO messages will be transmitted to the client regardless of what
client_min_messages is set to.
regards, tom lane
l/rfc7159.
Evidently whoever updated it didn't bother to back-patch into old
branches.
regards, tom lane
Michael Paquier writes:
> On Wed, Jan 02, 2019 at 06:11:55PM -0500, Tom Lane wrote:
>> In PG v10 and up this link goes to https://tools.ietf.org/html/rfc7159.
>> Evidently whoever updated it didn't bother to back-patch into old
>> branches.
> I don't think th
jority of them (though maybe not every one, not sure).
regards, tom lane
.
Why not?
> Probably DOC should explicitly say that if LATERAL function return empty set
> then current row is excluded from result set
That would be wrong for "LEFT JOIN LATERAL ...", so it does not seem
like an improvement.
regards, tom lane
you could create your own modified configuration if you
don't like what the standard one does. The stopword list, in particular,
is quite trivial to modify.
regards, tom lane
want to document that? It's not the standard-approved
way of making a transaction read-only.
regards, tom lane
e supported
back branches or just establish it going forward. Maintaining the notes
could be pretty confusing for the next few years if we do the latter,
though.
regards, tom lane
If I haven't heard objections, I'll see about making this happen
during the first week of Feb (after the CF closes, but before
it's time to do the February releases' notes).
regards, tom lane
| func
pg_catalog | round | numeric | numeric, integer| func
(3 rows)
The description in the docs matches reality AFAICS.
regards, tom lane
, it very
often applies to several release branches; and when that happens
we almost always use identical release-note entries for all the
branches.
Another possible source of confusion is the version number format
change. 10.4 is a minor release in the v10 branch, not a major
release such as 9.6
"Jonathan S. Katz" writes:
> On 1/26/19 10:06 AM, Tom Lane wrote:
>> If I haven't heard objections, I'll see about making this happen
>> during the first week of Feb (after the CF closes, but before
>> it's time to do the February releases' no
"Jonathan S. Katz" writes:
> On 2/4/19 11:12 AM, Tom Lane wrote:
>> It's not quite clear to me what the policy would be for removing
>> back-branch links from this list when old versions drop out of support.
>> Should we go back and remove them in surviving b
"Jonathan S. Katz" writes:
> On 2/4/19 4:25 PM, Tom Lane wrote:
>> After a bit more thought, I'm inclined to propose that the policy be
>> that we *don't* update the surviving back branches for branch retirement.
> ...so I guess in turn, we would not update
"Jonathan S. Katz" writes:
> On 2/4/19 11:12 AM, Tom Lane wrote:
>> Just for the record, this change causes the time to build HEAD's
>> HTML documentation to drop from ~120 sec to ~95 sec for me; the
>> size of the resulting html/ directory drops from 21MB t
possible".
Anyway, if people want something resembling the old presentation,
I think the way to get there is to have some sort of aggregate
release notes in a separate place on the web site. We'd discussed
that briefly upthread, but no one's volunteered to push it through.
regards, tom lane
"Jonathan S. Katz" writes:
> On 2/5/19 9:12 AM, Tom Lane wrote:
>> Anyway, if people want something resembling the old presentation,
>> I think the way to get there is to have some sort of aggregate
>> release notes in a separate place on the web site. We'
;d be willing to do most of the legwork in populating this repo,
if someone else were to handle the website plumbing.
regards, tom lane
he later
branches might be more up-to-date: that text is *the same*, modulo
toolchain-forced markup differences, in every branch; or at least
if it isn't it means I screwed up.
regards, tom lane
Andres Freund writes:
> On 2019-02-05 12:10:57 -0500, Tom Lane wrote:
>> For something like release-9-6-10.html, there's no value in having it
>> appear in three or four different places. You can't even argue that
>> the later branches might be more up-to-date: tha
Andres Freund writes:
> On 2019-02-05 12:24:00 -0500, Tom Lane wrote:
>> Huh? The release note contents are identical cross-branch.
>> I know, because I'm generally the one making them.
> The point is that links in release-$version.html in /current/ or in a
> ma
"Jonathan S. Katz" writes:
> On 2/5/19 11:37 AM, Tom Lane wrote:
>> After further thought about that, I'm liking the idea that was
>> discussed upthread of setting up a separate git repo for the
>> aggregate release notes.
> The contrary point I will make
PG Doc comments form writes:
> In "Table 8.7. bytea Literal Escaped Octets", the backslash character should
> be escaped as '\\' or '\134', not '\' or '\\134'.
Yup, you're right, somebody had a brain fade there.
Thanks for noticing!
regards, tom lane
ation are you looking at?
PG hasn't supported server-side autocommit since 7.3.x. There is
an autocommit variable in psql, but we concluded the server-side
feature broke far more client code than it helped.
regards, tom lane
x27;s a bit unfortunate that ecpg's command looks exactly like
a server command, but there you have it.)
regards, tom lane
safe bet at this point that that feature isn't ever
coming back, so I'd be good with ripping out the whole para.
regards, tom lane
e going to have massive, unreadable,
and mostly content-free diffs in every patch.
regards, tom lane
d treat them much as we do for bison output files:
we'll supply them in tarballs but you'd better have the relevant
tools if you want to build docs from a git pull. However, that
may be assuming too much about the portability of the tools ...
regards, tom lane
Peter Eisentraut writes:
> On 2019-03-11 15:50, Tom Lane wrote:
>> Ideally, we'd treat them much as we do for bison output files:
>> we'll supply them in tarballs but you'd better have the relevant
>> tools if you want to build docs from a git pull. Howev
OWNED page for this behavior?
The REASSIGN OWNED page does mention that it doesn't touch privileges
on non-owned objects, but I agree that it'd be better to be explicit
that that applies to default privileges. Will fix, thanks for reporting!
regards, tom lane
Peter Eisentraut writes:
> This has been committed. The SVG images are committed as well, so no
> new tools are required.
Buildfarm member alabio seems less than pleased.
regards, tom lane
mits are more
significant for this variable than for others?
regards, tom lane
#x27;ve attached a patch that does this, with
> some additional wording around the examples.
Yeah, this seems unnecessarily confusing. I tweaked your extra wording
a bit --- I didn't like referring to the index as covering a range,
because it's really excluding a range not including one.
Pushed.
regards, tom lane
a literal string constant. But surely
4.1.2.7 makes it plain that the discussed syntax is for constants.
You might need to read 4.2.9 "Type Casts" instead.)
regards, tom lane
ently points at
http://www.joeconway.com/plr.html
which does look a bit outdated ...
regards, tom lane
e NFS server, not
> the mount options on the NFS client.
Well, the DBA might also be the NFS server's admin, so I think we ought
to explain the correct settings on both ends.
regards, tom lane
owsers
but others (at least Safari) cut off the image.
regards, tom lane
valid" once all the pieces are attached.
However, I cannot find any coherent documentation explaining how
to do this (or why you'd want to). Am I just looking in the wrong
places?
regards, tom lane
BTW, is there anything equivalent for unique/pkey constraints?
I tried "add constraint unique ... not valid" and just got a
raspberry.
regards, tom lane
it's too late to
change it now.
There's probably some merit in having the documentation avoid the
use of "infinity" when it really means "unbounded", but I'm not
sure we can avoid it altogether without being obscure.
regards, tom lane
w.postgresql.org/docs/current/typeconv-union-case.html
It doesn't mention COALESCE explicitly, though ... and I imagine
digging in the code for coerce_to_common_type callers might find
some other cases that aren't listed there.
regards, tom lane
Bruce Momjian writes:
> Where do we document the pg_config SQL function?
We don't, because it's just the infrastructure under the pg_config view.
regards, tom lane
Bruce Momjian writes:
> On Sat, May 11, 2019 at 05:45:01PM -0400, Bruce Momjian wrote:
>> On Sat, May 11, 2019 at 05:27:23PM -0400, Tom Lane wrote:
>>> We don't, because it's just the infrastructure under the pg_config view.
> Uh, I listed it under "Functions
ch" instead.)
This distinction is widely ignored in casual speech or writing, but
it's still recognized in formal writing. I think our manual is
formal enough that we should try to get it right.
regards, tom lane
e, wctype(3) is more important if it exists, and
in the third place what a reader actually wants to know is that this
is controlled by the LC_CTYPE server parameter. It'd likely be better
to dump the man-page reference altogether and instead point readers to
our "Locale Support" chapter.
regards, tom lane
ly
used options from obscure ones. I don't have any concrete
proposal to make right now, but I am hoping to kick off a
discussion about what such an organization would look like.
regards, tom lane
ssword:" prompt is not showing up
on your terminal. That could be a bug, but I'm not familiar enough
with the Cygwin environment to diagnose it.
> Any suggestions on what to do would be appreciated.
You'd probably be better off asking for help about this on the -novice
or -bugs lists than -docs.
regards, tom lane
touched
by users of SPI.)
Not wedded to that, but it would reduce the risks of future mistakes
of this same sort.
regards, tom lane
rst EXPLAIN I get
Gather (cost=1000.00..11675.10 rows=1 width=8) (actual time=1.215..45.218 rows
=100 loops=1)
which without ANALYZE would just be
Gather (cost=1000.00..11675.10 rows=1 width=8)
The rows=1 estimate is equally wrong either way, but you don't get to
see the correct value without ANALYZE.
regards, tom lane
recollection that we once had such lists in the
TOC (because that was the default behavior for whatever toolchain we
were then using) and later took them out precisely because they were
useless. Not sure how a list of figures would be any more useful.
regards, tom lane
re's use in
a list of them. It's not like it will be any harder to make that change
in a year or two than it is today.
regards, tom lane
Isn't it the other way around, that the partition key column(s) must be
included in the primary key? Maybe I'm confused, but it seems like
we couldn't enforce PK uniqueness otherwise.
regards, tom lane
s complained before that it was ambiguous.
But, if we're going to change it, let's just s/midnight/00:00:00/
and be done. Making up fancy terminology doesn't improve matters.
regards, tom lane
[1] git blame dates the text to commit 1b342df00 of 2002-11-11, a
l as a primary
> key)" right after "a unique constraint". Thoughts?
I'd leave that alone. I don't think the parenthetical comment about
primary keys in your new text is adding much either.
regards, tom lane
really simple way to make it shorter is to say "00:00", leaving
out the seconds.
regards, tom lane
current policy is that as long as you're subscribed
to at least one PG list you can post to any of them.
regards, tom lane
since there's no actual functional change here.
regards, tom lane
Of course, that was me fat-fingering. Fixed in the attached v3. Thanks for
> reviewing!
Pushed with some marginal additional fiddling with the comments.
regards, tom lane
ban
entirely, because the rendering is completely disproportional to the
meaning.
(Or, maybe, somebody could tinker with the stylesheets?)
regards, tom lane
the existing wording seems like perfectly good English to
me, while your revision is at best awkward.
regards, tom lane
n mind. I wouldn't necessarily remove the inheritance section;
it's talking about OOP-style inheritance, which you can't get
with partitioning.
regards, tom lane
would just move the
set of failure conditions around, so I'm unconvinced that it'd
be an improvement.
regards, tom lane
e second formulation is
pedantically correct, but also unintelligible.
Maybe we could make it say "run in parallel with non-DDL activity" ?
regards, tom lane
n that.
There's no definitive right answer on the pronunciation.
It might be best to try to cast your sentences so that the issue
doesn't come up ;-)
regards, tom lane
ough the cracks if you
add them to the commitfest page.)
regards, tom lane
m changing the descriptions of individual options.
They're just ordered differently, and there is more text
around them. I did yield to temptation in some small ways
though.
Comments?
regards, tom lane
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/in
ow-by-blow discussions of decades-old
AIX or HPUX bugs either; nor recommendations to use gcc 2.95.3 ;-).
The HPUX section actually seems totally unnecessary after removing
info that is obsolete or duplicative.
Proposed patch attached.
regards, tom lane
diff --git a/doc/src
devel because commit used
some random OIDs above 9K".
regards, tom lane
ink it's the sort of thing that we sometimes cover in the
"source code" changes of the release notes. But yeah, 09568ec3d's
idea was pretty much fully superseded by a6417078c, so if we're
going to document anything it should be the latter not the former.
regards, tom lane
ase identifiers have to be double-quoted anywhere
in SQL. See
https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
particularly the last para in 4.1.1.
regards, tom lane
Andres Freund writes:
> On 2019-08-30 12:35:09 -0400, Tom Lane wrote:
>> I think it's the sort of thing that we sometimes cover in the
>> "source code" changes of the release notes. But yeah, 09568ec3d's
>> idea was pretty much fully superseded by a6
201 - 300 of 713 matches
Mail list logo
