Re: [HACKERS] branching for 9.2devel
On Wed, May 4, 2011 at 1:21 PM, Josh Berkus j...@agliodbs.com wrote: You can't indent patches, only patched files. And that's the problem with this happy scheme. For it to work at all sanely we'd need to keep the committed code that the patch is to be applied against strictly pgindent clean, presumably via some automated process such as a commit hook. That's been suggested in the past, but hasn't met with universal approval, IIRC. Well, there is another solution to this, which is to use Git branches and forks instead of mailing around patches. Shouldn't it be as simple as keeping a git clone of trunk up to date, applying the patch, running pgindent and emitting the resulting diff? Once it's been generated, just run git reset --hard to clean out all local changes. -- Thanks, David Blewett -- 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] branching for 9.2devel
On Mon, May 2, 2011 at 2:01 AM, Pavan Deolasee pavan.deola...@gmail.com wrote: Can we not setup a automatic mechanism where a submitter can send a patch to some email id, the patch gets applied on the current HEAD, pgindent is run and the new patch is sent back to the submitter who can then submit it to the hackers for review. If the patch does not apply cleanly, the same can also be emailed back to the submitter. This seems like a pretty good idea, but maybe it'd be easiest to take it a step further and add an automatic pgindent-ified patch is created when a patch is added to the commitfest app? If the original patch didn't apply cleanly, just don't make the pgindet-ified link a link and instead mark it red/strikethrough or some such? It would probably be good to have both pieces, so that patch authors could verify things outside of the app. -- Thanks, David Blewett -- 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] branching for 9.2devel
On Tue, May 3, 2011 at 9:51 PM, David Blewett da...@dawninglight.net wrote: This seems like a pretty good idea, but maybe it'd be easiest to take it a step further and add an automatic pgindent-ified patch is created when a patch is added to the commitfest app? That should read: ... but maybe it'd be easiest to take it a step further and have an additional, automatically created patch file that is run through pgindent when a patch is added to the commitfest app. -- Thanks, David Blewett -- 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] branching for 9.2devel
On Mon, Apr 25, 2011 at 1:04 PM, Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Aidan Van Dyk ai...@highrise.ca wrote: Of course, that all depends on: 1) pgindent being work everywhere, exactly the same 2) Discipline of all new published commits being pgindent clean. The problem is that getting it set up isn't yet trivial. This is all assuming that we fix that. Yeah, there is not much point in thinking about #2 until we have #1. Would this be a good GSoC project (or has the deadline passed)? -- Thanks, David Blewett -- 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] tsearch Parser Hacking
On Mon, Feb 14, 2011 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us wrote: David E. Wheeler da...@kineticode.com writes: Is it possible to modify the default tsearch parser so that / doesn't get lexed as a file token? There is zero, none, nada, provision for modifying the behavior of the default parser, other than by changing its compiled-in state transition tables. It doesn't help any that said tables are baroquely designed and utterly undocumented. IMO, sooner or later we need to trash that code and replace it with something a bit more modification-friendly. I added this to the TODO as something that can be tackled in the future. I've been wishing it would be possible to add other tokens as well (Python dotted path 'foo.bar.baz', Perl namespace path 'Foo::Bar', more flexible version number parsing, etc). David Blewett -- 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] compile/install of git
Sorry for top-posting... I was under the impression that git over http was just as efficient since 1.6.6 [1]. David Blewett 1. http://github.com/blog/642-smart-http-support On Sep 18, 2010 12:26 PM, Andrew Dunstan and...@dunslane.net wrote: On 09/18/2010 11:37 AM, Tom Lane wrote: Andrew Dunstan wrote: Test machines belong in ... Right. I was just reacting to Bruce's observation about what people said about his moving off BSD/OS. Bruce Momjianbr...@momjian.us writes: My big point in posting was to say that compiling... Yeah. Git over HTTP is horribly inefficient anyway - it's really a last resort. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your sub...
Re: [HACKERS] Streaming a base backup from master
On Fri, Sep 3, 2010 at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote: IOW, what I'd like to see is protocol extensions that allow an external copy of rsync to be invoked; not build in rsync, or tar, or anything else that we could get off-the-shelf. Personally, I would love to see protocol-level compression added. (Yes, going over a compressed SSH tunnel works well, but in general isn't user-friendly.) Josh: we talked on IRC awhile back and you mentioned that CMD had added this in Mammoth? Would you be interested in having someone get that integrated back into the community? David Blewett -- 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] Streaming a base backup from master
On Fri, Sep 3, 2010 at 12:23 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 03/09/10 18:53, David Blewett wrote: On Fri, Sep 3, 2010 at 11:47 AM, Tom Lanet...@sss.pgh.pa.us wrote: IOW, what I'd like to see is protocol extensions that allow an external copy of rsync to be invoked; not build in rsync, or tar, or anything else that we could get off-the-shelf. Personally, I would love to see protocol-level compression added. (Yes, going over a compressed SSH tunnel works well, but in general isn't user-friendly.) Josh: we talked on IRC awhile back and you mentioned that CMD had added this in Mammoth? Would you be interested in having someone get that integrated back into the community? There's a recent thread on pgsql-general about just that: http://archives.postgresql.org/pgsql-general/2010-08/msg3.php I agree with Tom's comments there, I'd like to have something to enable/disable SSL compression rather than implement our own. There was some discussion that it might not be available on JDBC SSL implementations, but if it's done in our protocol, you'll need changes to the client to make it work anyway. While I agree that combining SSL with compression is a great win, I'm not sold on Tom's argument that compression is only needed in WAN situations. I've seen great benefit to using an SSH tunnel with compression over LAN connections (100 and 1000 mbps). At work, we do have a private WAN that it would be nice to be able to use compression with no encryption on. I think it's a general-use thing. While I know it's not the best argument, MySQL does provide compression at the connection level. David Blewett -- 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] plpython3
On Sun, Jan 17, 2010 at 4:07 PM, James William Pye li...@jwp.name wrote: The effect of this is that every time the FUNCTION is called from PG, the import statements are ran, a new class object, UrlOpener, is created, and a new function object, translate, is created. Granted, a minor amount of overhead in this case, but the point is that in order to avoid it the author would have to use SD: if urlopener in SD: UrlOpener = SD[urlopener] else: class UrlOpener(urllib.UrlOpener): ... SD[urlopener] = UrlOpener While some may consider this a minor inconvenience, the problem is that *setup code is common*, so it's, at least, a rather frequent, minor inconvenience. With function modules, users have a module body to run any necessary setup code. Coming from a Python developer perspective, this is indeed an improvement. I always thought the whole SD/GD thing was a little odd. Doing the setup at the module level and relying on the interpreter to keep it cached is much more Pythonic and is a common idiom. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Add encoding support to COPY
Today on IRC, someone was wondering what the preferred method of exporting data in a specific encoding via COPY was. They reply was wrapping the COPY command in set client_encoding='foo';, which made me wonder how hard it would be to add an additional WITH parameter to the actual COPY statement to specify the encoding, a la: [ [ WITH ] [ BINARY ] [ OIDS ] [ DELIMITER [ AS ] 'delimiter' ] [ ENCODING [ AS ] 'charset' ] [ NULL [ AS ] 'null string' ] [ CSV [ HEADER ] [ QUOTE [ AS ] 'quote' ] [ ESCAPE [ AS ] 'escape' ] [ FORCE QUOTE column [, ...] ] Any objections? It seems like a cleaner solution client side than issuing multiple calls to set the client_encoding. If there are no objections, I can attempt to prepare a patch for the next commitfest. David Blewett -- 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] Add encoding support to COPY
On Wed, Jul 15, 2009 at 12:04 PM, Tom Lanet...@sss.pgh.pa.us wrote: What is the point? You'd generally have client_encoding set correctly for your usage anyway, and if you did not, the data could confuse your client-side code terribly. Offering an option to let the backend send data in the wrong encoding does NOT seem like a good idea to me. The use case was that the client connection was using one encoding, but needed to output the file in a different encoding. So they would have to do the set client_encoding dance each time they wanted to export the file. I don't see how it's wrong, especially considering there is already a method to do this, albeit cumbersome. I consider it simply syntactic sugar over existing functionality. David Blewett -- 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] Add encoding support to COPY
Apologies to Tom for the duplicate... On Wed, Jul 15, 2009 at 12:17 PM, Tom Lanet...@sss.pgh.pa.us wrote: Well, it might make sense to allow an ENCODING option attached to a COPY with a file source/destination. I remain of the opinion that overriding client_encoding on a transfer to/from the client is a bad idea. I really don't see how it is any different from manually flipping the client_encoding before/after the transfer. We could of course put a warning sign in the docs, but it seems to me it's more error prone for clients to set the client_encoding manually rather than include an option for a single command. What happens if an exception is thrown during the COPY process and the client doesn't handle things correctly? The rest of their session could be in an unexpected encoding, whereas with this method we know to return to the original client_encoding before doing anything else. By including the encoding option, their explicitly saying how they want to handle the data. I could see a use case for remote client code to do a COPY to STDOUT, that is actually being redirected to a file. If the consensus is for local file-based operations only, however, I can structure the patch that way. David -- 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] Add encoding support to COPY
On Wed, Jul 15, 2009 at 4:07 PM, Tom Lanet...@sss.pgh.pa.us wrote: David Blewett da...@dawninglight.net writes: On Wed, Jul 15, 2009 at 12:17 PM, Tom Lanet...@sss.pgh.pa.us wrote: Well, it might make sense to allow an ENCODING option attached to a COPY with a file source/destination. I remain of the opinion that overriding client_encoding on a transfer to/from the client is a bad idea. I really don't see how it is any different from manually flipping the client_encoding before/after the transfer. The difference is that the client-side code gets told that the encoding changed if you do the latter. Do you mean at the protocol level? All I was planning on having the patch do is the equivalent of the set client_encoding dance. Wouldn't that be sufficent to notify the client of the encoding change? David Blewett -- 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] pg_migrator issue with contrib
On Fri, Jun 5, 2009 at 6:11 PM, Dimitri Fontaine dfonta...@hi-media.com wrote: Some example modules that I can think of and are wildspread in the field, as far as I know, are ip4r (data type and indexes), orafce (functions, views, tables), and some less spread are prefix (data type and indexes) or temporal (period data type, indexes). And hstore... David Blewett -- 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] Python 3.0 does not work with PL/Python
On Thu, May 28, 2009 at 9:06 PM, Andrew Dunstan and...@dunslane.net wrote: Does Python 3 have some sort of usable sandbox that would mean we could have a trusted plpython? I brought this up last August [1]. Zope has a working sandbox that they include in their distribution. David Blewett 1. http://archives.postgresql.org/message-id/9d1f8d830808041008v50104fd8p6181d5ddce85...@mail.gmail.com
[HACKERS] Re: [PATCH] Automatic client certificate selection support for libpq v1
On Fri, May 8, 2009 at 12:10 PM, Tom Lane t...@sss.pgh.pa.us wrote: Seth Robertson in-pgsql-hack...@baka.org writes: I had a situation where I needed to connect to multiple postgresql servers in a variety of programs written in a variety of languages, including some which connected to multiple servers at the same time. As some of you might know, you cannot usefully put multiple certificates or keys in the postgresql.crt/.key files. Hmm, shouldn't we fix *that* rather than inventing a hack like this? Possibly a la SSH's authorized_keys or known_hosts formats? David -- 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] Python 3.0 does not work with PL/Python
On Thu, Apr 30, 2009 at 8:30 AM, James Pye li...@jwp.name wrote: On Apr 30, 2009, at 5:09 AM, David Blewett wrote: I'd love to see this. yep, once I get 0.9 of the driver out the door, I'll probably focus on this. It's the perfect time for a rewrite.. I really don't want to see the 2.x version ported. =\ I can't help with the C stuff, but I can try to help test things as you go. I will probably be taking you up on that offer. =) I'll be dev'ing on osx with some occasional compiles/tests on fbsd, so an extra pair of eyes on builds/test runs would be a *huge* help.. I have access to the current version of ubuntu, centos 5, gentoo and opensolaris. Just let me know what you'd like tested. David Blewett -- 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] Python 3.0 does not work with PL/Python
On Sun, Apr 5, 2009 at 7:10 PM, James Pye li...@jwp.name wrote: Any thoughts on the acceptability of a complete rewrite for Python 3? I've been fiddling with a HEAD branch including the plpy code in a github repo. (nah it dunt compile yet: bitrot and been busy with a 3.x driver. ;) I'd love to see this. I can't help with the C stuff, but I can try to help test things as you go. David Blewett -- 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] ARRAY vars (was Enable pl/python to return records based on multiple OUT params)
On Tue, Nov 4, 2008 at 4:17 PM, Hannu Krosing [EMAIL PROTECTED] wrote: One open question is how to translate arrays with non-default subscript values Quote: Subscripted assignment allows creation of arrays that do not use one-based subscripts. For example one might assign to myarray[-2:7] to create an array with subscript values running from -2 to 7. Should I just shift it to standard python tuple, or would it be better to return it as a dictionary with keys from -2 to 7 I think changing the base type is bound to cause issues. For example, suppose someone expects to be able to simply iterate over the array. If they're assuming it's a list, they will expect the values to be returned. If it's a dictionary, the keys will be. If you're going to do that, you'd need to do a custom dict class that iterated over the values I think. David Blewett -- 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] Enable pl/python to return records based on multiple OUT params
On Sat, Nov 1, 2008 at 7:52 AM, Hannu Krosing [EMAIL PROTECTED] wrote: On Sat, 2008-11-01 at 06:13 +0200, Hannu Krosing wrote: attached is a patch which enables plpython to recognize function with multiple OUT params as returning a record Overrides previous patch. Fixed some bugs, added regression tests. Hi Hannu: I was wondering if it would be possible to get plpython to convert IN parameters of type ARRAY to Python lists? I see some example functions here [1], but it would be nice if it was done automatically. David 1. http://archives.postgresql.org/pgsql-general/2007-01/msg01417.php -- 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] pre-MED
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter [EMAIL PROTECTED] wrote: Also, PL/Perl shouldn't be the only language to have this capability. How might we add similar capabilities to PL/PythonU and PL/Tcl? To the rest of the PLs? Would it make any sense to have it in SQL language functions? Here's a vote for allowing this in plain SQL. I use the tablefunc contrib module as a way to build a view of a specific questionnaire's responses (using Elein's nice model here [1]). Currently, if I then write queries against these views that include WHERE clauses they don't perform very well as the underlying data size grows. I was using the afore-mentioned large view that casts everything to text, but recently I started using separate calls to the crosstab function for each underlying table, then joining them together based on their response ID. This seems to work much better for more complex queries, but I think it would still be beneficial to have access to these qualifiers so I could push down to each subquery the list of response ID's to pull. I don't have access to sample SQL at the moment, but if it is wanted I can try to get that this week. David Blewett 1. http://www.varlena.com/GeneralBits/110.php -- 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] migrate data 6.5.3 - 8.3.1
On Thu, Aug 14, 2008 at 9:58 AM, alexander lunyov [EMAIL PROTECTED] wrote: Hello everybody. We have a dusty old server, FreeBSD 3.3-RELEASE, PostgreSQL 6.5.3. I need to migrate four DBs from old server to new server (FreeBSD 6.2, PostgreSQL 8.3.1). Just an FYI: I advised Alexander to post here, because I thought some of the devs might have older pg installs/dump tools and might be able to give some advice. David Blewett -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PL/PythonU
Hi All: This is an off-shoot of the Do we really want to migrate plproxy and citext into PG core distribution? thread. On the way home from PyOhio, I had a conversation with a few people that use Zope a lot. I happened to mention that Postgres doesn't have an untrusted version of pl/python and they were curious as to why. They directed me to Zope's Restricted Python implementation [1][2]. In doing some research, I found the Pl/Python -- current maintainer? [3] thread from 2006. I also found this [4] thread on the python-dev mailing list. Hannu: You had mentioned bringing pl/python up to the level of some of the other pl's. Have you thought any more about pl/pythonu? David Blewett -- A few quotes from the python-dev thread (links at bottom): Here is some context for Python-Dev. RestrictedPython is a custom Python compiler that, when combined with a restricted environment, provides a sandbox safe enough to allow partly-trusted people to write and execute scripts on a Zope server. It has been used in Zope 2 for a long time and will have a future in Zope 3. The sandbox is more extensive than what the rexec module provides. The safety of RestrictedPython has been validated in a somewhat formal process with Python 2.4. Ranjith is working to validate it with Python 2.5. -- Shane Hathaway [5] No, he means the restricted Python compiler and capability-proxy system used by Zope. You know, the one I always bring up whenever anybody says they want to implement capabilities in Python? ;-) Zope's restricted Python is basically a combination of a special compiler, __builtin__ replacements, and a proxy type. Instead of using LOAD_ATTR opcodes, the compiler generates code that calls a special getattr() function instead, and most objects other than relatively-safe builtin types are wrapped in proxies that control what attributes can be accessed and what operations can be performed. The restricted Python framework itself doesn't impose any particular security policy; proxies delegate checks to checker objects that are essentially capabilities. Mostly, it focuses on creating a safe sandbox that can be expanded. -- Phillip J. Eby [6] 1. http://svn.zope.org/RestrictedPython/trunk/ 2. http://svn.zope.org/zope.security/trunk/src/zope/security/untrustedpython/ 3. http://archives.postgresql.org/pgsql-hackers/2006-02/msg01036.php 4. http://mail.python.org/pipermail/python-dev/2008-July/081340.html 5. http://mail.python.org/pipermail/python-dev/2008-July/081412.html 6. http://mail.python.org/pipermail/python-dev/2008-July/081347.html -- 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] PL/Python
On Mon, Aug 4, 2008 at 1:56 PM, Hannu Krosing [EMAIL PROTECTED] wrote: Hannu: You had mentioned bringing pl/python up to the level of some of the other pl's. Have you thought any more about pl/pythonu? Obviously, I meant pl/python. Subject line fixed to. Sorry for the noise. David Blewett -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
