Re: [HACKERS] Let the commit fest begin!
On Thu, 2008-05-01 at 12:30 -0400, Tom Lane wrote: It's May 1st, which means it's time for our second 8.4 commit fest. I took a quick look through my inbox and added some pending patches to http://wiki.postgresql.org/wiki/CommitFest:May but it's entirely likely there are still some missing from the queue. Would authors of submitted patches please check that (a) your patch is in the queue, and (b) the most recent version is linked to? I've left the page labeled as accepting new contributions for the moment, but we should close it up as soon as any stragglers have been identified. I'm thinking this seems to be working quite well for everybody. Patches seem to be going through quicker now. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.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] [PATCHES] GUC parameter cursors_tuple_fraction
On Friday 02 May 2008 13:35:27 Simon Riggs wrote:
On Fri, 2008-05-02 at 12:01 -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Simon Riggs wrote:
* We've said here http://www.postgresql.org/docs/faqs.TODO.html that
we Don't want hints. If that's what we really think, then this patch
must surely be rejected because its a hint... That isn't my view. I
*now* think we do need hints of various kinds.
cursors_tuple_fraction or OPTIMIZE FOR xxx ROWS isn't the kind of hints
we've said no to in the past.
More to the point, I think what we've generally meant by hints is
nonstandard decoration on individual SQL commands (either explicit
syntax or one of those interpret-some-comments kluges).
Yes, that is definitely an Oracle compatibility thought.
Simon is
reading the policy in such a way that it would forbid all the planner
cost parameters, which is surely not what is intended.
So we're allowed to influence the behaviour of the planner, but just not
by touching the individual statements. OK.
Can we allow a statement like
SET index_weighting = '{{my_index, 0.1},{another_index, 0.5}}'
That would allow us to tell a specific SQL statement that it should use
a cost weighting of 0.1 * normal cost for the my_index index (etc).
SET enable_seqscan = off; is a blunt instrument that can sometimes
achieve the same thing, but insufficiently exact to be really useful.
Many people use that (Sun, in their first published PostgreSQL
benchmark...)
We/I want to make the planner even better, but the above is roughly what
people want while they're waiting for us to get the planner right.
I think the above would be helpful, but even then I am not sure it goes far
enough, since there might be cases where you need and index wieghted high for
a specific join within the query, but low for a different join in that query.
A further problem with this implementation would be that in general it would
require that you issue a set, run your query, and then issue another set to
put those weightings back to the defaults, which seems like an excessive
amount of overhead. As much as people like to turn their nose to in-line
query hints, the manifestation of deficiencies in the planner always
manifiest themselves at the query level, so it makes it difficult to create a
solid solution that operates somewhere else.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] Text - C string
Brendan Jurd [EMAIL PROTECTED] writes: Well ... if somebody does want to change the representation of xml down the road, he's going to have to touch all the sites where the code converts to and from cstring anyway, right? True. With that in mind, please find attached my followup patch. It cleans up another 21 sites manually copying between cstring and varlena, for a net reduction of 115 lines of code. I applied most of this, but not the parts that were dependent on the assumption that bytea and text are the same. That is unlikely to remain true if we ever get around to putting locale/encoding information into text values. Furthermore it's a horrid type pun, because bytea can contain embedded nulls whereas cstrings can't; you were making unwarranted assumptions about whether, say, cstring_to_text_with_len would allow embedded nulls to go by. And lastly, quite a few of those changes were just plain broken, eg several places in selfuncs.c where you allowed strlen() to be applied to a bytea converted to cstring. 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] Proposed Patch - LDAPS support for servers on port 636 w/o TLS
stephen layland [EMAIL PROTECTED] writes: I've written a quick patch against the head branch (8.4DEV, but it also works with 8.1.3 sources) to fix LDAP authentication support to work with LDAPS servers that do not need start TLS. I'd be interested to hear your opinions on this. Not being an LDAP user, I'm not very qualified to comment on the details here, but ... My solution was to create a boolean config variable called ldap_use_start_tls which the user can toggle whether or not start tls is necessary. ... I really don't like using a GUC variable to determine the interpretation of entries in pg_hba.conf. A configuration file exists to set configuration, it shouldn't need help from a distance. Also, doing it this way means that if several different LDAP servers are referenced in different pg_hba.conf entries, they'd all have to have the same encryption behavior. I think a better idea is to embed the flag in the pg_hba.conf entry itself. Perhaps something like ldapso: instead of ldaps: to indicate old secure ldap protocol, or include another parameter in the URL body. 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] Protection from SQL injection
* Thomas Mueller: What do you think about it? Do you think it makes sense to implement this security feature in PostgreSQL as well? Can't this be implemented in the client library, or a wrapper around it? A simple approximation would be to raise an error when you encounter a query string that isn't contained in some special configuration file. -- 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 for Prevent pg_dump/pg_restore from being affected by statement_timeout
Euler Taveira de Oliveira wrote: Andrew Dunstan wrote: Committed with slight editorializing. Statement timeout was only introduced in 7.3, whereas pg_dump can dump from much older versions of Postgres. You forget a ; in this committ [1]. [1] http://archives.postgresql.org/pgsql-committers/2008-05/msg00028.php I need to stop doing things late at night. fixed. cheers andrew. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Query Hints? No thanks. Data hints?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi -hackers, In another thread about GUC parameter cursors_tuple_fraction, the debate seems to drift onto query hints. About which the consensus here is pretty clear and strong, no query hints in PostgreSQL, thanks, or we're never gonna have a perfect generic planner. IIRC, I've read here in the past some attempts to begin a proposal on the topic of data hints, allowing the user to describe his data in a way ANALYZE can't figure out by itself, as e.g. this column value is tied to this other column value in this way. This could be a materialized column, mutual-exclusive NOT NULLs, or any multi-columns relationships, as well as this table is a fact table, etc. What do you -hackers think about such a plan: - assess cases where the planner is failing short of good statistics - assess data properties SQL does not give us but would be of interrest to internals, and at the same time not so difficult to know about by DBAs - based on this, prepare a descriptive language of some sort tying this all in - implement it in a good way ;) I'm thinking we could have a new set of commands to tell PostgreSQL some high-level facts about the data, e.g. there's a injective function such as f(t.colA) = t.colB or any useful thing to be found in the firsts proposed step. Is there a chance we're gonna improve the planner this way? And answer Simon's (and many others here and there, -performance etc) concerns? HTH, regards, - -- dim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkgeEjoACgkQlBXRlnbh1bnlHwCfcHL5uOlCpptekwLBMp+E9kUn 4roAoMfwdITByHtxCi35l9jDCTSFw2Ho =whVn -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
