it 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.
--
T
On Tue, May 3, 2011 at 9:51 PM, David Blewett 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: ... b
dded 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 ap
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
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 pars
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" wrote:
On 09/18/2010 11:37 AM, Tom Lane wrote:
>
> Andr
On Fri, Sep 3, 2010 at 12:23 PM, Heikki Linnakangas
wrote:
> On 03/09/10 18:53, David Blewett wrote:
>>
>> On Fri, Sep 3, 2010 at 11:47 AM, Tom Lane wrote:
>>>
>>> IOW, what I'd like to see is protocol extensions that allow an external
>>> copy of
el 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 Bl
On Sun, Jan 17, 2010 at 4:07 PM, James William Pye 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
On Wed, Jul 15, 2009 at 4:07 PM, Tom Lane wrote:
> David Blewett writes:
>> On Wed, Jul 15, 2009 at 12:17 PM, Tom Lane wrote:
>>> Well, it might make sense to allow an ENCODING option attached to a COPY
>>> with a file source/destination. I remain of
Apologies to Tom for the duplicate...
On Wed, Jul 15, 2009 at 12:17 PM, Tom Lane 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
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
[ 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
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
On Thu, May 28, 2009 at 9:06 PM, Andrew Dunstan 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
On Fri, May 8, 2009 at 12:10 PM, Tom Lane wrote:
> Seth Robertson 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
;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
On Thu, Apr 30, 2009 at 8:30 AM, James Pye 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
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
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,
onse 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 c
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
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. Sorr
entioned 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 compil
24 matches
Mail list logo
