ne characters are also disallowed.
I'm not sure why you would think that specscanner.l is relevant
here. It's for parsing our (rather idiosyncratic) "isolation
test" spec files, not SQL.
regards, tom lane
Laurenz Albe writes:
> This thread doesn't look like we're going to find a wording that will
> make everyone happy, but I believe that this patch is a clear improvement.
Pushed with the "command message" wording. Thanks for the discussion!
regards, tom lane
r, it's flat wrong for the multi-statement-query-message
case, because surely all those statements are client-issued. I'm okay
with this text leaving out nitpicky details, but it should leave the
reader with a mental model that more or less matches reality.
regards, tom lane
idn't want to mention protocol details
here. I can't argue with documenting it in the protocol chapter
though. So about like this?
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 6b327d4fd81..5818457bf48 100644
--- a/doc/src
timestamp is set by copying statement timestamp
at the moment of beginning a transaction.
regards, tom lane
given them the right mind-set about what is
important.
regards, tom lane
xplain it?
I understand David's allergy to mentioning the wire protocol. Would
"client message" be better than "protocol message"? I also still like
"command message", even if we're avoiding the word "command" elsewhere
in the para.
regards, tom lane
... so concretely, about like this?
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 6b327d4fd81..ed30dbe7ccd 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -11244,13 +11244,13 @@ now()
CURRENT_TIMESTAMP, but
Laurenz Albe writes:
> Perhaps the remark should say "protocol message" or "frontend-backend
> protocol message" to make clear that we are not talking about an
> SQL statement here.
Yeah, that seems like a good idea.
regards, tom lane
Cool. I'll push after the beta2 release freeze lifts.
regards, tom lane
I figured out how to make the 003_peer.pl tests for \1 less
hacky, and pushed that. Here's a proposed patch for the
documentation side of things, including your suggestion to
make pg_ident.conf.sample match up better.
regards, tom lane
diff --git a/doc/src/sgml/c
ed settings.
regards, tom lane
would improve matters?
Although "statement message" doesn't feel right, so maybe leave that
one alone.
regards, tom lane
Daniel Gustafsson writes:
> Or perhaps ”values are separated by a tab character”?
WFM
regards, tom lane
everal tabs on each line, so use of the singular
isn't quite right. However, the best alternative phrasing I could
come up with is "each instance of white space is actually a single tab
character", and that doesn't seem any more understandable. So maybe
it's best left as you have it.
regards, tom lane
ks to be complaints because the comments
in the code don't exactly match the comments in the documentation.
I'm not clear whether "they should match exactly" is a useful goal.
The two cases are oriented towards different audiences.
regards, tom lane
the substitution code could be quite broken and it wouldn't
notice. But I don't offhand see a way to improve that without
making assumptions about the incoming name...
regards, tom lane
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 332fad
for multiple replacements.
> Also, should we attempt to align this documentation and
> pg_ident.conf.sample as pertains to pg-username vs. database-username?
Agreed that making pg_ident.conf.sample match would be an improvement.
regards, tom lane
akes it
> incorrect; and wouldn't be good English even if it was.
The existing sentence is pretty mangled English, though. I think
it would be clearer as
When the database-username field is a regular expression, it is
not possible to use \1 within it to refer to a capture from
the system-username field.
Thoughts?
regards, tom lane
e. I'd include text along the lines of "The data inserted
above could also be inserted from a file containing:".
regards, tom lane
Dean Rasheed writes:
> On Sat, 21 Jun 2025 at 18:09, Tom Lane wrote:
>> Clearly these functions must reject NaN histogram bounds, for
>> the same reason they reject infinite bounds. But I don't see
>> any reason why they couldn't treat a NaN operand as valid
Dean Rasheed writes:
> On Fri, 20 Jun 2025 at 22:19, Tom Lane wrote:
>> So concretely, how about the attached?
> LGTM (though I'm not sure it really needs the word "therefore" in the
> first hunk).
OK, done that way.
> There are also a couple of code comments
more explicit.
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 8d7d9a2f3e8..11676b63c82 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -1824,13 +1824,24 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at lea
sed, with bucket 1
now being the one just below low, and the inclusive bounds
now being on the upper side.
plus an example.
regards, tom lane
f width_bucket (the one taking an array of lower bounds)?
Perhaps this change provides enough context, but I'm unsure.
regards, tom lane
7;t see a reason to do it differently here.
regards, tom lane
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> On 2025-May-13, Tom Lane wrote:
>>> "Another option that is often preferable is to remove the partition
>>> from the partitioned table but retain access to it as a table in its own
>>> right."
>> AFAICS,
> right.
AFAICS, it's correct as written.
regards, tom lane
king and specialized
operators and functions (see ).
+ They also simplify comparisons of inconsistently-written addresses,
+ such as abbreviated and unabbreviated IPv6 addresses.
regards, tom lane
Per our git log, we've not attempted to
sync this code with upstream since 2005.
regards, tom lane
no longer be defined.
> Maybe you should add that not only the function will be deleted, but also
> the 'color' column of the 'my_colors' table?
This paragraph is concerned with the dependency behavior of functions,
so I think adding that comment would just be off-topic complexity.
regards, tom lane
s still applicable to versions in the field.)
I concur with David that we should just drop the para. It's merely
confusing now. If you have a generated constraint name, it won't
require double-quoting unless your table or column name does, and
if they do you are doubtless already quite familiar with how
quoting works.
regards, tom lane
David Rowley writes:
> On Wed, 9 Apr 2025 at 14:33, Tom Lane wrote:
>> Maybe better:
>>
>> Other possibilities will be excluded for lack of join clauses.
>> (In reality, use of EquivalenceClasses would allow us to
>> deduce additional join clauses that allow mo
clauses.
(In reality, use of EquivalenceClasses would allow us to
deduce additional join clauses that allow more join
combinations, but here we ignore that to preserve the
simplicity of this example.)
regards, tom lane
aking the examples use
some other operators that are not equijoins. But I wonder if that
would not be more confusing rather than less so.
regards, tom lane
I suppose it might be helpful to add something along the
lines of "if you are using a pre-packaged version of Postgres, please
consult the packager's documentation".
regards, tom lane
ntity column.
See CREATE
TABLE for details.
Where do you see a pointer to CREATE SEQUENCE on that page?
regards, tom lane
se internally to represent OTHERS. We could use
-1, which AFAICS cannot be generated by MAKE_SQLSTATE.
regards, tom lane
Robert Treat writes:
> On Thu, Feb 6, 2025 at 5:33 PM Tom Lane wrote:
>> Here's a combined proposal that also adds glossary entries.
> +1
OK, pushed.
regards, tom lane
Robert Treat writes:
> On Mon, Feb 3, 2025 at 12:23 PM Tom Lane wrote:
>> Hmm, I kind of like the up-front statement that timestamptz stores
>> UTC. How about this simpler change?
> I thought the re-order made sense since the preceding paragraph talks
> exclusively ab
Zulu
GMT+10 GMT+3 GMT+7 GMT-1 GMT-13 GMT-4 GMT-8 UCT
Maybe we could move the info to the Glossary, but that seems like
a separate matter from what's under discussion here.
regards, tom lane
suitable alterations (or added to the end of
Architectural Fundamentals, perhaps). Both of these pages are
oriented towards "access Postgres from a terminal command line",
which I concede is probably a minority thing anymore.
regards, tom lane
politicians keep changing the
DST laws, so the meaning could change. In certain cases like
appointment calendars, tracking local law is just what you want
... but in cases like flight schedules, probably not.
regards, tom lane
e in supporting
two different implementations.
regards, tom lane
parameter,
because its behavior
is entirely determined by the OVER clause.
regards, tom lane
2
sales | 1 | 5000 |1
sales | 4 | 4800 |2
sales | 3 | 4800 |2
(10 rows)
The ranks are separate within each partition (depname), and
within a partition rows having the same salary get the
same rank.
regards, tom lane
web/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=d7f9c00c4099bd86c39ce79c997123a2a0ca6782;hb=HEAD
starting more or less from the a_expr production.
Keep in mind that this is a moving target, as we frequently add
new syntax features.
regards, tom lane
section (9.7.3). For example,
regression=# select substring('foobar', 'o.b');
substring
---
oob
(1 row)
regression=# select substring('foobar', 'o.b', '');
substring
---
(1 row)
because '.' is a metacharacter in POSIX but not SQL regexps.
regards, tom lane
atabase boundaries ... but they don't today.)
regards, tom lane
PG Doc comments form writes:
> Method `next` of an iterator should be named `__next__` instead.
This was reported and fixed recently [1], but thanks for the report!
regards, tom lane
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=2ff7c913d
u might get most of the way there, but
there will be input that plpgsql will accept that you won't.
regards, tom lane
ns
don't have to document their exact behavior". (If it said
"implementation-defined", that would mean we should.) So not
documenting it is expected. I think we have indeed changed the
details around this in the past.
regards, tom lane
uences view,
so it's not separately documented. There are a fair number of other
view-supporting functions that we don't document either.
regards, tom lane
cture can do all the same testing tricks that the makefiles
can, and for sure it's not documented how.
regards, tom lane
> index with the appropriate query clause and then AND together the index
> results to identify the result rows".
> You mean "WHERE x = 5 OR y = 6"?
No; the query says AND. Unioning the index results would be
appropriate if it said OR, but that's a different topic.
regards, tom lane
ser to what we write elsewhere.
regards, tom lane
pressions, aren’t those expressions over table column?
> e.g., “CREATE INDEX idx_lower_last_name ON users(LOWER(last_name))”,
> “last_name" is a column rather than a row.
Consider
CREATE INDEX idx_lower_name ON users(LOWER(last_name || ' ' || first_name));
regards, tom lane
hich plan nodes
> with initPlans were allowed to be parallel-safe.
I think you're right. Thanks for catching that!
regards, tom lane
te to 5.2 until it becomes a lot more
widespread in standard distros.
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
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
inted at the actual old data directory, not
PGDATA=/var/lib/pgsql/10/data.
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
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
t are you looking at it with?
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
.
The example in the documentation works perfectly well for me.
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
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
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
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
m that it's
identical to CREATE DOMAIN.
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
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
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
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
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
for copying Python.
regards, tom lane
re and pushed it.
Thanks for the submission!
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
t (postal codes for
example) and hence thought that an arbitrary limit was a good thing.
Time to move on.
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
dlers
forms a subtransaction, which means that transactions cannot
be ended inside such a block.
regards, tom lane
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
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
=?UTF-8?Q?Sebastian_Ska=C5=82acki?= writes:
> Looks great to me, thanks!
Pushed, thanks.
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
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
.)
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
have
this setting and always use the
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
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
re neatnik-ism than rescuing the chapter from total
irrelevancy.
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
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
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
"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
the probability of the
Gregorian calendar still being in use 18000 years from now,
but it doesn't seem very profitable. What else do you want
to use?
regards, tom lane
ff.
However, if you're running a moderately old PG version, you need
to make use of the links at the top of the page to go to the
equivalent page in the older version's docs.
regards, tom lane
Arne Sommerfelt writes:
> I am running on AWS RDS - it says engine version 12.17 i thought that was
> the postgres version. If so, the [] subscripting should be supported
> according to docs.
According to what docs? Generic subscripting was added in v14.
reg
1 - 100 of 749 matches
Mail list logo