On Tue, Apr 11, 2017 at 12:14 AM, Peter Eisentraut
wrote:
> Why $subject?
>
> Does it just need to be wired into the makefiles a bit better?
Looks like an oversight to me. I would suggest changing the Makefile like that:
diff --git a/contrib/bloom/Makefile b/contrib/bloom/Makefile
index 13bd397b7
Why $subject?
Does it just need to be wired into the makefiles a bit better?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Thu, Mar 9, 2017 at 7:23 PM, Michael Paquier
wrote:
> Thanks. Shouldn't this fix be back-patched? pg_visibility should fail
> properly for indexes and other relkinds even in 9.6. pgstattuple can
> also trigger failures. It would be confusing for users to face "could
> not open file" kind of err
On Fri, Mar 10, 2017 at 9:34 AM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> Thanks. Shouldn't this fix be back-patched? pg_visibility should fail
>> properly for indexes and other relkinds even in 9.6. pgstattuple can
>> also trigger failures. It would be confus
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> Thanks. Shouldn't this fix be back-patched? pg_visibility should fail
> properly for indexes and other relkinds even in 9.6. pgstattuple can
> also trigger failures. It would be confusing for users to face "could
> not open file" kind
On Fri, Mar 10, 2017 at 8:59 AM, Amit Langote
wrote:
> Hi Stephen,
>
> On 2017/03/10 6:48, Stephen Frost wrote:
>> Amit, Michael,
>>
>> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>>> On 2017/03/09 11:51, Michael Paquier wrote:
OK, I am marking that as ready for committer.
>>>
>>> T
Hi Stephen,
On 2017/03/10 6:48, Stephen Frost wrote:
> Amit, Michael,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> On 2017/03/09 11:51, Michael Paquier wrote:
>>> OK, I am marking that as ready for committer.
>>
>> Thanks.
>
> Thanks for this, I've pushed this now. I do have a f
Amit, Michael,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2017/03/09 11:51, Michael Paquier wrote:
> > OK, I am marking that as ready for committer.
>
> Thanks.
Thanks for this, I've pushed this now. I do have a few notes about
changes that I made from your patch;
- Generally s
Amit, Michael,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2017/03/09 11:51, Michael Paquier wrote:
> > On Wed, Mar 8, 2017 at 5:10 PM, Amit Langote
> > wrote:
> >> On 2017/03/08 16:47, Michael Paquier wrote:
> >>> Only regular tables are tested as valid objects. Testing toast tabl
On 2017/03/09 11:51, Michael Paquier wrote:
> On Wed, Mar 8, 2017 at 5:10 PM, Amit Langote
> wrote:
>> On 2017/03/08 16:47, Michael Paquier wrote:
>>> Only regular tables are tested as valid objects. Testing toast tables
>>> is not worth the complication. Could you add as well a matview?
>>
>> Don
On Wed, Mar 8, 2017 at 5:10 PM, Amit Langote
wrote:
> On 2017/03/08 16:47, Michael Paquier wrote:
>> Only regular tables are tested as valid objects. Testing toast tables
>> is not worth the complication. Could you add as well a matview?
>
> Done in the attached updated patch.
+select count(*) >
On 2017/03/08 16:47, Michael Paquier wrote:
> On Tue, Mar 7, 2017 at 4:15 PM, Amit Langote wrote:
> +++ b/contrib/pg_visibility/expected/pg_visibility.out
> @@ -0,0 +1,85 @@
> +CREATE EXTENSION pg_visibility;
> +--
> +-- check that using the module's functions with unsupported relations will
> fai
On Tue, Mar 7, 2017 at 4:15 PM, Amit Langote
wrote:
> Sorry about the absence on this thread.
No problems! Thanks for showing up with an updated patch.
> On 2017/02/14 15:30, Michael Paquier wrote:
>> On Tue, Feb 14, 2017 at 3:18 PM, Amit Langote wrote:
>>>
>>> Added more tests in pgstattuple an
Sorry about the absence on this thread.
On 2017/02/14 15:30, Michael Paquier wrote:
> On Tue, Feb 14, 2017 at 3:18 PM, Amit Langote wrote:
>>
>> Added more tests in pgstattuple and the new ones for pg_visibility,
>> although I may have overdone the latter.
>
> A bonus idea is also to add tests fo
On Tue, Mar 7, 2017 at 3:10 AM, Corey Huinker wrote:
> Michael, do you want to add yourself as a reviewer?
Yes, thanks for the reminder.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
On Tue, Feb 14, 2017 at 1:30 AM, Michael Paquier
wrote:
> Hm... It may be a good idea to be consistent on the whole system and
> refer to "partitioned table" as a table without storage and used as an
> entry point for partitions. The docs use this term in CREATE TABLE,
> and we would finish with
On Tue, Feb 14, 2017 at 3:18 PM, Amit Langote
wrote:
> On 2017/02/13 14:59, Michael Paquier wrote:
> I see, thanks for explaining. Implemented that in the attached, also
> fixing the errcode. Please see if that's what you had in mind.
Yes. That's it, the overall patch footprint is reduced.
> I
On 2017/02/13 14:59, Michael Paquier wrote:
> On Fri, Feb 10, 2017 at 4:29 PM, Amit Langote wrote:
>> On 2017/02/10 14:32, Michael Paquier wrote:
>>> The visibility checks are localized in pg_visibility.c and the storage
>>> checks in pgstatindex.c, so yes we could have macros in those files.
>>> O
On Fri, Feb 10, 2017 at 4:29 PM, Amit Langote
wrote:
> On 2017/02/10 14:32, Michael Paquier wrote:
>> On Thu, Feb 9, 2017 at 7:21 AM, Corey Huinker
>> wrote:
>
> Thanks Corey and Michael for the reviews!
>
>>> 1. should have these tests named in core functions, like maybe:
>>>
>>> relation_has_v
On 2017/02/10 14:32, Michael Paquier wrote:
> On Thu, Feb 9, 2017 at 7:21 AM, Corey Huinker wrote:
Thanks Corey and Michael for the reviews!
>> 1. should have these tests named in core functions, like maybe:
>>
>> relation_has_visibility(Relation)
>> relation_has_storage(Relation)
>> and/or corr
On Thu, Feb 9, 2017 at 7:21 AM, Corey Huinker wrote:
> Is this still needing a reviewer?
Useful input is always welcome.
> Code is quite clear. It does raise two questions:
>
> 1. should have these tests named in core functions, like maybe:
>
> relation_has_visibility(Relation)
> relation_has_st
On Mon, Feb 6, 2017 at 4:01 AM, Amit Langote
wrote:
> On 2017/01/24 15:35, Amit Langote wrote:
> > On 2017/01/24 15:11, Michael Paquier wrote:
> >> On Tue, Jan 24, 2017 at 2:14 PM, Amit Langote
> >> wrote:
> >>> Some contrib functions fail to fail sooner when relations of
> unsupported
> >>> rel
On 2017/01/24 15:35, Amit Langote wrote:
> On 2017/01/24 15:11, Michael Paquier wrote:
>> On Tue, Jan 24, 2017 at 2:14 PM, Amit Langote
>> wrote:
>>> Some contrib functions fail to fail sooner when relations of unsupported
>>> relkinds are passed, resulting in error message like one below:
>>>
>>>
On 2017/01/24 15:11, Michael Paquier wrote:
> On Tue, Jan 24, 2017 at 2:14 PM, Amit Langote
> wrote:
>> Some contrib functions fail to fail sooner when relations of unsupported
>> relkinds are passed, resulting in error message like one below:
>>
>> create table foo (a int);
>> create view foov as
On Tue, Jan 24, 2017 at 2:14 PM, Amit Langote
wrote:
> Some contrib functions fail to fail sooner when relations of unsupported
> relkinds are passed, resulting in error message like one below:
>
> create table foo (a int);
> create view foov as select * from foo;
> select pg_visibility('foov', 0)
Some contrib functions fail to fail sooner when relations of unsupported
relkinds are passed, resulting in error message like one below:
create table foo (a int);
create view foov as select * from foo;
select pg_visibility('foov', 0);
ERROR: could not open file "base/13123/16488": No such file or
I should also note that this is on github at
https://github.com/twosigma/postgresql-contrib
Nico
--
--
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, Jan 23, 2017 at 06:05:25PM -0600, Jim Nasby wrote:
> On 1/23/17 5:38 PM, Nico Williams wrote:
> >Attached is an alternative implementation of MATERIALIZED VIEWs.
>
> Interesting. I don't see this being accepted into core because it's plpgsql
> and it depends on the user to track what crite
On Tue, Jan 24, 2017 at 12:48:49AM +0100, Marko Tiikkaja wrote:
> Did you forget the attachment?
I guess I must have. Attached this time.
/*
* Copyright (c) 2016 Two Sigma Open Source, LLC.
* All Rights Reserved
*
* Permission to use, copy, modify, and distribute this software and its
* docu
On 1/23/17 5:38 PM, Nico Williams wrote:
Attached is an alternative implementation of MATERIALIZED VIEWs.
Interesting. I don't see this being accepted into core because it's
plpgsql and it depends on the user to track what criteria to use to
apply the update. The second item is the biggest is
On Tue, Jan 24, 2017 at 12:40 AM, Nico Williams
wrote:
> psql(1) does not output notifications asynchronously, as it does not
> check for them when idle. This makes it difficult to script handling of
> NOTIFYs.
>
> Attached is pqasyncnotifier.c, a simple command that allows one to
> handle NOTIF
psql(1) does not output notifications asynchronously, as it does not
check for them when idle. This makes it difficult to script handling of
NOTIFYs.
Attached is pqasyncnotifier.c, a simple command that allows one to
handle NOTIFYs asynchronously.
Cheers,
Nico
--
--
Sent via pgsql-hackers m
Attached is an alternative implementation of MATERIALIZED VIEWs.
The idea is to explore possible enahncements to the PostgreSQL
MATERIALIZED VIEW features.
Features:
- All SQL-coded.
- Keeps history of deltas computed at each refresh.
- Allows DMLs of the materialized view, recording the ch
Robert Haas writes:
> On Fri, Sep 30, 2016 at 10:24 PM, Tom Lane wrote:
>> The problem seems to be that HeapTupleSatisfiesVacuum asserts
>> Assert(ItemPointerIsValid(&htup->t_self));
>> while collect_corrupt_items hasn't bothered to set up the t_self
>> field of the HeapTupleData it's passing in.
On Fri, Sep 30, 2016 at 10:24 PM, Tom Lane wrote:
> So I tried using pg_visibility's pg_check_visible() as part of
> testing the business with pg_upgrade generating faulty visibility
> maps on bigendian servers, and it instantly generated an assert
> failure here:
>
> #2 0x0041de78 in Exceptional
So I tried using pg_visibility's pg_check_visible() as part of
testing the business with pg_upgrade generating faulty visibility
maps on bigendian servers, and it instantly generated an assert
failure here:
#2 0x0041de78 in ExceptionalCondition (conditionName=, errorType=, fileName=, lineNumber=)
On Wed, Feb 25, 2015 at 08:36:49PM -0500, Andrew Dunstan wrote:
> >>>I doubt we want to rip it out without some suitable
> >>>replacement -- do we?
> >>>
> >>>
> >>
> >>That's more than 10 years ago. I remember creating this for my then work
> >>at the North Carolina State Highway Patrol and sendin
On Thu, Feb 26, 2015 at 8:56 AM, Stephen Frost wrote:
> * Jim Nasby (jim.na...@bluetreble.com) wrote:
>> On 2/25/15 4:10 PM, Andrew Dunstan wrote:
>> >
>> >On 02/25/2015 11:59 AM, Joe Conway wrote:
>> >>>
>> >>>It's largely because of such uncertainties that I have been advised
>> >>>in the past (
On 02/25/2015 06:44 PM, Jim Nasby wrote:
On 2/25/15 4:10 PM, Andrew Dunstan wrote:
On 02/25/2015 11:59 AM, Joe Conway wrote:
It's largely because of such uncertainties that I have been advised
in the past (by those with appropriate letters after their names)
to stop using the Artistic licenc
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 2/25/15 4:10 PM, Andrew Dunstan wrote:
> >
> >On 02/25/2015 11:59 AM, Joe Conway wrote:
> >>>
> >>>It's largely because of such uncertainties that I have been advised
> >>>in the past (by those with appropriate letters after their names)
> >>>to st
On 2/25/15 4:10 PM, Andrew Dunstan wrote:
On 02/25/2015 11:59 AM, Joe Conway wrote:
It's largely because of such uncertainties that I have been advised
in the past (by those with appropriate letters after their names)
to stop using the Artistic licence. This is why I spent nearly a
year workin
On 02/25/2015 11:59 AM, Joe Conway wrote:
It's largely because of such uncertainties that I have been advised
in the past (by those with appropriate letters after their names)
to stop using the Artistic licence. This is why I spent nearly a
year working on changing pgAdmin to the PostgreSQL lic
On 02/25/2015 06:59 PM, Joe Conway wrote:
I doubt we want to rip it out without some suitable replacement -- do we?
No, probably not. I think there are a few options:
0. Find out that the current situation is OK, and the Artistic license
is not a problem the way the code is used.
1. Ask Mau
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/24/2015 04:47 AM, Dave Page wrote:
> On Tue, Feb 24, 2015 at 12:24 PM, Heikki Linnakangas
> wrote:
>> contrib/fuzzystrmatch/dmetaphone.c says this:
>>
>>> /* COPYRIGHT NOTICES
>>> ***
>>>
>>> Mo
On Tue, Feb 24, 2015 at 12:24 PM, Heikki Linnakangas
wrote:
> contrib/fuzzystrmatch/dmetaphone.c says this:
>
>> /* COPYRIGHT NOTICES ***
>>
>> Most of this code is directly from the Text::DoubleMetaphone perl module
>> version 0.05 available from ht
contrib/fuzzystrmatch/dmetaphone.c says this:
/* COPYRIGHT NOTICES ***
Most of this code is directly from the Text::DoubleMetaphone perl module
version 0.05 available from http://www.cpan.org.
It bears this copyright notice:
Copyright 2000, Ma
Hi
I'm not sure if this is a documentation or hackers issue, but the
documentation page for contrib module "xml2" refers to PostgreSQL 8.4 in
the future tense:
"It is planned that this module will be removed in PostgreSQL 8.4 in
favor of the newer standard API"
http://www.postgresql.org/docs/
On 01/19/2013 05:42 AM, Boszormenyi Zoltan wrote:
> Hi,
>
> I want to test my lock_timeout code under Windows and
> I compiled the whole PG universe with the MinGW cross-compiler
> for 64-bit under Fedora 18.
You're significantly better off compiling for native Windows if at all
possible. Windows c
Andrew Dunstan writes:
> *sigh*. Don't post after midnight. Of course, this isn't relevant to a
> cross-compiling environment, where repeated invocations of make
> repeatedly build the executables.
> The question is whether we care enough about this case to fix it.
I think we certainly need th
On 01/19/2013 12:13 AM, Andrew Dunstan wrote:
On 01/18/2013 11:59 PM, Peter Eisentraut wrote:
The above is the way it's done everywhere else in the source tree.
I think the reason this works is that either make or the system call
that make uses is aware of this naming issue somehow.
Oh, hm
2013-01-19 02:03 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 07:03 PM, Andrew Dunstan wrote:
It's not a good idea it seems.
Because that's only half of what I suggested.
This patch seems to do the right thing.
It probably needs to be applied to all the live branches.
cheers
and
2013-01-19 01:03 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:45 PM, Boszormenyi Zoltan wrote:
2013-01-18 23:37 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:19 PM, Boszormenyi Zoltan wrote:
2013-01-18 22:52 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I want to
On 01/18/2013 11:59 PM, Peter Eisentraut wrote:
The above is the way it's done everywhere else in the source tree.
I think the reason this works is that either make or the system call
that make uses is aware of this naming issue somehow.
Oh, hmm, all these years playing with this stuff and I
On Fri, 2013-01-18 at 17:37 -0500, Andrew Dunstan wrote:
> > ifdef PROGRAM
> > $(PROGRAM): $(OBJS)
> > - $(CC) $(CFLAGS) $(OBJS) $(PG_LIBS) $(LDFLAGS) $(LDFLAGS_EX)
> $(LIBS) -o $@
> > + $(CC) $(CFLAGS) $(OBJS) $(PG_LIBS) $(LDFLAGS) $(LDFLAGS_EX)
> $(LIBS) -o $@$(X)
> > endif
> >
>
>
On 01/18/2013 11:42 PM, Tom Lane wrote:
Andrew Dunstan writes:
This patch seems to do the right thing.
Hmm ... seems kinda grotty ... isn't there a cleaner way?
It probably needs to be applied to all the live branches.
Agreed on back-patching once we have the right thing, but I don't like
Andrew Dunstan writes:
> This patch seems to do the right thing.
Hmm ... seems kinda grotty ... isn't there a cleaner way?
> It probably needs to be applied to all the live branches.
Agreed on back-patching once we have the right thing, but I don't like
this version too much.
On 01/18/2013 07:03 PM, Andrew Dunstan wrote:
It's not a good idea it seems.
Because that's only half of what I suggested.
This patch seems to do the right thing.
It probably needs to be applied to all the live branches.
cheers
andrew
diff --git a/src/makefiles/pgxs.mk b/src/makefi
On 01/18/2013 05:45 PM, Boszormenyi Zoltan wrote:
2013-01-18 23:37 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:19 PM, Boszormenyi Zoltan wrote:
2013-01-18 22:52 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I want to test my lock_timeout code under Windows and
I compi
2013-01-18 23:37 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:19 PM, Boszormenyi Zoltan wrote:
2013-01-18 22:52 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I want to test my lock_timeout code under Windows and
I compiled the whole PG universe with the MinGW cross-compi
On 01/18/2013 05:19 PM, Boszormenyi Zoltan wrote:
2013-01-18 22:52 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I want to test my lock_timeout code under Windows and
I compiled the whole PG universe with the MinGW cross-compiler
for 64-bit under Fedora 18.
The problem contrib
2013-01-18 22:52 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I want to test my lock_timeout code under Windows and
I compiled the whole PG universe with the MinGW cross-compiler
for 64-bit under Fedora 18.
The problem contrib directories where Makefile contains
PROGRAM =
Boszormenyi Zoltan wrote:
> I want to test my lock_timeout code under Windows and
> I compiled the whole PG universe with the MinGW cross-compiler
> for 64-bit under Fedora 18.
>
> The problem contrib directories where Makefile contains
> PROGRAM = ...
> The executables binaries are created
Hi,
I want to test my lock_timeout code under Windows and
I compiled the whole PG universe with the MinGW cross-compiler
for 64-bit under Fedora 18.
The problem contrib directories where Makefile contains
PROGRAM = ...
The executables binaries are created without the .exe suffix. E.g.:
[zoz
On 9/14/12 10:13 AM, Bruce Momjian wrote:
> On Fri, Sep 14, 2012 at 10:59:45AM -0300, Alvaro Herrera wrote:
>> Excerpts from Bruce Momjian's message of vie sep 14 10:37:18 -0300 2012:
>>> Someone asked me about translations for pg_upgrade, and I don't see 'po'
>>> directories for any of the contrib
On Fri, Sep 14, 2012 at 10:59:45AM -0300, Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of vie sep 14 10:37:18 -0300 2012:
> > Someone asked me about translations for pg_upgrade, and I don't see 'po'
> > directories for any of the contrib tools. Do we not translate contrib
> > stuf
Excerpts from Bruce Momjian's message of vie sep 14 10:37:18 -0300 2012:
> Someone asked me about translations for pg_upgrade, and I don't see 'po'
> directories for any of the contrib tools. Do we not translate contrib
> stuff? Why?
We don't. I don't know the exact reason, but I know that whil
Someone asked me about translations for pg_upgrade, and I don't see 'po'
directories for any of the contrib tools. Do we not translate contrib
stuff? Why?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for ev
Excerpts from Dimitri Fontaine's message of mié dic 28 15:12:48 -0300 2011:
> Tom Lane writes:
> > I wonder whether it's time to drop that file altogether ... it served a
> > purpose back before we integrated contrib into the SGML docs, but now
> > I'm not quite sure why we should bother with it.
Tom Lane writes:
> I wonder whether it's time to drop that file altogether ... it served a
> purpose back before we integrated contrib into the SGML docs, but now
> I'm not quite sure why we should bother with it.
I wonder if we shouldn't keep the file and have it just point to the
relevant docum
Alvaro Herrera writes:
> Apparently we forgot to update the README file in contrib/.
I wonder whether it's time to drop that file altogether ... it served a
purpose back before we integrated contrib into the SGML docs, but now
I'm not quite sure why we should bother with it.
Apparently we forgot to update the README file in contrib/. I wonder if
it's necessary to explain that within each directory you find one or
more ".control" file that determines what can be run ... or maybe just
mention the pg_extensions views?
What about this?
diff --git a/contrib/README b/con
Robert Haas wrote:
On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane wrote:
If I have to break up the recipe with annotations like "run this part as
root" and then "these commands no longer need root", I don't think
that's going to be an improvement over either of the above.
Fair enough, I'm not g
On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane wrote:
>>> I have not touched the documentation, either. One thing I'd like to do
>>> is adjust both the SGML documentation and the hints printed by the
>>> script to uniformly use "sudo ...root-privileged-command..." rather than
>>> recommending use of "
Robert Haas writes:
> On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane wrote:
>> Accordingly, the attached patch does what I suggested above, namely dike
>> out the Makefile's knowledge of how to run the regression tests and put
>> it into the chkselinuxenv script.
> Seems fine. The rename is definite
On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane wrote:
> I wrote:
>> I think it should be possible to still use all the existing testing
>> infrastructure if the check/test script does something like
>> make REGRESS="label dml misc" check
>
> I've now worked through the process of actually running
I wrote:
> I think it should be possible to still use all the existing testing
> infrastructure if the check/test script does something like
> make REGRESS="label dml misc" check
I've now worked through the process of actually running the sepgsql
regression tests, and I must say that I had n
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> How about this fix on regression test of sepgsql?
>
> IMO, the fundamental problem with the sepgsql regression tests is that
> they think they don't need to play by the rules that apply to every
> other PG regression test. I don't think this patch is
Kohei KaiGai writes:
> How about this fix on regression test of sepgsql?
IMO, the fundamental problem with the sepgsql regression tests is that
they think they don't need to play by the rules that apply to every
other PG regression test. I don't think this patch is fixing that
problem; it's just
How about this fix on regression test of sepgsql?
It disables to launch regression test together with other modules,
and adds its own build target "sepgsql-installcheck" that launches
chkselinuxenv script then pg_regress command as currently we
are doing.
It allows users to launch regression test
On Mon, Sep 26, 2011 at 11:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
>>> Another possibility is to remove the Makefile's knowledge of how to run
>>> the tests, and change chkselinuxenv into something that both verifies
>>> the environment a
2011/9/26 Tom Lane :
> Robert Haas writes:
>> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
>>> Another possibility is to remove the Makefile's knowledge of how to run
>>> the tests, and change chkselinuxenv into something that both verifies
>>> the environment and then launches the tests.
>
Robert Haas writes:
> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
>> Another possibility is to remove the Makefile's knowledge of how to run
>> the tests, and change chkselinuxenv into something that both verifies
>> the environment and then launches the tests.
> That's not a bad fix, eith
On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
>>> In fact, I've been wondering if we ought to go a step further and not
>>> recurse into the sepgsql directory for *any* of the targets. Then we
>>> could get r
Peter Eisentraut writes:
> On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
>> In fact, I've been wondering if we ought to go a step further and not
>> recurse into the sepgsql directory for *any* of the targets. Then we
>> could get rid of the associated configure option, which no longer
>
On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
> In fact, I've been wondering if we ought to go a step further and not
> recurse into the sepgsql directory for *any* of the targets. Then we
> could get rid of the associated configure option, which no longer
> serves any other purpose, and j
2011/9/26 Tom Lane :
> As a stopgap, what about removing sepgsql from the list of contrib
> modules tested by "make -C contrib check"? (I haven't looked at
> exactly how ugly it might be to do that, nor whether we'd have to also
> disable installcheck from recursing to sepgsql.)
>
Is it unavailabl
On Mon, Sep 26, 2011 at 12:06 AM, Tom Lane wrote:
>> Then we
>> could get rid of the associated configure option, which no longer
>> serves any other purpose, and just say that if you want to build (or
>> regression-test) sepgsql, well, you gotta go to that directory and do
>> it by hand.
>
> The
Robert Haas writes:
> On Sun, Sep 25, 2011 at 9:07 PM, Tom Lane wrote:
>> As a stopgap, what about removing sepgsql from the list of contrib
>> modules tested by "make -C contrib check"?
> +1.
> In fact, I've been wondering if we ought to go a step further and not
> recurse into the sepgsql dir
On Sun, Sep 25, 2011 at 9:07 PM, Tom Lane wrote:
> As a stopgap, what about removing sepgsql from the list of contrib
> modules tested by "make -C contrib check"?
+1.
In fact, I've been wondering if we ought to go a step further and not
recurse into the sepgsql directory for *any* of the targets
So I thought it would be a good idea to enable contrib/sepgsql in the
Fedora build of 9.1. This soon crashed and burned, though, because
(1) if you build sepgsql, there is no way to omit the sepgsql regression
tests, other than by not regression-testing contrib at all. I didn't
see that as a ste
I wrote:
> On further reflection, I'm wondering exactly how much goodness to chop
> off there. What I'd originally been thinking was to just lobotomize the
> case-folding step, and allow citext's comparison operators to still
> respond to input collation when comparing the folded strings. However
Greg Stark writes:
> On Mon, Jun 6, 2011 at 9:14 PM, Tom Lane wrote:
>> The most workable alternative that I can see is to lobotomize citext so
>> that it always does lower-casing according to the database's "default"
>> collation, which would allow us to pretend that its notion of equality
>> is
On Mon, Jun 6, 2011 at 9:14 PM, Tom Lane wrote:
> The most workable alternative that I can see is to lobotomize citext so
> that it always does lower-casing according to the database's "default"
> collation, which would allow us to pretend that its notion of equality
> is not collation-sensitive a
On Jun 6, 2011, at 4:35 PM, Tom Lane wrote:
>> That sounds like a good idea.
>
> BTW, it struck me shortly after sending this that we'd already discussed
> the idea of a flag in pg_proc showing whether a function pays attention
> to collation. We could of course use that for this purpose.
Seems
"David E. Wheeler" writes:
> On Jun 6, 2011, at 1:14 PM, Tom Lane wrote:
>> ... One bit of infrastructure that might be a good idea is
>> a flag to indicate whether an equality operator's behavior is
>> potentially collation-dependent, so that we could avoid taking
>> performance hits in the norm
On Jun 6, 2011, at 1:14 PM, Tom Lane wrote:
> The most workable alternative that I can see is to lobotomize citext so
> that it always does lower-casing according to the database's "default"
> collation, which would allow us to pretend that its notion of equality
> is not collation-sensitive after
I've been looking into bug #6053, in which Regina Obe complains that
hash-based DISTINCT queries fail for type "citext". The cause is not
far to seek: the header comment for execGrouping.c states
* Note: we currently assume that equality and hashing functions are not
* collation-sensitive, so t
On May 12, 2011, at 3:50 PM, Tom Lane wrote:
>> Would changing the versions from 1.0 to 1.0.0 really break anything for
>> those folks?
>
> It would as soon as they needed to do an ALTER EXTENSION UPDATE ..
Ah-ite, screw it then.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-ha
On Thu, May 12, 2011 at 6:33 PM, David E. Wheeler wrote:
>> Having said that, I don't really care that much, except that it seems
>> a bit late in the release cycle to be changing this. People have
>> presumably already got installations that they hope to not have to
>> scratch and reload for 9.1
"David E. Wheeler" writes:
> On May 12, 2011, at 3:09 PM, Tom Lane wrote:
>> Having said that, I don't really care that much, except that it seems
>> a bit late in the release cycle to be changing this. People have
>> presumably already got installations that they hope to not have to
>> scratch a
1 - 100 of 742 matches
Mail list logo
