Daniel Gustafsson writes:
>> On 7 Oct 2023, at 22:22, Tom Lane wrote:
>> Yeah, either way has the same result. However, I wonder if we should
>> change this example to use current_user for clarity. It does look
>> more like it's intended to be a variable or column
isn't a good fix.
regards, tom lane
wrong with the existing docs.
The limitation to 1-microsecond precision is spelled out in the
table just above the para you quote.
regards, tom lane
LTER SYSTEM command.
foo.bar = 'baz'
So that feels like a bug: we should not allow ALTER SYSTEM to execute
against a placeholder GUC definition, because the placeholder can't
tell us whether the value is valid. I wonder though if forbidding
this would break any legitimate usage patterns.
regards, tom lane
Laurenz Albe writes:
> On Mon, 2023-10-16 at 12:29 -0400, Tom Lane wrote:
>> So that feels like a bug: we should not allow ALTER SYSTEM to execute
>> against a placeholder GUC definition, because the placeholder can't
>> tell us whether the value is valid. I wonder th
so, that para already mentions that the input can be a
comma-separated list when appropriate, so your add-on para seems
partially repetitive. I think you could just drop the first
sentence of it.
regards, tom lane
was an intention to have some such feature but it never got done?
Anyway, I don't see anything indicating that there's actually
such a concept as "the default connection". I suggest we just
remove those paragraphs.
What *is* treated specially is CURRENT --- but EXEC SQL SET
CONNECTION = CURRENT is effectively a no-op, so it's not very
exciting.
regards, tom lane
ange time_key to be a timestamp or timestamptz value?
regards, tom lane
er, CREATE DATABASE does not copy
+ database-level GRANT permissions attached to the
+ source database. The new database has default permissions.
+
+
There is a second standard system database named
regards, tom lane
like there is anything unclear about the CREATE TABLE error message.
regards, tom lane
Bruce Momjian writes:
> On Wed, Nov 1, 2023 at 06:32:37PM -0400, Tom Lane wrote:
>> But it *is* permissible, unless we add code to reject it during
>> SET as Bruce mentioned. Which seems fairly pointless to me. It's not
>> like there is anything unclear about the
Bruce Momjian writes:
> I found a cleaner improvement, attached.
OK by me. Maybe that doesn't make the point strongly enough,
but we can hope it's enough.
regards, tom lane
"Daniel Westermann (DWE)" writes:
> Creating a table with 1600 bigint columns does work with a 8k blocksize:
Yeah, but populating it would not (unless many of the columns were
NULL).
regards, tom lane
mpact of NULLs, and the fact that usually tables have some
variable-width columns, I doubt that a creation-time warning could be
accurate enough to be useful.
regards, tom lane
put notes about PL/pgSQL features into command
reference pages that have nothing to do with PL/pgSQL.
regards, tom lane
the
first section that mentions partial indexes at all. Somebody
reading the chapter in order would have no idea what we were
talking about.
regards, tom lane
dom users can't see
umoptions.
regards, tom lane
y case,
we accept 'T', 't', '_', and most other punctuation there, so
we should be able to read nearly any plausible variant.
regards, tom lane
nce to a
> particular standard, except for ISO 9075 to show that Postgres is
> SQL-standard-compliant?
I think that would remove useful context without actually improving
anything. (The datetime input code would be far simpler if it
meant only to read the exact format mentioned in the SQL spec.)
regards, tom lane
ctions that are writing the NOTIFY
queue. If it were a lesser but still exclusive lock type,
it wouldn't make any difference.
explicit-locking.html is really only about locks on tables.
Maybe that should be clarified somewhere?
regards, tom lane
could handle those another way than reserving
a table column for them? We could give them their own table rows,
or relegate them to footnotes.
The "serial" types need a bit more reflection too, since they
aren't truly types at all: there is no matching pg_type entry.
I'm not sure they belong here.
regards, tom lane
ct '2 month'::interval;
interval
--
2 mons
(1 row)
regards, tom lane
rily just
read 4.1.1.
Perhaps it'd be better to use different example strings though?
regards, tom lane
"David G. Johnston" writes:
> We probably should write the syntax like we do everywhere else:
> [grantee]={privilege[*]}[…]/grantor
> Then define the placeholders in the subsequent paragraph.
Seems reasonable. About like this?
regards, tom lane
d
gt; CI)
Can't help you on that when you provide no details. PG certainly
does work for many other people on Debian+arm64.
regards, tom lane
database. See
https://www.postgresql.org/docs/current/contrib.html
regards, tom lane
ill fix, thanks!
regards, tom lane
user
running initdb". I don't like "installation user", that's just about
as vague as could be.
regards, tom lane
lain it here. But nobody's done so in
twenty years so I'm not holding my breath.)
regards, tom lane
Bruce Momjian writes:
> Agreed, updated patch attached.
WFM.
regards, tom lane
et, as you'd find out if you tried it. I think there's a patch
in the pipeline to allow it.
regards, tom lane
the new owner.
For myself, I thought Laurenz's proposed patch is an improvement.
regards, tom lane
fraid of the compatibility implications if we change it now.
regards, tom lane
rows)
regression=# explain verbose SELECT txt = ch AS txt_ch FROM test;
QUERY PLAN
---
Seq Scan on pg_temp.test (cost=0.00..19.45 rows=630 width=1)
Output: (txt = (ch)::text)
(2 rows)
regards, tom lane
likely
that we'll get better at it.
I'm a little dubious about the "Technical References" list right below
it, too. The RFC references are probably useful and stable, and maybe
the wikipedia ref is OK, but I have little faith in either the
stability or the long-term relevance of the other two links.
regards, tom lane
Daniel Gustafsson writes:
> On 13 Feb 2024, at 20:42, Tom Lane wrote:
>> I'm a little dubious about the "Technical References" list right below
>> it, too. The RFC references are probably useful and stable, and maybe
>> the wikipedia ref is OK, but I have lit
y!
Indeed. Will fix, thanks for report!
regards, tom lane
...".
Yup, I think you're right. Thanks for the report!
regards, tom lane
27;s worth giving an example that neither explains the
"disregarded" bit nor highlights the dependency on L being given.
regards, tom lane
server status; however, if
incorrect values are provided, the server will log a failed
connection attempt.
If you don't want log spam about failed connections, you'd need
a user with privilege to connect to the mentioned database.
Otherwise, not.
regards, tom lane
PG Doc comments form writes:
> It seems the ending clarifying sentence:
> "(Null when most_common_vals is.)"
> should rather be:
> "(Null when most_common_vals is null.)"
I think it's perfectly good English as-is, if a bit terse.
regards, tom lane
ot; instead of "RETURNS real"?
> The docs are correct.
Specifically, that bit is a declaration of the data type of the
function's result, not a specification of how to compute it.
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
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
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
"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
201 - 300 of 691 matches
Mail list logo
