Re: [HACKERS] Rejecting weak passwords
I wrote: > Following the discussions in > http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php > and > http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php , > here are patches for > > a) a hook in backend/commands/user.c that allows one to add >password checking functions > b) a contrib module that makes use of the hook and > c) documentation for the contrib module. I found a small but embarrassing bug - here is another version. Yours, Laurenz Albe pwdcheck-hook.patch Description: pwdcheck-hook.patch pwdcheck-contrib.patch Description: pwdcheck-contrib.patch pwdcheck-contrib-doc.patch Description: pwdcheck-contrib-doc.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Reworks for Access Control facilities (r2350)
KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: > Please review the new revision, Thanks, In general, I'm pretty happy with this revision. You still have a number of places where you have comments about code which does not exist any more. For example, the comments about the check being removed from LookupCreationNamespace. I would recommend pulling out those comments and instead having a comment at the top of the function that says "namespace creation permission checks are handled in the individual object ac_*_create() routines". I don't like having comments that are about code which was removed. Some of these could be moved to the README if they aren't there already and they really need to be kept. There are some other grammatical and spelling issues in the comments, but I don't believe any of this should hold this patch up from being ready for committer. At a minimum, I think this really needs to have a committer comment on it to ensure we're going in the right direction. I'd be happy to continue working with KaiGai to review his changes going forward, either with the next set of SE-PG patches or reworking this one if necessary. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] man pages
On Sun, Oct 11, 2009 at 09:18:20PM -0400, Tom Lane wrote: > Alvaro Herrera writes: > > As for builtin functions, I think that's going to be a very hard > > sell. > > Fresh out of the box, there are 2227 entries in pg_proc as of CVS > HEAD. I don't see making a man page for each one as being a useful > activity ... How about a man page with all of them (or main sections of them) and a bunch of symbolic links, as with *printf? Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] man pages
Alvaro Herrera writes: > As for builtin functions, I think that's going to be a very hard sell. Fresh out of the box, there are 2227 entries in pg_proc as of CVS HEAD. I don't see making a man page for each one as being a useful activity ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] man pages
David Fetter wrote: > Folks, > > I'd like to see about creating man pages for the following: > > - libpq > - SPI > - the built-in functions > > These being what I've clicked through way too many web links to find > information about. If there are other things that should have man > pages, please mention same. We already have SPI manpages in HEAD. libpq would be very useful, I agree; you should try to patch the SGML following the SPI example in order to get those. It shouldn't be difficult. As for builtin functions, I think that's going to be a very hard sell. I'd focus on libpq at first :-) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unicode UTF-8 table formatting for psql text output
On Fri, Oct 09, 2009 at 04:35:46PM -0500, Kevin Grittner wrote:
> Peter Eisentraut wrote:
>
> > I think the setting ought be called linestyle unicode (instead of
> > utf8), since the same setting would presumably work in case we ever
> > implement UTF-16 support on the client side.
>
> Yeah, anytime one gets sloppy with the distinction between a character
> set and a character encoding scheme, one tends to regret it, sooner or
> later. Here's we're talking about which glyphs to show -- that's
> based on a character set.
The attached updated patch renames all user-visible uses of
"utf8" to "unicode". It also updates the documentation
regarding "locale" to "psql client character set encoding"
so the docs now match the code exactly.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 85e9375..c3b2c28 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1690,6 +1690,53 @@ lo_import 152801
+ linestyle
+
+
+ Sets the line drawing style of text table output to one
+ of ascii or unicode.
+ Unique abbreviations are allowed. (That would mean one
+ letter is enough.) unicode will be
+ selected if used by the psql client character set encoding,
+ otherwise ascii will be used by default.
+
+
+
+ Query result tables are displayed as text for some output
+ formats (unaligned,
+ aligned, and wrapped
+ formats). The tables are drawn using characters of the psql
+ client character set encoding. By default,
+ the ASCII character set will be used,
+ which will display correctly for all encodings. However, if
+ the user is using an encoding based upon the Universal
+ Character Set (Unicode), for
+ example UTF8, the Unicode box drawing
+ characters will be used in place of ASCII punctuation in
+ order to display more readable tables.
+
+
+
+ This option is useful for overriding the default line style,
+ for example to force the use of
+ only ASCII characters when extended
+ character sets such as Unicode are inappropriate. This
+ might be the case if preserving output compatibility with
+ older psql versions is important (prior to 8.5.0).
+
+
+
+ Unicode use Unicode box drawing characters.
+
+
+
+ ASCII use plain ASCII characters.
+
+
+
+
+
+
columns
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index da57eb4..6f34e68 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -46,6 +46,7 @@
#include "input.h"
#include "large_obj.h"
#include "mainloop.h"
+#include "mbprint.h"
#include "print.h"
#include "psqlscan.h"
#include "settings.h"
@@ -596,6 +597,14 @@ exec_command(const char *cmd,
/* save encoding info into psql internal data */
pset.encoding = PQclientEncoding(pset.db);
pset.popt.topt.encoding = pset.encoding;
+if (!pset.popt.topt.line_style_set)
+{
+ if (pset.encoding == get_utf8_id())
+ pset.popt.topt.line_style = &utf8format;
+ else
+ pset.popt.topt.line_style = &asciiformat;
+}
+
SetVariable(pset.vars, "ENCODING",
pg_encoding_to_char(pset.encoding));
}
@@ -1432,6 +1441,13 @@ SyncVariables(void)
/* get stuff from connection */
pset.encoding = PQclientEncoding(pset.db);
pset.popt.topt.encoding = pset.encoding;
+ if (!pset.popt.topt.line_style_set)
+ {
+ if (pset.encoding == get_utf8_id())
+ pset.popt.topt.line_style = &utf8format;
+ else
+ pset.popt.topt.line_style = &asciiformat;
+ }
pset.sversion = PQserverVersion(pset.db);
SetVariable(pset.vars, "DBNAME", PQdb(pset.db));
@@ -1772,6 +1788,27 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet)
printf(_("Output format is %s.\n"), _align2string(popt->topt.format));
}
+ /* set table line style */
+ else if (strcmp(param, "linestyle") == 0)
+ {
+ if (!value)
+ ;
+ else if (pg_strncasecmp("ascii", value, vallen) == 0)
+ popt->topt.line_style = &asciiformat;
+ else if (pg_strncasecmp("unicode", value, vallen) == 0)
+ popt->topt.line_style = &utf8format;
+ else
+ {
+ psql_error("\\pset: allowed line styles are ascii, unicode\n");
+ return false;
+ }
+
+ popt->topt.line_style_set = true;
+
+ if (!quiet)
+ printf(_("Line style is %s.\n"), popt->topt.line_style->name);
+ }
+
/* set border style/width */
else if (strcmp(param, "border") == 0)
{
diff --git a/src/bin/psql/mbprint.c b/src/bin/psql/mbprint.c
index
Re: [HACKERS] Is FOR UPDATE an optimization fence?
Robert Haas writes:
> On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane wrote:
>> It's an entirely trivial code change either way. I'm inclined to think
>> that we should prevent flattening, on the grounds of least astonishment.
> It seems like this is somewhat related to the question of embedding an
> {INSERT|UPDATE|DELETE}...RETURNING in some arbitrary part of a query
> versus only allowing it in a WITH clause. The argument for only
> allowing it in a WITH clause is that there is otherwise no guarantee
> that it is evaluated in its entirety but just once. ISTM we could
> contrariwise give it the handling you're proposing here: allow it
> anywhere in the query, but make it act as an optimization fence.
I don't think this analogy to update queries is a very solid one.
SELECT FOR UPDATE has a couple of properties that make it much less
critical for it to have evaluate-exactly-once semantics:
* Locking the same row twice is a no-op.
* If you don't run the query to completion and thus don't lock all
the rows, so what? Arguably, the semantics of the query are to
lock only the rows actually read/returned.
> For that reason, I think I'd be inclined to make it act as an
> optimization fence if used as a top-level CTE, but otherwise flatten
> it, so that the handling is consistent with what we've proposed to do
> elsewhere.
Well, the point of the WITH RETURNING restriction is that just because a
subselect isn't flattened doesn't mean you have evaluate-exactly-once
semantics for the subselect. The upper query is still free to execute
the subselect multiple times, partially, or not at all. A CTE, on the
other hand, is more than just an optimization fence --- we've decided to
give it evaluate-exactly-once semantics. So SELECT FOR UPDATE at the
top of a CTE is really irrelevant to this discussion; it's going to be
treated the same no matter what.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] man pages
David Fetter wrote: Folks, I'd like to see about creating man pages for the following: - libpq - SPI - the built-in functions That would be really helpful and convenient. I've often wanted libpq man pages. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is FOR UPDATE an optimization fence?
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane wrote:
> I'm fooling around with pushing FOR UPDATE locking into a new plan node
> type, and I just noticed a behavior that seems a bit bogus.
> Historically we have dealt with FOR UPDATE in sub-selects by flattening
> the sub-select if we could, because the alternative was to fail
> altogether. For example, consider
>
> select * from a join (select * from b for update) ss on a.x = ss.y;
>
> The FOR UPDATE effectively got hoisted to the top because that's where
> we could implement it, making this equivalent to
>
> select * from a join b on a.x = b.y for update of b;
>
> It seems to me, though, that this is changing the semantics. In the
> latter case it's clear that we should only lock b rows that have a join
> partner in a (which indeed is what happens). In the former case, what
> I think should be expected to happen is that *all* b rows get locked.
>
> With FOR UPDATE as a plan node, it's possible to fix this by treating
> FOR UPDATE in a sub-select as an optimization fence that prevents
> flattening of the sub-select, much like LIMIT has always done. The
> FOR UPDATE node will end up at the top of the subplan and it will act
> as the syntax would suggest.
>
> Of course the downside of changing it is that queries that worked fine
> before might work differently (and much slower) now; first because not
> flattening the sub-select might lead to a worse plan, and second because
> locking more rows takes more time.
>
> The alternative would be to let it continue to flatten such sub-selects
> when possible, and to tell anyone who doesn't want that to stick in
> OFFSET 0 as an optimization fence.
>
> It's an entirely trivial code change either way. I'm inclined to think
> that we should prevent flattening, on the grounds of least astonishment.
It seems like this is somewhat related to the question of embedding an
{INSERT|UPDATE|DELETE}...RETURNING in some arbitrary part of a query
versus only allowing it in a WITH clause. The argument for only
allowing it in a WITH clause is that there is otherwise no guarantee
that it is evaluated in its entirety but just once. ISTM we could
contrariwise give it the handling you're proposing here: allow it
anywhere in the query, but make it act as an optimization fence.
For that reason, I think I'd be inclined to make it act as an
optimization fence if used as a top-level CTE, but otherwise flatten
it, so that the handling is consistent with what we've proposed to do
elsewhere. But I'm not really familiar with how these constructs are
being treated by the executor, so I might be creating a false parallel
here.
The other comment I have is that I *expect* subqueries to be pulled
up. So my own personal POLA would not be violated by locking only the
rows with a join partner; in fact it would be more likely to be
violated by the reverse behavior. I might not be typical, though. My
experience is that not pulling up subqueries tends to have disastrous
effects on performance, so I'm somewhat biased against creating more
situations where that will happen.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] man pages
Folks, I'd like to see about creating man pages for the following: - libpq - SPI - the built-in functions These being what I've clicked through way too many web links to find information about. If there are other things that should have man pages, please mention same. How would that be handled in our current doc build system? I'd really appreciate any hints, tips or pointers on man page creation in our current system :) Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is FOR UPDATE an optimization fence?
Markus Wanner writes: > BTW: how do other databases deal with this? Anything of relevance in the > SQL standards? SQL99 treats FOR UPDATE as an attribute of DECLARE CURSOR, so there's no way for it to appear in a sub-select per spec. (In general our approach to FOR UPDATE is only loosely related to what the spec thinks it does ...) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is FOR UPDATE an optimization fence?
Hi, Tom Lane wrote: > It's an entirely trivial code change either way. I'm inclined to think > that we should prevent flattening, on the grounds of least astonishment. Yeah, I also tend towards making FOR UPDATE an optimization fence (that's how I understood the non-flattening approach). While it might change behavior compared to previous versions, it doesn't force people into writing kludges like OFFSET 0. BTW: how do other databases deal with this? Anything of relevance in the SQL standards? Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Is FOR UPDATE an optimization fence?
I'm fooling around with pushing FOR UPDATE locking into a new plan node type, and I just noticed a behavior that seems a bit bogus. Historically we have dealt with FOR UPDATE in sub-selects by flattening the sub-select if we could, because the alternative was to fail altogether. For example, consider select * from a join (select * from b for update) ss on a.x = ss.y; The FOR UPDATE effectively got hoisted to the top because that's where we could implement it, making this equivalent to select * from a join b on a.x = b.y for update of b; It seems to me, though, that this is changing the semantics. In the latter case it's clear that we should only lock b rows that have a join partner in a (which indeed is what happens). In the former case, what I think should be expected to happen is that *all* b rows get locked. With FOR UPDATE as a plan node, it's possible to fix this by treating FOR UPDATE in a sub-select as an optimization fence that prevents flattening of the sub-select, much like LIMIT has always done. The FOR UPDATE node will end up at the top of the subplan and it will act as the syntax would suggest. Of course the downside of changing it is that queries that worked fine before might work differently (and much slower) now; first because not flattening the sub-select might lead to a worse plan, and second because locking more rows takes more time. The alternative would be to let it continue to flatten such sub-selects when possible, and to tell anyone who doesn't want that to stick in OFFSET 0 as an optimization fence. It's an entirely trivial code change either way. I'm inclined to think that we should prevent flattening, on the grounds of least astonishment. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
