On 01/30/2014 01:25 PM, Craig Ringer wrote:
On 01/29/2014 09:47 PM, Craig Ringer wrote:
https://github.com/ringerc/postgres/compare/rls-9.4-upd-sb-views
i.e. https://github.com/ringerc/postgres.git ,
branch rls-9.4-upd-sb-views
(subject to rebasing) or the non-rebased tag
Hi,
personally I really dislike constructs like you used:
#ifdef WIN32
if (check_if_admin)
#endif
check_root(progname);
It is hard to read and may confuse editors. Can you rewrite it?
The rest looks fine to me.
Best regards,
--
Christian Kruse
Hi,
For the documentation patch, I propose the attached to avoid future
confusions. Comments? It might make sense to back-patch as well.
Compiles, didn't find any typos and I think it is comprehensible.
Looks fine for me.
Best regards,
--
Christian Kruse
On 2014-01-30 08:32:20 +0100, Christian Kruse wrote:
Hi Tom,
On 29/01/14 20:06, Tom Lane wrote:
Christian Kruse christ...@2ndquadrant.com writes:
Your reasoning sounds quite logical to me. Thus I did a
grep -RA 3 ereport src/* | less
and looked for ereport calls with errno in it. I
Hi,
On 30/01/14 10:15, Andres Freund wrote:
While I understand most modifications I'm a little bit confused by
some parts. Have a look at for example this one:
+ *errstr = psprintf(_(failed to look up effective user id %ld: %s),
+ (long) user_id,
+
Hi Pavel,
it should be fixed by
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b152c6cd0de1827ba58756e24e18110cf902182acommit
Ok. Good.
Sorry I didn't update my sources. Done now. Thanks
Also, I didn't quite understand these lines of comments:
Hi Oskari,
Are you planning to work on what Tom has suggested ? It make sense to me as
well.
What are your views on that ?
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
This seems wrong: in HEAD, an empty select list does *not* generate a error
warning anymore:
$ psql -X
psql (9.4devel_HEAD_20140130_0805_571addd)
Type help for help.
testdb=# create table t as select i from generate_series(1,3) as f(i);
SELECT 3
testdb=# select * from t;
i
---
1
2
3
(3
On 1/30/14, 10:44 AM, Erik Rijkers wrote:
This seems wrong: in HEAD, an empty select list does *not* generate a error
warning anymore:
This is intentional, see 1b4f7f93b4693858cb983af3cd557f6097dab67b
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list
30.01.2014 11:37, Jeevan Chalke kirjoitti:
Hi Oskari,
Are you planning to work on what Tom has suggested ? It make sense to me
as well.
What are your views on that ?
Tom's suggestions make sense to me, but unfortunately I haven't had time
to work on this feature recently so I don't think
(2014/01/30 8:29), Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I could live with just stddev. Not sure others would be so happy.
FWIW, I'd vote for just stddev, on the basis that min/max appear to add
more to the counter update time than stddev does; you've got
this:
+
On Wed, Jan 29, 2014 at 8:48 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
I'd like to know the truth and the fact in your patch, rather than your
argument:-)
I see.
[part of sample sqls file, they are executed in pgbench]
SELECT
Hello
patch with updated comment
regards
Pavel
2014-01-30 Jeevan Chalke jeevan.cha...@enterprisedb.com:
Hi Pavel,
it should be fixed by
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b152c6cd0de1827ba58756e24e18110cf902182acommit
Ok. Good.
Sorry I didn't update
Hi Pavel,
I looked at your latest cleanup patch. Yes its looks more cleaner in term
equivalent_locale equivalent_encoding separate functions.
I did run the test again on latest patch and all looks good.
Marking it as ready for committer.
Regards,
On Fri, Jan 24, 2014 at 9:49 PM, Pavel
On Thu, Jan 30, 2014 at 12:23 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Jan 29, 2014 at 8:13 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Few observations in patch (back-to-pglz-like-delta-encoding-1):
1.
+#define pgrb_hash_unroll(_p, hindex) \
+ hindex = hindex ^
On Tue, Jan 21, 2014 at 1:33 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 20 January 2014 17:00, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What if you're a superuser and you want to move everybody's objects
(perhaps in preparation for dropping the
On 30 January 2014 05:36, Craig Ringer cr...@2ndquadrant.com wrote:
On 01/29/2014 08:29 PM, Dean Rasheed wrote:
On 29 January 2014 11:34, Craig Ringer cr...@2ndquadrant.com wrote:
On 01/23/2014 06:06 PM, Dean Rasheed wrote:
On 21 January 2014 09:18, Dean Rasheed dean.a.rash...@gmail.com wrote:
On Wed, Jan 29, 2014 at 12:35 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Jan 29, 2014 at 10:55 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jan 29, 2014 at 3:07 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Anybody knows about this patch?
Hi Pavel,
Now patch looks good to me and I think it is in good shape to pass it on to
the committer as well.
However, I have
- Tweaked few comments
- Removed white-space errors
- Fixed typos
- Fixed indentation
Attached patch with my changes. However entire design and code logic is
untouched.
I'm sorry for the late reply. I was unable to access email.
From: Craig Ringer cr...@2ndquadrant.com
On 01/24/2014 06:42 PM, MauMau wrote:
The customer is using 64-bit PostgreSQL 9.1.x
Which x?
9.1.6.
Does this issue also occur on 9.3.2, or in 9.4 HEAD, when tested on
Win2k12?
I'm
From: Ronan Dunklau ronan.dunk...@dalibo.com
There is no regression tests covering this bugfix, althought I don't know
if
it would be practical to implement them.
Thanks for reviewing the patch. I'm glad to know that it seems OK.
Unfortunately, the current regression test system cannot
Hello
All is ok
Thank you
Pavel
2014-01-30 Jeevan Chalke jeevan.cha...@enterprisedb.com:
Hi Pavel,
Now patch looks good to me and I think it is in good shape to pass it on to
the committer as well.
However, I have
- Tweaked few comments
- Removed white-space errors
- Fixed typos
-
OK.
Assigned it to committer.
Thanks for the hard work.
On Thu, Jan 30, 2014 at 6:16 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
All is ok
Thank you
Pavel
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL
2014-01-30 Jeevan Chalke jeevan.cha...@enterprisedb.com:
OK.
Assigned it to committer.
Thanks for the hard work.
Thank you for review
Pavel
On Thu, Jan 30, 2014 at 6:16 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
All is ok
Thank you
Pavel
--
Jeevan B Chalke
Hi,
Alvaro Herrera alvhe...@2ndquadrant.com writes:
So here's a patch implementing the ideas expressed in this thread.
There are two new SQL functions:
I spent some time reviewing the patch and tried to focus on a higher
level review, as I saw Andres already began with the lower level stuff.
On 30 January 2014 11:55, Dean Rasheed dean.a.rash...@gmail.com wrote:
Hmm, looks like this is a pre-existing bug.
The first thing I tried was to reproduce it using SQL, so I used a
RULE to turn a DELETE into a SELECT FOR UPDATE. This is pretty dumb,
but it shows the problem:
CREATE TABLE
Craig, all,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
I'm considering just punting on inheritance for 9.4, adding checks to
prohibit inheritance from being added to a rel with row security and
prohibiting any rel with inheritance from being given a row-security policy.
I'm alright with
On Mon, Jan 27, 2014 at 10:48:16PM -0500, Bruce Momjian wrote:
On Mon, Jan 27, 2014 at 07:19:21PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Oh, one odd thing about this patch. I found I needed to use INT64_MAX,
but I don't see it used anywhere else in our codebase.
Christian Kruse christ...@2ndquadrant.com writes:
Have a look at the psprintf() call: we first have a _(failed to look
up effective user id %ld: %s) as an argument, then we have a (long)
user_id and after that we have a ternary expression using errno. Isn't
it possible that the first _()
Tom Lane wrote:
Christian Kruse christ...@2ndquadrant.com writes:
Have a look at the psprintf() call: we first have a _(failed to look
up effective user id %ld: %s) as an argument, then we have a (long)
user_id and after that we have a ternary expression using errno. Isn't
it possible
Hi,
On 30/01/14 10:01, Tom Lane wrote:
While I haven't actually read the gettext docs, I'm pretty sure that
gettext() is defined to preserve errno. It's supposed to be something
that you can drop into existing printf's without thinking, and if
it mangled errno that would certainly not be the
ok, great. This is really fabulous. So far most everything feels
natural and good.
I see something odd in terms of the jsonb use case coverage. One of
the major headaches with json deserialization presently is that
there's no easy way to easily move a complex (record- or array-
containing)
KONDO Mitsumasa kondo.mitsum...@lab.ntt.co.jp writes:
(2014/01/30 8:29), Tom Lane wrote:
If we felt that min/max were of similar value to stddev then this
would be mere nitpicking. But since people seem to agree they're
worth less, I'm thinking the cost/benefit ratio isn't there.
Why do you
Shigeru Hanada shigeru.han...@gmail.com writes:
At the moment we don't use attstorage for foreign tables, so allowing
SET STORAGE against foreign tables never introduce visible change
except \d+ output of foreign tables. But IMO such operation should
not allowed because users would be
On 01/30/2014 01:53 AM, Tomas Vondra wrote:
(3) A file with explain plans for 4 queries suffering ~2x slowdown,
and explain plans with 9.4 master and Heikki's patches is available
here:
http://www.fuzzy.cz/tmp/gin/queries.txt
All the queries have 6 common words, and the
Peter Geoghegan p...@heroku.com writes:
On Wed, Jan 29, 2014 at 8:48 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
method | try1 | try2 | try3 | degrade performance ratio
-
method 1 | 6.546 | 6.558 | 6.638 |
On Thu, Jan 30, 2014 at 2:39 AM, Craig Ringer cr...@2ndquadrant.com wrote:
Earlier discussions seemed to settle on each relation having its own
row-security quals applied independently. So quals on a parent rel did
not cascade down to child rels.
Do you have a link to that prior discussion? I
I wrote:
If I understand this test scenario properly, there are no duplicate
queries, so that each iteration creates a new hashtable entry (possibly
evicting an old one). And it's a single-threaded test, so that there
can be no benefit from reduced locking.
After looking more closely, it's
On Thu, Jan 30, 2014 at 12:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
If I understand this test scenario properly, there are no duplicate
queries, so that each iteration creates a new hashtable entry (possibly
evicting an old one). And it's a single-threaded test, so that there
can
On Wed, Jan 29, 2014 at 3:11 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 14 January 2014 08:38, Christian Kruse christ...@2ndquadrant.com wrote:
Hi,
On 13/01/14 20:06, Heikki Linnakangas wrote:
On 12/17/2013 04:58 PM, Christian Kruse wrote:
attached you will find a patch for showing the
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan and...@dunslane.net wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for the populate functions except for
backwards compatibility on the json side (not jsonb). For non-complex
structures it
Robert Haas robertmh...@gmail.com writes:
One could test it with each pgbench thread starting at a random point
in the same sequence and wrapping at the end.
Well, the real point is that 1 distinct statements all occurring with
exactly the same frequency isn't a realistic scenario: any
BTW ... it occurs to me to wonder if it'd be feasible to keep the
query-texts file mmap'd in each backend, thereby reducing the overhead
to write a new text to about the cost of a memcpy, and eliminating the
read cost in pg_stat_statements() altogether. It's most likely not worth
the trouble; but
On 01/30/2014 12:34 PM, Merlin Moncure wrote:
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan and...@dunslane.net wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for the populate functions except for
backwards compatibility on the json
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
On 01/30/2014 12:34 PM, Merlin Moncure wrote:
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan and...@dunslane.net
wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for the populate functions
Hi.
Now it looks fine for me.
2014-01-28 Dimitri Fontaine dimi...@2ndquadrant.fr:
Hi,
Sergey Muraviov sergey.k.murav...@gmail.com writes:
Now patch applies cleanly and works. :-)
Cool ;-)
But I have some notes:
1. There is an odd underscore character in functions
Christian Kruse wrote:
+Since Gentoo often supports different versions of a package to be
+installed you have to tell the PostgreSQL build environment where the
+Docbook DTD is located:
+programlisting
+cd /path/to/postgresql/sources/doc
+make
On 01/30/2014 01:03 PM, Hannu Krosing wrote:
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
On 01/30/2014 12:34 PM, Merlin Moncure wrote:
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan and...@dunslane.net
wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs
On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
It's always annoyed me that pgindent insists on adjusting vertical
whitespace around #else and related commands. This has, for example,
rendered src/include/storage/barrier.h nigh illegible: you get things
like
/*
* lwsync orders
Bruce Momjian br...@momjian.us writes:
On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
I assert that we should simply remove both of these bits of code, as
just about every committer on the project is smarter about when to use
vertical whitespace than this program is.
OK, I have
On Fri, Aug 9, 2013 at 09:12:03AM -0400, Robert Haas wrote:
On Mon, Aug 5, 2013 at 4:53 PM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Bruce Momjian br...@momjian.us writes:
So do we want to keep that AND in the 9.3beta and 9.4 documentation?
The grammar as in gram.y still allows
Andrew Dunstan and...@dunslane.net writes:
On 01/30/2014 01:03 PM, Hannu Krosing wrote:
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
We'd have to move that code from hstore to jsonb_support.c and then
make hstore refer to it.
Or just copy it and leave hstore alone - the code duplication is
Hello
This patch creates a infrastructure for client side testing environment
1. Surely we want this patch, this infrastructure - lot of important
functionality is not covered by tests - pg_dump, pg_basebackup, ... Without
infrastructure is terrible work to create some tests.
2. This patch does
On Thu, Jan 30, 2014 at 01:46:34PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
I assert that we should simply remove both of these bits of code, as
just about every committer on the project is smarter about when to
On 01/30/2014 01:50 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/30/2014 01:03 PM, Hannu Krosing wrote:
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
We'd have to move that code from hstore to jsonb_support.c and then
make hstore refer to it.
Or just copy it and
On Thu, Jan 23, 2014 at 03:17:35PM +0100, Ronan Dunklau wrote:
- for after triggers, the whole queuing mechanism is bypassed for foreign
tables. This is IMO acceptable, since foreign tables cannot have
constraints or constraints triggers, and thus have not need for
deferrable
2014-01-19 Tom Lane t...@sss.pgh.pa.us:
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
I kind of don't see the point of having IF NOT EXISTS for things that
have OR REPLACE, and am generally in favor of implementing OR REPLACE
rather than IF NOT
On Thu, Jan 30, 2014 at 9:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW ... it occurs to me to wonder if it'd be feasible to keep the
query-texts file mmap'd in each backend, thereby reducing the overhead
to write a new text to about the cost of a memcpy, and eliminating the
read cost in
On 12/22/2013 11:30 PM, Amit Kapila wrote:
I had observed one problem with PGC_BACKEND parameters while testing patch
for ALTER SYSTEM command.
Problem statement: If I change PGC_BACKEND parameters directly in
postgresql.conf and then do pg_reload_conf() and reconnect, it will
On Wed, Jan 29, 2014 at 11:21 PM, Bruce Momjian br...@momjian.us wrote:
On Wed, Jan 29, 2014 at 07:31:29PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have cleaned up entab.c so I am ready to add a new option that removes
tabs from only comments. Would you like me to
Robert Haas escribió:
On Wed, Jan 29, 2014 at 11:21 PM, Bruce Momjian br...@momjian.us wrote:
I compute 6627 lines as modified. What I did not do is handle _only_
cases with periods before the tabs. Should I try that?
I don't have any comment on that specific point, but I took a quick
Andrew Dunstan and...@dunslane.net writes:
On 12/22/2013 11:30 PM, Amit Kapila wrote:
- * backend start.
+ * backend start. However for windows, we need to process
+ * config file during backend start for non-default
parameters,
+
On 01/30/2014 03:12 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 12/22/2013 11:30 PM, Amit Kapila wrote:
- * backend start.
+ * backend start. However for windows, we need to process
+ * config file during backend start for
On Thu, Jan 30, 2014 at 3:04 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas escribió:
On Wed, Jan 29, 2014 at 11:21 PM, Bruce Momjian br...@momjian.us wrote:
I compute 6627 lines as modified. What I did not do is handle _only_
cases with periods before the tabs. Should I
Peter Geoghegan p...@heroku.com writes:
On Thu, Jan 30, 2014 at 9:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW ... it occurs to me to wonder if it'd be feasible to keep the
query-texts file mmap'd in each backend, thereby reducing the overhead
to write a new text to about the cost of a
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribió:
I don't have any comment on that specific point, but I took a quick
look through one of these diffs and it looks like a lot of churn for
no improvement. So I'm not sure what we want to do here, but I don't
think it's this.
On Thu, Jan 30, 2014 at 03:32:27PM -0500, Robert Haas wrote:
Or this:
- mp_int_copy(a, b); /* ok: 0 = r b */
- mp_int_copy(q, a); /* ok: q = a */
+ mp_int_copy(a, b); /* ok: 0 = r b */
+ mp_int_copy(q, a); /* ok: q = a */
I do agree with you some of the changes-after-periods
On Thu, Oct 17, 2013 at 9:11 AM, Vik Fearing vik.fear...@dalibo.com wrote:
On 10/17/2013 02:42 PM, Robert Haas wrote:
On Thu, Oct 17, 2013 at 8:26 AM, Vik Fearing vik.fear...@dalibo.com wrote:
On 10/17/2013 10:03 AM, Fabien COELHO wrote:
My guess is that it won't be committed if there is a
On Thu, Jan 30, 2014 at 3:32 AM, Christian Kruse
christ...@2ndquadrant.com wrote:
For the documentation patch, I propose the attached to avoid future
confusions. Comments? It might make sense to back-patch as well.
Compiles, didn't find any typos and I think it is comprehensible.
I took a
On Thu, Jan 30, 2014 at 12:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In reality, actual applications
could hardly be further from the perfectly uniform distribution of
distinct queries presented here.
Yeah, I made the same point in different words. I think any realistic
comparison of this
On 30 January 2014 17:27, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jan 29, 2014 at 3:11 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 14 January 2014 08:38, Christian Kruse christ...@2ndquadrant.com wrote:
Hi,
On 13/01/14 20:06, Heikki Linnakangas wrote:
On 12/17/2013 04:58 PM,
On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Shigeru Hanada shigeru.han...@gmail.com writes:
At the moment we don't use attstorage for foreign tables, so allowing
SET STORAGE against foreign tables never introduce visible change
except \d+ output of foreign tables. But
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think this is totally misguided. Who's to say that some weird FDW
might not pay attention to attstorage? I could imagine a file-based
FDW using that to decide whether to compress
On Thu, January 30, 2014 20:07, Andrew Dunstan wrote:
Updated patches for both pieces. Included is some tidying done by
[ nested-hstore-9.patch.gz ]
Here is a small doc-patch to Table F-6. hstore Operators
It corrects its booleans in the 'Result' column ( t and f instead of true and
On Thu, January 30, 2014 23:15, Erik Rijkers wrote:
On Thu, January 30, 2014 20:07, Andrew Dunstan wrote:
Updated patches for both pieces. Included is some tidying done by
[ nested-hstore-9.patch.gz ]
Here is a small doc-patch to Table F-6. hstore Operators
It corrects its booleans in
On 1/28/14, 3:59 PM, Rohit Goyal wrote:
The data from IndexTupleData is written to disk, and then read back in
again. Did you initdb a new database cluster after you made your change? If
you did the initdb with the original code, and then tried to point your new
code at the old disk
On more occasions than I care to recall, someone has suggested that it
would be valuable to do something with strxfrm() blobs in order to
have cheaper locale-aware text comparisons. One obvious place to do so
would be in indexes, but in the past that has been dismissed on the
following grounds:
*
Pavel Raiskup prais...@redhat.com writes:
[ 0001-pg_upgrade-make-the-locale-comparison-more-toleratin.patch ]
Committed with minor adjustments (mostly, wordsmithing the comments).
Although this was categorized as a bug fix, I'm not sure it's worth
taking the risk of back-patching. We've not
On Thu, Jan 30, 2014 at 1:07 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/29/2014 04:56 PM, Andrew Dunstan wrote:
On 01/29/2014 01:03 PM, Andrew Dunstan wrote:
On 01/27/2014 10:43 PM, Andrew Dunstan wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of
Peter Geoghegan p...@heroku.com writes:
On more occasions than I care to recall, someone has suggested that it
would be valuable to do something with strxfrm() blobs in order to
have cheaper locale-aware text comparisons. One obvious place to do so
would be in indexes, but in the past that has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/30/2014 10:41 PM, Stephen Frost wrote:
Earlier discussions seemed to settle on each relation having its
own row-security quals applied independently. So quals on a
parent rel did not cascade down to child rels.
This strikes me as a bit
On 01/31/2014 01:18 AM, Robert Haas wrote:
On Thu, Jan 30, 2014 at 2:39 AM, Craig Ringer cr...@2ndquadrant.com wrote:
Earlier discussions seemed to settle on each relation having its own
row-security quals applied independently. So quals on a parent rel did
not cascade down to child rels.
On Thu, Jan 30, 2014 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Quite aside from the index bloat risk, this effect means a 3-4x reduction
in the maximum string length that can be indexed before getting the
dreaded Values larger than 1/3 of a buffer page cannot be indexed error.
Worse, a
On 01/30/2014 07:21 PM, Merlin Moncure wrote:
Something seems off:
postgres=# create type z as (a int, b int[]);
CREATE TYPE
postgres=# create type y as (a int, b z[]);
CREATE TYPE
postgres=# create type x as (a int, b y[]);
CREATE TYPE
-- test a complicated construction
postgres=# select
On Thu, Jan 30, 2014 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think this is totally misguided. Who's to say that some weird FDW
might not pay attention to attstorage? I
On Thursday, January 30, 2014, Craig Ringer cr...@2ndquadrant.com wrote:
This strikes me as a bit odd- isn't this against how we handle the
GRANT system when it comes to inheiritance? That is to say- if
you have access to query the parent, then you'll get rows back from
the child and I
Peter Geoghegan p...@heroku.com writes:
On Thu, Jan 30, 2014 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Quite aside from the index bloat risk, this effect means a 3-4x reduction
in the maximum string length that can be indexed before getting the
dreaded Values larger than 1/3 of a buffer
On Thu, Jan 30, 2014 at 4:45 PM, Peter Geoghegan p...@heroku.com wrote:
So we consider the
appropriateness of a regular strcoll() or a strxfrm() in all contexts
(in a generic and extensible manner, but that's essentially what we
do). I'm not too discouraged by this restriction, because in
On Thu, Jan 30, 2014 at 5:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That's not hard to prevent. If that should happen, we don't go with
the strxfrm() datum. We have a spare IndexTuple bit we could use to
mark when the optimization was applied.
You'd need a bit per column, no?
I don't think
On Thu, Jan 30, 2014 at 4:52 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/30/2014 07:21 PM, Merlin Moncure wrote:
postgres=# select hstore(row(1, array[row(1, array[row(1,
array[1,2])::z])::y])::x);
hstore
On 01/30/2014 09:48 PM, Robert Haas wrote:
On Thu, Oct 17, 2013 at 9:11 AM, Vik Fearing vik.fear...@dalibo.com wrote:
On 10/17/2013 02:42 PM, Robert Haas wrote:
On Thu, Oct 17, 2013 at 8:26 AM, Vik Fearing vik.fear...@dalibo.com wrote:
On 10/17/2013 10:03 AM, Fabien COELHO wrote:
My guess is
On 01/23/2014 11:22 PM, Emre Hasegeli wrote:
inet-gist
-
I realized that create extension btree_gist fails with the patch.
ERROR: could not make operator class gist_inet_ops be default for type inet
DETAIL: Operator class inet_ops already is the default.
I think making the new
On Thu, Jan 30, 2014 at 3:49 PM, Peter Geoghegan p...@heroku.com wrote:
So ISTM that we could come up with an infrastructure, possibly just
for insertion scanKeys (limiting the code footprint of all of this) in
order to inner-page-process datums at this juncture, and store a blob
instead, for
On 01/31/2014 09:01 AM, Stephen Frost wrote:
I don't see where this follows at all- clearly, you already get a subset
of rows from the child than if you queried the parent because there are
other children.
Er, what? I don't see what you're saying here.
Currently, when you query the parent,
On 1/20/14, 8:08 PM, Alvaro Herrera wrote:
Peter Eisentraut escribió:
src/backend/postmaster/postmaster.c:2255: indent with spaces.
+else
src/backend/postmaster/postmaster.c:2267: indent with spaces.
+break;
I just checked the Jenkins page for this patch:
(2014/01/28 22:01), Etsuro Fujita wrote:
(2014/01/27 21:49), Shigeru Hanada wrote:
Is it too big change that making ANALYZE command to handle foreign
tables too even if no table name was specified? IIRC, performance
issue was the reason to exclude foreign tables from auto-analyze
processing.
Hello everyone,
My name is Anirudh Subramanian and I am a graduate student in Computer
Science. I would like to participate in Google Summer of Code and would
like to contribute to postgresql. I am not familiar with the postgresql
codebase yet but will surely get started in the near future. Right
Hi Anirudh,
On Fri, Jan 31, 2014 at 12:23 PM, Anirudh anirudh2...@gmail.com wrote:
Hello everyone,
My name is Anirudh Subramanian and I am a graduate student in Computer
Science. I would like to participate in Google Summer of Code and would like
to contribute to postgresql. I am not
On Thu, Jan 30, 2014 at 01:52:55PM -0500, Bruce Momjian wrote:
On Thu, Jan 30, 2014 at 01:46:34PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
I assert that we should simply remove both of these bits of code, as
On Fri, Jan 31, 2014 at 2:01 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/30/2014 03:12 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 12/22/2013 11:30 PM, Amit Kapila wrote:
- * backend start.
+ * backend start. However for
1 - 100 of 109 matches
Mail list logo
