On Sat, Feb 12, 2011 at 10:45 AM, Noah Misch wrote:
> That said, I've tried both constructions, and I marginally prefer the end
> result
> with AlteredTableInfo.verify. I've inlined ATColumnChangeRequiresRewrite into
> ATPrepAlterColumnType; it would need to either pass back two bools or take an
Dimitri Fontaine wrote:
Now, what I think I would do about the core package is a quite simple
backport of them, using Martin's excellent work. Do we want our own QA
on them? If yes, I think I would need some help here, maybe with some
build farm support for running from our debian packages rath
Magnus Hagander writes:
> On Sat, Feb 12, 2011 at 22:46, Dimitri Fontaine
> wrote:
>> If we really believe that the debian interpretation of the licence issue
>> here is moot, surely the easiest action is to offer a debian package
>> repository hosted in the postgresql.org infrastructure.
>>
> A
Tom Lane writes:
> Right, the basic difficulty here is exactly that in a Makefile that's
> building multiple shlibs, there is no easy way to decide which shlibs go
> with which sql scripts. The existing implementation essentially relies
> on the base name of the sql script matching the base name
> charles.mcdev...@emc.com wrote:
> > The GNU people will never be 100% satisfied by anything you do to psql,
> > other
> than making it GPL.
> > Readline is specifically licensed in a way to try to force this (but many
> > disagree
> with their ability to force this).
> >
>
> The "GNU people" a
On Feb 12, 2011, at 3:37 PM, Tom Lane wrote:
>> How likely is *that*?
>
> Not very, but the rules are getting a bit complicated ...
Doesn't seem complicated to me:
1. Use -- to separate extension name, old version, new version
2. Don't use - at the beginning or end of name or version number
3.
"David E. Wheeler" writes:
> On Feb 12, 2011, at 3:12 PM, Tom Lane wrote:
>> Hm. I think we'd still have to disallow dash as the first or last
>> character in a version name to make that unambiguous. Not sure it's
>> worth the trouble.
> How likely is *that*?
Not very, but the rules are gettin
On Feb 12, 2011, at 3:12 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Feb 12, 2011, at 2:29 PM, Tom Lane wrote:
>>> I did think of another idea besides forbidding dash in extension names:
>>> what if we use double dash as the name/version separator,
>
>> +1 You might even consider mand
"David E. Wheeler" writes:
> On Feb 12, 2011, at 2:29 PM, Tom Lane wrote:
>> I did think of another idea besides forbidding dash in extension names:
>> what if we use double dash as the name/version separator,
> +1 You might even consider mandating a double-dash between versions, so that
> they
On Feb 12, 2011, at 2:29 PM, Tom Lane wrote:
> I did think of another idea besides forbidding dash in extension names:
> what if we use double dash as the name/version separator, ie the naming
> conventions are like
> extension--version.control
> extension--version.sql
> extensio
On Sat, Feb 12, 2011 at 03:42:17PM -0600, Kevin Grittner wrote:
> In two hours of testing with a 90GB production database, the copy
> patch on top of HEAD ran 0.6% faster than HEAD for pg_dumpall
> (generating identical output files), but feeding that in to and
> empty cluster with psql ran 8.4% fa
Dimitri Fontaine writes:
> Tom Lane writes:
>> Right, the basic difficulty here is exactly that in a Makefile that's
>> building multiple shlibs, there is no easy way to decide which shlibs go
>> with which sql scripts. The existing implementation essentially relies
>> on the base name of the sq
This is another bit of the syncrep patch split out.
I will revisit the replication timeout one Real Soon, I promise -- but
I have a couple things to do today that may delay that until the
evening.
https://github.com/fdr/postgres/commit/ad3ce9ac62f0e128d7d1fd20d47184f867056af1
Context diff suppli
On Sat, Feb 12, 2011 at 22:46, Dimitri Fontaine wrote:
> Tom Lane writes:
>> Less narrow-minded interpretation of GPL requirements, perhaps.
>> (And yes, we have real lawyers on staff considering these issues.)
>
> If we really believe that the debian interpretation of the licence issue
> here is
Dimitri Fontaine writes:
> Tom Lane writes:
>> pgxs.mk will substitute for MODULE_PATHNAME in it is
>> "$libdir/hstore-1.0" ... not exactly what's wanted. This is because the
>> transformation rule depends on $*, ie the base name of the input file.
> A though that is occurring to me here would
Oops, thank for remind !
Oleg
On Sat, 12 Feb 2011, Tom Lane wrote:
Jeff Davis writes:
btree_gist is essentially required for exclusion constraints to be
useful in a practical way.
In fact, can you submit it for the next commitfest to be included in
core? That would allow range types and ex
Tom Lane writes:
> Less narrow-minded interpretation of GPL requirements, perhaps.
> (And yes, we have real lawyers on staff considering these issues.)
If we really believe that the debian interpretation of the licence issue
here is moot, surely the easiest action is to offer a debian package
rep
Jeff Davis writes:
> btree_gist is essentially required for exclusion constraints to be
> useful in a practical way.
> In fact, can you submit it for the next commitfest to be included in
> core? That would allow range types and exclusion constraints to be used
> out-of-the-box in 9.2.
> Only if
Noah Misch wrote:
> I'd say, run them with this patch alone. The important thing is
> to not penalize existing COPY users. Incidentally, the "did you
> want ... ?" was a genuine question. I see very little performance
> risk here, so the tests could be quite cursory, even absent
> entirely.
"mac_man2...@yahoo.it" wrote:
> So, invoking or not invoking sorting depends on different
> parameters of the specific DBMS, does it?
In the right circumstances (where autovacuum or other maintenance
jobs happen to run in the background at the right moment), two
back-to-back runs on the same d
2011/2/12 mac_man2...@yahoo.it :
> So, invoking or not invoking sorting depends on different parameters of the
> specific DBMS, does it?
>
> This also means that it depends on the specific implementation of the
> Planner and, as a consequence, on the specific DBMS?
> I mean, different DBMS can chos
So, invoking or not invoking sorting depends on different parameters of
the specific DBMS, does it?
This also means that it depends on the specific implementation of the
Planner and, as a consequence, *on the specific DBMS*?
I mean, different DBMS can chose differently on invoking sorting even
On Sat, 2011-02-12 at 18:53 +0300, Oleg Bartunov wrote:
> > It sure seems like
> > http://www.postgresql.org/docs/9.0/static/btree-gist.html could be and
> > should be improved, in general.. If this module is really still just a
> > test bed for GiST, then perhaps it's not a big deal..
>
> No, it
I wrote:
> it seems likely that such a cycle might be related to this new
> code not properly allowing for some aspect of tuple cleanup.
I found a couple places where cleanup could let these fall through
the cracks long enough to get stale and still be around when a tuple
ID is re-used, causing
On lör, 2011-02-12 at 13:34 +0100, Rémi Zara wrote:
> Since the per-column collation patch went in, pika (NetBSD 5.1/mips) started
> failing consistently with this diff:
>
> ***
> /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/expected/polymorphism.out
> Sat Feb 12 02:16:07 201
Tom Lane writes:
> pgxs.mk will substitute for MODULE_PATHNAME in it is
> "$libdir/hstore-1.0" ... not exactly what's wanted. This is because the
> transformation rule depends on $*, ie the base name of the input file.
[...]
> On balance #3 seems the least bad, but I wonder if anyone sees this
>
On Mon, 2011-01-31 at 16:12 +0900, Fujii Masao wrote:
> On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes wrote:
> > I do not understand what doing so gets us.
> >
> > Say we previously received 2/3 of a WAL file, and replayed most of it.
> > So now the shared buffers have data that has been synced to
On Sat, 2011-02-12 at 09:32 -0500, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 12:52 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> Actually... wait a minute. Now that I'm thinking about this a little
> >> more, I'm not so convinced. If we leave this the way is,
YAMAMOTO Takashi wrote:
> i have seen this actually happen. i've confirmed the creation of
> the loop with the attached patch. it's easily reproducable with
> my application. i can provide the full source code of my
> application if you want. (but it isn't easy to run unless you are
> familiar
I've run into a small infelicity that was introduced by our recent round
of redesign of the extensions feature. Specifically, if we have an
installation script that is named like hstore-1.0.sql.in, then what
pgxs.mk will substitute for MODULE_PATHNAME in it is
"$libdir/hstore-1.0" ... not exactly
Stephen,
On Sat, 12 Feb 2011, Stephen Frost wrote:
Oleg,
* Oleg Bartunov (o...@sai.msu.su) wrote:
what do you need for documentation ? From users point of view we add just
knn support and all examples are available in btree_gist.sql and sql
subdirectory. Contact me directly, if you have quest
* Robert Haas (robertmh...@gmail.com) wrote:
> I think a big part of the problem here is that we have wildly
> inconsistent terminology for no especially good reason.
Agreed.
> Thoughts, comments?
I thought about this for a bit and agree w/ your suggestions.
So, +1 from me.
Thanks,
On Fri, Feb 11, 2011 at 02:49:27PM -0500, Robert Haas wrote:
> You might want to consider a second boolean in lieu of a three way
> enum. I'm not sure if that's cleaner but if it lets you write:
>
> if (blah)
> at->verify = true;
>
> instead of:
>
> if (blah)
> at->worklevel = Min(at->
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Tom Lane wrote:
> > > >> Bruce Momjian writes:
> > > >>> I have reviewed is_absolute_path() and have implemented
> > > >>> path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc'
> >
On Fri, Feb 11, 2011 at 12:52 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Actually... wait a minute. Now that I'm thinking about this a little
>> more, I'm not so convinced. If we leave this the way is, and just
>> paper over the problem using the method Stephen an
Itagaki,
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> On Sat, Feb 12, 2011 at 05:01, Stephen Frost wrote:
> > What does the spec say about this, if anything? Is that required by
> > spec, or is the spec not relevant to this because MULTISETs are only one
> > dimensional..?
>
> Yes.
On Sat, Feb 12, 2011 at 7:47 AM, Stephen Frost wrote:
> Oleg,
>
> * Oleg Bartunov (o...@sai.msu.su) wrote:
>> what do you need for documentation ? From users point of view we add just
>> knn support and all examples are available in btree_gist.sql and sql
>> subdirectory. Contact me directly, if y
Oleg,
* Oleg Bartunov (o...@sai.msu.su) wrote:
> what do you need for documentation ? From users point of view we add just
> knn support and all examples are available in btree_gist.sql and sql
> subdirectory. Contact me directly, if you have questions.
It sure seems like
http://www.postgresql.or
Hi,
Since the per-column collation patch went in, pika (NetBSD 5.1/mips) started
failing consistently with this diff:
***
/home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/expected/polymorphism.out
Sat Feb 12 02:16:07 2011
---
/home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/tes
I had tried that before. That doesn't seem to change anything. JDBC still
expects 6 OUT parameters, instead of just 1...
2011/2/11 Robert Haas
> On Tue, Jan 25, 2011 at 2:39 AM, Lukas Eder wrote:
> > So what you're suggesting is that the plpgsql code is causing the issues?
> > Are there any ind
Hello, and sorry for the delay,
* Peter Rosin wrote on Sat, Jan 29, 2011 at 02:26:24PM CET:
> Or is plain 'ar' used somewhere instead of 'x86_64-w64-mingw32-ar'?
Automake outputs 'AR = ar' in Makefile.in for rules creating old
libraries iff neither AC_PROG_LIBTOOL nor another method to define
AR
hi,
> YAMAMOTO Takashi wrote:
>
>> it seems that PredicateLockTupleRowVersionLink sometimes create
>> a loop of targets (it founds an existing 'newtarget' whose
>> nextVersionOfRow chain points to the 'oldtarget') and it later
>> causes CheckTargetForConflictsIn loop forever.
>
> Is this a hy
On 11/02/11 10:53, Jan Urbański wrote:
> On 10/02/11 22:26, Steve Singer wrote:
Here's an updated patch with documentation. It's an incremental patch on
top of the latest explicit-subxacts version.
Cheers,
Jan
diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml
index 87be8c2..aee
On 11/02/11 17:22, Steve Singer wrote:
> On 11-02-10 05:20 AM, Jan Urbański wrote:
>>
>> D'oh, I was thinking about whether it's safe to skip the internal
>> subxact if you're in an implicit one and somehow I always convinced
>> myself that since you eventually close the explicit one, it is.
>>
>>
On Sun, Feb 6, 2011 at 15:31, Andrew Dunstan wrote:
> Force strings passed to and from plperl to be in UTF8 encoding.
>
> String are converted to UTF8 on the way into perl and to the
> database encoding on the way back. This avoids a number of
> observed anomalies, and ensures Perl a consistent vi
On 12/02/11 10:00, Alex Hunsaker wrote:
> On Sat, Feb 12, 2011 at 01:50, Jan Urbański wrote:
>> On 12/02/11 04:12, Alex Hunsaker wrote:
>>> In PLy_traceback fname and prname look like they will leak (well as
>>> much as a palloc() in an error path can leak I suppose).
>>
>> But they're no palloc'd
On Sat, Feb 12, 2011 at 01:50, Jan Urbański wrote:
> On 12/02/11 04:12, Alex Hunsaker wrote:
>> In PLy_traceback fname and prname look like they will leak (well as
>> much as a palloc() in an error path can leak I suppose).
>
> But they're no palloc'd, no? fname is either a static " string,
> or P
On 12/02/11 04:12, Alex Hunsaker wrote:
> On Wed, Feb 9, 2011 at 02:10, Jan Urbański wrote:
>> On 06/02/11 20:12, Jan Urbański wrote:
>>> On 27/01/11 22:58, Jan Urbański wrote:
On 23/12/10 14:56, Jan Urbański wrote:
> Here's a patch implementing traceback support for PL/Python mentioned i
Stephen,
what do you need for documentation ? From users point of view we add just
knn support and all examples are available in btree_gist.sql and sql
subdirectory. Contact me directly, if you have questions.
Oleg
On Fri, 11 Feb 2011, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.co
49 matches
Mail list logo
