Hi,
The attached documentation patch further describes the
additive nature of the permission system.
This patch makes some sweeping statements. It needs
review by someone who knows whats in all the corners.
(I'm sure this would happen anyway, but it seems worth
mentioning.)
Paragraph structu
On 09/28/2012 10:34 PM, Misa Simic wrote:
Hi Guys,
I have made some blog about the subject:
http://misasimic.blogspot.co.uk/2012/09/postgresql-92-and-json-datatype.html
Hopefully will help on some kind...
I think if you want to contribute you should post on the mailing list -
otherwise t
Hi Guys,
I have made some blog about the subject:
http://misasimic.blogspot.co.uk/2012/09/postgresql-92-and-json-datatype.html
Hopefully will help on some kind...
Kind Regards,
Misa
On 9/28/12 5:13 PM, Tom Lane wrote:
> We could probably eliminate that inconsistency by insisting that two
> clauses can only be matched for this purpose when they reference the
> same set of rels overall, but that doesn't feel right --- it certainly
> seems like the example above ought to be thoug
> Add [ds]list's which can be used to embed lists in bigger data structures
> without additional memory management
> Alvaro, Andres, Review by Peter G. and Tom
This is missing Robert. Sorry for that.
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Develop
On Saturday, September 29, 2012 01:54:37 AM Tom Lane wrote:
> Andres Freund writes:
> > On Saturday, September 29, 2012 01:39:03 AM Tom Lane wrote:
> >> Right offhand it doesn't seem like it really gains that much even for
> >> that use-case. You'd end up editing the include file either way, just
Josh Berkus writes:
>> I'm thinking that this is overly restrictive, and we could usefully
>> suppose that "var >= anything" and "var <= anything" should be treated
>> as a range constraint pair if the vars match and there are no volatile
>> functions in the expressions. We are only trying to get
Andres Freund writes:
> On Saturday, September 29, 2012 01:39:03 AM Tom Lane wrote:
>> Right offhand it doesn't seem like it really gains that much even for
>> that use-case. You'd end up editing the include file either way, just
>> slightly differently.
> Well, with USE_INLINE you have to recom
> I'm thinking that this is overly restrictive, and we could usefully
> suppose that "var >= anything" and "var <= anything" should be treated
> as a range constraint pair if the vars match and there are no volatile
> functions in the expressions. We are only trying to get a selectivity
> estimat
On Saturday, September 29, 2012 01:39:03 AM Tom Lane wrote:
> Andres Freund writes:
> > The reason I had the header declare DEFINE_ILIST_FUNCTIONS (or rather
> > ILIST_USE_DEFINITION back then) instead of reusing USE_INLINE directly is
> > that it makes it easier to locally change a "module" to no
Andres Freund writes:
> The reason I had the header declare DEFINE_ILIST_FUNCTIONS (or rather
> ILIST_USE_DEFINITION back then) instead of reusing USE_INLINE directly is
> that
> it makes it easier to locally change a "module" to not inlining which makes
> testing the !USE_INLINE case easier.
Over in pgsql-performance, Shaun Thomas was just complaining about the
planner not picking a bitmap indexscan for a query involving a
constraint like
b.created_dt between a.created_dt
and a.created_dt + interval '1 month';
At first I wrote this off as being due to inability to ge
On Friday, September 14, 2012 10:57:54 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > One thing I would like more input in, is whether people think it's
> > worthwhile to split dlists and slists into separate files. Thus far
> > this has been mentioned by three people independently.
>
> They're
Andrew Dunstan writes:
> I just noticed this code in win32.h and cygwin.h:
> #if __GNUC__ && ! defined (__declspec)
> #error You need egcs 1.1 or newer for compiling!
> #endif
> EGCS was merged back into gcc with the 2.95 release in 1999, according
> to Wikipedia, So perhaps we shoul
Excerpts from Kohei KaiGai's message of lun sep 10 08:08:32 -0300 2012:
> As attached, I split off the original one into three portions; for set-schema,
> set-owner and rename-to. Please apply them in order of patch filename.
Hmm, in the first patch, it seems to me we can simplify
AlterObjectName
Excerpts from Dimitri Fontaine's message of vie sep 28 17:36:41 -0300 2012:
> Dimitri Fontaine writes:
> > Please find attached a patch that fixes it in 9.1, in all classic
> > pg_dump, --data-only and --schema-only.
>
> Same for 9.2, attached. master needs yet another patch because of the
> rece
Dimitri Fontaine writes:
> Please find attached a patch that fixes it in 9.1, in all classic
> pg_dump, --data-only and --schema-only.
Same for 9.2, attached. master needs yet another patch because of the
recent headers reorg, it seems, that's for another day though.
Regards,
--
Dimitri Fontain
I just noticed this code in win32.h and cygwin.h:
#if __GNUC__ && ! defined (__declspec)
#error You need egcs 1.1 or newer for compiling!
#endif
EGCS was merged back into gcc with the 2.95 release in 1999, according
to Wikipedia, So perhaps we should just remove these ancient relics,
Brian Weaver writes:
> Here's a very minimal fix then, perhaps it will be more palatable.
I did some further work on this to improve comments and clean up the
pg_dump end of things, and have committed it.
> Even though I regret the effort I put into the first patch it's in my
> employer's best i
Marko Kreen writes:
> Indeed, after another makefile reorg, I could not reproduce it
> on skytools master either, some digging showed that due
> to a makefile bug ($< instead $^) the ADD SCHEMA
> was missing from .sql file. So no bug in postgres.
That would explain, indeed :)
> Could you test i
On Fri, Sep 28, 2012 at 12:58 AM, Heikki Linnakangas
wrote:
> Hmm, I cannot reproduce this on my Linux laptop. However, I think I see what
> the problem is: the assertion should assert that (*CurrPos* % XLOG_BLCKZ >=
> SizeOfXLogShortPHD), not currpos. The former is an XLogRecPtr, the latter is
>
Hi,
The attached patch (against git head)
normalizes "search_path" as the thing indexed
and uses a secondary index term to distinguish
the configuration parameter from the run-time
setting.
"search path" the concept remains distinguished
in the index from "search_path" the setting/config param.
I
On 09/28/2012 11:28:39 AM, Karl O. Pinc wrote:
> Doc patch, index search_path where it's used to secure functions.
> search_path-securing.patch
Second version. Should be indexing the concept, not the run-time
setting.
Karl
Free Software: "You don't pay back, you pay forward."
Hi,
Doc patch, index search_path where it's used to secure functions.
search_path-securing.patch
Against git head. (As are the previous doc patches.)
Karl
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
diff --git a/doc/src/sgml/ref/create_functio
Hi,
2 patches:
pg_temp-toindex.patch
Puts pg_temp into the index of the docs.
(Line lengths are ugly so the change can
be easily reviewed.)
pg_temp-reformat.patch
Reformats the doc source after the
above patch. (Fixes line length.)
Regards,
Karl
Free Software: "You don't pay back, you pay f
Excerpts from Kohei KaiGai's message of jue sep 27 01:01:18 -0300 2012:
> * I have a question. What is the meaning of INT64_IS_BUSTED?
> It seems to me a marker to indicate a platform without 64bit support.
> However, the commit 901be0fad4034c9cf8a3588fd6cf2ece82e4b8ce
> says as follows:
>
Peter Eisentraut writes:
> Example:
> create temporary table foo (a int);
> insert into foo values (1);
> alter role peter set temp_buffers = 120;
> ERROR: 22023: invalid value for parameter "temp_buffers": 120
> DETAIL: "temp_buffers" cannot be changed after any temporary tables
> have been acc
On Wed, Sep 26, 2012 at 7:15 PM, Dimitri Fontaine
wrote:
> Marko Kreen writes:
>>> Can we work out a minimal example to reproduce the bug?
>>
>> Yes, the above text or sql/pgq_coop/sql/pgq_coop_init_ext.sql
>>
>> I guess you could replace pgq_coop with any extension just
>> consisting of just fun
> On Tuesday, September 25, 2012 6:29 PM Heikki Linnakangas wrote:
> On 25.09.2012 10:08, Heikki Linnakangas wrote:
> > On 24.09.2012 16:33, Amit Kapila wrote:
> >> In any case, it will be better if you can split it into multiple
> patches:
> >> 1. Having new functionality of "Switching timeline ov
On 09/28/2012 08:22 AM, Peter Eisentraut wrote:
(3) Invent an auxiliary type along the lines of "json_value" and say
that you create a cast from foo to json_value when you want one
interpretation, or directly to json if you want the other. Then
things like record_to_json would look for the appr
On 9/27/12 10:36 AM, Tom Lane wrote:
> (1) Reject Robert's assumption that we have to support both
> interpretations for every cast situation. For instance, it doesn't
> seem that unreasonable to me to insist that you have to cast to text
> and then to json if you want the literal-reinterpretation
On 09/28/2012 12:42 AM, Andrew Dunstan wrote:
On 09/27/2012 06:58 PM, Hannu Krosing wrote:
On 09/27/2012 09:18 PM, Andrew Dunstan wrote:
On 09/27/2012 10:36 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2012 09:22 AM, Robert Haas wrote:
Maybe I am being too pedantic about this and th
32 matches
Mail list logo
