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
24 matches
Mail list logo
