| Commit message (Collapse) | Author | Age |
|
|
|
| |
From: Josh Kupershmidt <schmiddy@gmail.com>
|
|
|
|
|
|
|
|
|
| |
By using curly braces, the template had specified that one of
"NOT DEFERRABLE", "INITIALLY IMMEDIATE", or "INITIALLY DEFERRED"
was required on any CREATE TRIGGER statement, which is not
accurate. Change to square brackets makes that optional.
Backpatch to 9.1, where the error was introduced.
|
|
|
|
| |
Joshua Tolley
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Granting a role without ADMIN OPTION is supposed to prevent the grantee
from adding or removing members from the granted role. Issuing SET ROLE
before the GRANT bypassed that, because the role itself had an implicit
right to add or remove members. Plug that hole by recognizing that
implicit right only when the session user matches the current role.
Additionally, do not recognize it during a security-restricted operation
or during execution of a SECURITY DEFINER function. The restriction on
SECURITY DEFINER is not security-critical. However, it seems best for a
user testing his own SECURITY DEFINER function to see the same behavior
others will see. Back-patch to 8.4 (all supported versions).
The SQL standards do not conflate roles and users as PostgreSQL does;
only SQL roles have members, and only SQL users initiate sessions. An
application using PostgreSQL users and roles as SQL users and roles will
never attempt to grant membership in the role that is the session user,
so the implicit right to add or remove members will never arise.
The security impact was mostly that a role member could revoke access
from others, contrary to the wishes of his own grantor. Unapproved role
member additions are less notable, because the member can still largely
achieve that by creating a view or a SECURITY DEFINER function.
Reviewed by Andres Freund and Tom Lane. Reported, independently, by
Jonas Sundman and Noah Misch.
Security: CVE-2014-0060
|
|
|
|
|
|
| |
The documentation suggested using "echo | psql", but not the often-superior
alternative of a here-document. Also, be more direct about suggesting
that people avoid -c for multiple commands. Per discussion.
|
|
|
|
|
| |
The previous text was a bit misleading, as well as unnecessarily vague
about what information would be discarded. Per gripe from Craig Skinner.
|
|
|
|
| |
Erikjan Rijkers
|
|
|
|
| |
More languages than PL/pgSQL actually support parameter names.
|
|
|
|
|
|
|
|
|
| |
ALTER TABLE .. VALIDATE CONSTRAINT previously
gave incorrect details about lock levels and
therefore incomplete reasons to use the option.
Initial bug report and fix from Marko Tiikkaja
Reworded by me to include comments by Kevin Grittner
|
|
|
|
|
|
|
|
| |
Per discussion, this restriction isn't needed for any real security reason,
and it seems to confuse people more often than it helps them. It could
also result in some database states being unrestorable. So just drop it.
Back-patch to 9.0, where ALTER DEFAULT PRIVILEGES was introduced.
|
|
|
|
|
|
|
| |
Swap the order of a couple of phrases to clarify what the adjective
"subsequent" applies to.
Joshua Tolley
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation for ALTER TYPE .. RENAME claimed to support a
RESTRICT/CASCADE option at the 'type' level, which wasn't implemented
and doesn't make a whole lot of sense to begin with. What is supported,
and previously undocumented, is
ALTER TYPE .. RENAME ATTRIBUTE .. RESTRICT/CASCADE.
I've updated the documentation and back-patched this to 9.1 where it was
first introduced.
|
|
|
|
|
| |
There's been some confusion expressed about this point, so clarify.
Extended version of a patch by David Wheeler.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My "fix" for bugs #7578 and #6116 on DROP OWNED at fe3b5eb08a1 not only
misstated that it applied to REASSIGN OWNED (which it did not affect),
but it also failed to fix the problems fully, because I didn't test the
case of owned shared objects. Thus I created a new bug, reported by
Thomas Kellerer as #7748, which would cause DROP OWNED to fail with a
not-for-user-consumption error message. The code would attempt to drop
the database, which not only fails to work because the underlying code
does not support that, but is a pretty dangerous and undesirable thing
to be doing as well.
This patch fixes that bug by having DROP OWNED only attempt to process
shared objects when grants on them are found, ignoring ownership.
Backpatch to 8.3, which is as far as the previous bug was backpatched.
|
|
|
|
| |
Noted by Joe Van Dyk
|
| |
|
|
|
|
|
|
| |
We've generally recommended use of INSTEAD triggers over rules since that
feature was added; but this old text in the CREATE VIEW reference page
didn't get the memo. Noted by Thomas Kellerer.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These reference pages still claimed that you have to be superuser to create
a database or schema owned by a different role. That was true before 8.1,
but it was changed in commits aa1110624c08298393dfce996f7b21809d98d3fd and
f91370cd2faf1fd35a1ac74d84652a85ed841919 to allow assignment of ownership
to any role you are a member of. However, at the time we were thinking of
that primarily as a change to the ALTER OWNER rules, so the need to touch
these two CREATE ref pages got missed.
|
|
|
|
|
|
|
|
|
| |
Somewhere along the line, somebody decided to remove all trace of this
notation from the documentation text. It was still in the command syntax
synopses, or at least some of them, but with no indication what it meant.
This will not do, as evidenced by the confusion apparent in bug #7543;
even if the notation is now unnecessary, people will find it in legacy
SQL code and need to know what it does.
|
|
|
|
| |
Backpatch to 9.1 and 9.2.
|
|
|
|
|
|
| |
returned, per report from Aleksey Tsalolikhin
Backpatch to 9.2 and 9.1.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This check was overlooked when we added function execute permissions to the
system years ago. For an ordinary trigger function it's not a big deal,
since trigger functions execute with the permissions of the table owner,
so they couldn't do anything the user issuing the CREATE TRIGGER couldn't
have done anyway. However, if a trigger function is SECURITY DEFINER,
that is not the case. The lack of checking would allow another user to
install it on his own table and then invoke it with, essentially, forged
input data; which the trigger function is unlikely to realize, so it might
do something undesirable, for instance insert false entries in an audit log
table.
Reported by Dinesh Kumar, patch by Robert Haas
Security: CVE-2012-0866
|
|
|
|
|
| |
The sort order is no longer fixed at database creation time, but can be
controlled via COLLATE. Noted by Thomas Kellerer.
|
|
|
|
|
| |
The point that you need parentheses for non-constant expressions apparently
needs to be brought out a bit more clearly, per bug #6315.
|
|
|
|
| |
Kevin Grittner
|
| |
|
|
|
|
|
|
| |
The documentation neglected to explain its behavior in a script file
(it only ends execution of the script, not psql as a whole), and failed
to mention the long form \quit either.
|
| |
|
|
|
|
| |
Noted by Hitoshi Harada.
|
|
|
|
| |
Per comment form Fujii Masao.
|
|
|
|
| |
Almost all other pages have one; this one must have been forgotten.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is what may actually be a mistake in our markup. The problem is
in a situation like
<para>
<command>FOO</command> is ...
there is strictly speaking a line break before "FOO". In the HTML
output, this does not appear to be a problem, but in the man page
output, this shows up, so you get double blank lines at odd places.
So far, we have attempted to work around this with an XSL hack, but
that causes other problems, such as creating run-ins in places like
<acronym>SQL</acronym> <command>COPY</command>
So fix the problem properly by removing the extra whitespace. I only
fixed the problems that affect the man page output, not all the
places.
|
|
|
|
| |
Noted by Josh Kupershmidt.
|
|
|
|
| |
Per discussion with Josh Kupershmidt.
|
|
|
|
|
|
|
|
|
|
|
| |
Also change "switch" to "arg" because "switch" is a bit of a sloppy
term. So the environment variable is called
PSQL_EDITOR_LINENUMBER_ARG. Set "+" as hardcoded default value on
Unix (since "vi" is the hardcoded default editor), so many users won't
have to configure this at all. Move the documentation around a bit to
centralize the editor configuration under environment variables,
rather than repeating bits of it under every backslash command that
invokes an editor.
|
|
|
|
|
| |
KaiGai Kohei, based on feedback from Yeb Havinga, with some
corrections by me.
|
|
|
|
|
| |
We had previously (af26857a2775e7ceb0916155e931008c2116632f)
established the U.S. spellings as standard.
|
|
|
|
| |
Per Josh Kupershmidt and Tom Lane.
|
|
|
|
|
|
|
|
|
|
|
| |
The initial commit of the ALTER TABLE ADD FOREIGN KEY NOT VALID feature
failed to support labeling such constraints as deferrable. The best fix
for this seems to be to fold NOT VALID into ConstraintAttributeSpec.
That's a bit more general than the documented syntax, but it allows
better-targeted syntax error messages.
In addition, do some mostly-but-not-entirely-cosmetic code review for
the whole NOT VALID patch.
|
|
|
|
| |
This has always been true, it was just never documented.
|
|
|
|
| |
Per a gripe from Tom Lane.
|
|
|
|
|
|
|
|
|
| |
The previous wording wasn't explicit enough, which could misled readers
into thinking that the locks acquired are more restricted in nature than
they really are. The resulting optimism can be damaging to morale when
confronted with reality, as has been observed in the field.
Greg Smith
|
|
|
|
| |
Noted by Daniele Varrazzo.
|
|
|
|
| |
Shigeru Hanada, with a minor grammar correction.
|
|
|
|
|
|
|
|
| |
Using -s when registering a service will now suppress
the application eventlog entries stating that the service
is starting and started.
MauMau
|