"David G. Johnston" writes:
> The request is to fix our documentation to use a valid date for the example
> in the paragraph that describes the separator requirement for years greater
> than 4 digits.
Oh! Got it, that should be fixed.
regards, tom lane
ement" would.
By the same token, there is just about no use-case for a function
declared to return "any". The parser will not infer some other
data type the way it would do for "anyelement", so you'll end up
with an object that you can't do anything with.
regards, tom lane
l as well as the server proper). I'd check
for a related server package before you go complaining to the
homebrew folks.
regards, tom lane
hether INSERTs are processed in the
order returned by the data source, which is probably a pretty safe
assumption. Still, SQL is a set-oriented language which means that
it generally doesn't guarantee anything about row order, with the
sole exception being the immediate output of a SELECT ... ORDER BY.
So I think adding such guarantees isn't a great idea.
regards, tom lane
re neatnik-ism than rescuing the chapter from total
irrelevancy.
regards, tom lane
ets
from https://github.com/docbook/wiki/wiki/DocBookXslStylesheets
to someplace convenient and setting the environment variable
XML_CATALOG_FILES to point there.
regards, tom lane
.
Having said that, I'm not sure that substituting "is distinct from
null" in the COALESCE documentation is much better, because it's not
clear to me that we're entirely standards-compliant about what that
means for rowtypes either.
regards, tom lane
have
this setting and always use the
regards, tom lane
.)
How about the attached?
regards, tom lane
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 6646820d6a..a693424a69 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -3369,7 +3369,7 @@ SELECT person.name, holidays.num_w
I happened to come across this:
https://arxiv.org/pdf/1901.01973
I found this to be really interesting reading, so I wonder if
we shouldn't cite it in history.sgml or some such place.
regards, tom lane
in appendix E. But now, not so much. The simplest fix
would be to change this text to point to
https://www.postgresql.org/docs/release/
regards, tom lane
=?UTF-8?Q?Sebastian_Ska=C5=82acki?= writes:
> Looks great to me, thanks!
Pushed, thanks.
regards, tom lane
Daniel Gustafsson writes:
> On 4 Jul 2024, at 07:40, Tom Lane wrote:
>> I happened to come across this:
>> https://arxiv.org/pdf/1901.01973
>> I found this to be really interesting reading, so I wonder if
>> we shouldn't cite it in history.sgml or some such place
Thomas Munro writes:
> On Thu, Jul 4, 2024 at 5:40 PM Tom Lane wrote:
>> I happened to come across this:
>> https://arxiv.org/pdf/1901.01973
> Just by the way, for anyone interested, that paper appeared as a
> chapter in a book "The Pragmatic Wisdom of Michael Stonebr
dlers
forms a subtransaction, which means that transactions cannot
be ended inside such a block.
regards, tom lane
wonder if we could make a tooltip worded like "link to this header"
pop up when you hover over the '#'? That'd improve things a lot
even if we had a better icon.
A different idea is to dispense with the icon and make the section
title itself be a link to itself.
regards, tom lane
t (postal codes for
example) and hence thought that an arbitrary limit was a good thing.
Time to move on.
regards, tom lane
+00B6, ie part of
LATIN-1, so it's *far* more likely to render correctly everywhere
than U+01F517 is. We could also consider the section sign §
(U+00A7).
In any case, a tooltip would help reduce confusion.
regards, tom lane
re and pushed it.
Thanks for the submission!
regards, tom lane
for copying Python.
regards, tom lane
ork. I do not think it's reasonable to extend that policy
to the rest of the manual: in other places, there are too many
distinct topics under consideration and too much reason to make
localized changes.
regards, tom lane
se is omitted altogether, and
hence may fail if the count is not a constant.)
As with SELECT INTO,
the special variable FOUND can be checked to see whether there was
a row to move to.
regards, tom lane
ELECT *", and this bit was meant
to be consistent with that; but if the reader is confused about
how "y" got into the discussion then writing it out explicitly
should help.
regards, tom lane
s should be
> written:
> [ Returning { * | output_expression [ [ AS ] output_name ] } [, …] ]
Agreed.
> Related, select says:
> [ * | expression [ [ AS ] output_name ] [, …] ]
I imagine the RETURNING synopsis was copied from that one :-(
Yes, let's change that too.
regards, tom lane
EATE DOMAIN page:
where domain_constraint is:
[ CONSTRAINT constraint_name ]
{ NOT NULL | NULL | CHECK (expression) }
rather than making readers go look that up. Is that the same thing
you're thinking, or did you have a different idea?
regards, tom lane
m that it's
identical to CREATE DOMAIN.
regards, tom lane
pg_proc.oid
> typanalyzeregproc pg_proc.oid
> The correct reference is pg_proc.proname
No, it's correct as written: regproc is an OID. See
https://www.postgresql.org/docs/current/datatype-oid.html
regards, tom lane
e
copy-and-pasteable" doesn't seem like a good constraint to add.
Another idea perhaps could be to remove enough digits from the
example that it doesn't cause overwidth warnings in the PDF ---
but I'm not sure that's feasible in a 3-column table. Or we
could just drop this one example.
regards, tom lane
hat, if it makes the table narrow enough. Probably need
to set it in italics or something to make it obviously not-data.
> Would do it elsewhere for consistency
Right, we'd have to do it in each entry of this table (that it
is correct for).
regards, tom lane
have a "site administrator" who is not them. Even for
people running Unix/Linux, that text seems like it's making archaic
assumptions.
regards, tom lane
.
The example in the documentation works perfectly well for me.
regards, tom lane
d be "the rest of time" instead of "the test of time"
It's correct as-is --- that's a pretty standard idiom in English.
regards, tom lane
t are you looking at it with?
regards, tom lane
ng that there was possibly an old
live server. You didn't supply enough detail to reproduce the
problem, but perhaps check whether the old and new Postgres versions
were built with similar options.
regards, tom lane
lementation?
I believe it's required by SQL spec. Or more accurately, the spec
says that constraint-triggered actions happen either at the end of the
statement or the end of the transaction, depending on whether you set
them as "deferred".
regards, tom lane
inted at the actual old data directory, not
PGDATA=/var/lib/pgsql/10/data.
regards, tom lane
gt;pgconfig);
if ((fp = fopen(filename, "r")) != NULL)
{
fclose(fp);
return;
}
Do you have a PG_VERSION file in /var/lib/pgsql/10/data?
If so, why?
regards, tom lane
s like it would create
more confusion than is justified.
On the whole I think this is self-inflicted damage. Leaving that
stuff around was just asking for confusion.
regards, tom lane
te to 5.2 until it becomes a lot more
widespread in standard distros.
regards, tom lane
n provenance, mind you,
so maybe that is unrelated). I wonder whether Apple are using more
aggressive optimization flags than other people. OTOH, while it would
not surprise me if Apple put some work into making zlib go fast, it
seems less likely that they'd expend effort or risk on xsltproc.
regards, tom lane
MacPorts build is the outlier, leaving us with the theories that it was
built at -O0 or there's a performance bug in the newer source releases.
I have no doubt that xmlsoft.org would be interested if you can narrow
it down to the latter.
regards, tom lane
uld try removing those parts of
stylesheet-speedup-common.xsl and see what happens ...
regards, tom lane
> SQL state: 42601
The described symptoms sound like you're trying to use <-> with a pre-9.6
server. Since that feature was added in 9.6, it won't work.
We generally don't recommend reading documentation versions that don't
match your server.
regards, tom lane
Rudy Barbieri writes:
> But it could be better improve the documentation highlighting that in
> previous versions there was a bug.
I see no bug here ... failing to recognize an operator that was added in
later versions can hardly be classed as a bug.
regards, tom lane
y enough by looking at array_send and array_recv:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob_plain;f=src/backend/utils/adt/arrayfuncs.c;hb=HEAD
regards, tom lane
ould provide the exact
> commands you think should work and the error message you receive when you
> execute said commands.
I think probably the OP is confusing the current COPY syntax with the
obsolete form documented at the bottom of the COPY page.
regards, tom lane
son grammar.)
regards, tom lane
nning initdb directly, or some script that perhaps
sudo'd internally?
regards, tom lane
cann.org/pipermail/tz/2017-December/025682.html
You haven't said what it is you are hoping to accomplish, so it's
hard to say if there's some safer way to do it.
regards, tom lane
time,
then it's something to avoid.
regards, tom lane
will fix, thanks for noticing!
regards, tom lane
iggers are fired for each actual row change,
including changes in partitions or child tables that are not directly
named in the query.
Possibly "row operation" would be better than "row change".
regards, tom lane
like
In contrast, row-level triggers are fired for individual row change
events, and the triggers that are fired for an event are those
attached to the specific table containing the changed row, even if
it is a partition or child table not directly named in the query.
regards, tom lane
Bruce Momjian writes:
> Oh, I am sorry. I was focused on the first part of the sentence and
> didn't notice your change to the second part. How is this attachment?
Seems same as your previous version?
regards, tom lane
Bruce Momjian writes:
> How is the attached patch?
Maybe also make that text into a hyperlink to the SPI manual chapter?
regards, tom lane
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
101 - 200 of 713 matches
Mail list logo
