Bruce Momjian writes:
> OK, updated patch with both fixes.
AFAICS that's the same patch you posted before.
regards, tom lane
=?utf-8?q?PG_Doc_comments_form?= writes:
> However, that list isn't complete, eg. TIMESTAMPTZ, JSON, UUID... are
> missing, probably because these aren't in SQL standard.
Those are not key words. They're just names.
regards, tom lane
one was inspired to
write something comparable in length to the existing per-index-type
chapters. But I'm not volunteering to do that, so if it's a chapter it'd
be a mighty thin one to start with.
Anybody have a preference, an objection, or a better idea?
regards, tom lane
Peter Eisentraut writes:
> On 2/5/18 18:51, Tom Lane wrote:
>> So I can see two ways to approach this: add two new subsections at the end
>> of xindex.sgml, or create a new chapter about b-trees in Part VII
>> ("Internals") to go beside the existing ones about t
n passing in the LIKE docs. But we should not
put them in a table with the LIKE ops themselves, IMO. That would just
invite confusion about what they do and whether you're supposed to use
them directly.
regards, tom lane
ssions must appear in select list
What do you find unclear about this error message?
The reason seems clear enough to me: if the ordering expression isn't one
of the values that are being de-duplicated on, then there isn't a unique
value to associate with each surviving row for sorting purposes.
regards, tom lane
or is defined.
In SQL:2011, it's 7.13 general rule 3) b) iii) 3) B),
on page 420 in the draft version I have.
regards, tom lane
did > 100 AND name <> '')
> );
Hmm ... that example is legal syntax as-is, but considering that the
explanation for it says specifically that it's table-constraint syntax
not column-constraint syntax, I think you're right.
regards, tom lane
hat on the
grounds that it was unmaintainable and also incompatible with some
documentation output formats. I'm not too sure what the state of
play is on the latter point, now that we've switched to XML.
regards, tom lane
to accept SVG-format figures, but we were having a hard time
figuring out what tools to recommend for editing them, because available
editors have no respect for readability or preserving small deltas when
rewriting SVG files.
regards, tom lane
g Postgres data
file changes :-() but that doesn't mean it isn't a problem for us.
How can we resolve these issues?
regards, tom lane
Craig Ringer writes:
> On 26 February 2018 at 12:16, Tom Lane wrote:
>> How can we resolve these issues?
> Question the assumptions and requirements. Why do we actually _need_
> diffable, mergeable images? Sure, it'd be *nice*, but what's the real world
> impact if w
some very old branches like 9.2, but not OK in any
of 9.3 through 10. So I'm thinking that somebody broke some
version-specific website markup. No idea how to investigate further,
but I'm cc'ing the www list for comment.
regards, tom lane
ale explicitly.)
regards, tom lane
r the SQL standard's syntax diagrams or our actual
bison grammar, they're both unreasonably complicated. Novices would
not thank us for reproducing that in full detail in the basic SELECT
syntax summary, and I'm not sure experts would either.
So, surely there's room for improve
"Jonathan S. Katz" writes:
> I would say that’s the exact reason why it should be documented,
> so it’s clear that it was by design.
Seems reasonable. Maybe something in 8.7.4 enum implementation details?
regards, tom lane
TG_something' as it is for trigger local variables.
Ugh, yeah, that's a thinko isn't it. Will fix, thanks for noticing!
regards, tom lane
Tatsuo Ishii writes:
> For me it seems there's a typo in protocol.sgml. I am not an English
> native speaker and I might be wrong though.
You're not wrong.
regards, tom lane
if it broke then.
regards, tom lane
hardly
unlikely that the input is different.
regards, tom lane
psql's help.
regards, tom lane
e clear?
+1 ... I thought the same. Will go fix it.
regards, tom lane
rhaps there's something we could change to make this clearer,
but I'm not sure what.
regards, tom lane
I'm pretty sure that general limitation is already documented elsewhere.
I don't believe that it's possible to make a 256 Gb jsonb. How will
that fit in the varlena header?
regards, tom lane
what we think the use-case for this
table is at all. Different use-cases result in different ideas about the
best ordering.
regards, tom lane
on=# create table bar as select 1 as x;
SELECT 1
regards, tom lane
For the use case of "why did I get this error", I'd say that looking in
Appendix A is quite unhelpful, and sorting it differently wouldn't make
it any more helpful.
regards, tom lane
research to figure out what is safe.
regards, tom lane
R UPDATE code is able to identify a target table in many cases where
* the other code can't, while the non-FOR-UPDATE case allows use of WHERE
* CURRENT OF with an insensitive cursor.
regards, tom lane
you could just stop with
"guaranteed to be updatable"; I don't think the rest adds much.
regards, tom lane
ble.
I don't want to sound like I think what we've got now is the peak of
perfection, because it isn't. But we have to strike a balance between
formal correctness and readability for users who aren't familiar with
formal syntax notations. It's a difficult problem.
regards, tom lane
attached patch.
Pushed, thanks!
regards, tom lane
t was, in fact, like that initially. Peter E. changed it in commit
0d9bdbcaae0, without any discussion that I remember seeing. I've never
been very happy with "alphabetical order trumps all other considerations"
as a documentation rule, and this seems like a good example of why not.
regards, tom lane
lues using PQgetvalue.
> This isn't really a comment on the documentation.
Indeed. The submitter did file a bug a bit later, and we dealt with it
over there.
regards, tom lane
and
would cause the cursor declaration to fail, too.
regards, tom lane
the old toolchain, but I think mostly the same
tags were complained of. Don't know the cause.
regards, tom lane
re
not trustworthy permanent URLs.
> Maybe we should be
> looking for some more stable source of similar information?
Exactly.
regards, tom lane
o fix it there, since it's
not the documented process.
regards, tom lane
pe "help" for help.
I can replicate your symptoms if there's not actually a matching
entry in the .pgpass file ...
regards, tom lane
've successfully created the dblink extension in a given
database, and yet you still don't see any dblink_fdw, you might
need to "alter extension update" to bring dblink to something
newer than 1.0.
regards, tom lane
ks for catching that!
regards, tom lane
available somewhere,
if "go dig in the git repo" doesn't seem like an adequate answer
for that.
Thoughts?
regards, tom lane
"Jonathan S. Katz" writes:
>> On Aug 5, 2018, at 6:57 PM, Tom Lane wrote:
>> ... We could discuss ways
>> of making a complete release-note archive available somewhere,
>> if "go dig in the git repo" doesn't seem like an adequate answer
//www.postgresql.org/docs/*/static/release-*.html
doesn't exist, then redirect to
https://www.postgresql.org/docs/old-release-notes/static/release-*.html";
it might be worth doing.
regards, tom lane
e branches). But that
seems pretty confusing, and prone to redirection loops if we also have the
other thing.
regards, tom lane
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
301 - 400 of 691 matches
Mail list logo
