On Jul 16, 2009, at 12:49 PM, Andrew Dunstan wrote:
I'm using jQuery to pull the proper doc into a div. I'm still
noodling with it, trying to fix encoding issues on Windows, but
it's pretty close to done.
Yes, that's nice, it's just the sort of thing I had in mind - if you
can do it with
On Jul 16, 2009, at 7:17 AM, Andrew Gierth wrote:
Revision to previous hstore patch to fix (and add tests for) some edge
case bugs with nulls or empty arrays.
This looks great, Andrew, thanks. Here's what I did to try it out:
* I built a simple database with a table with an (old) hstore colum
Robert,
BTW, the new commitfest software is great. Easily a 75% reduction in
time required to track reviewing activity.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
Robert Haas wrote:
> 2009/7/16 KaiGai Kohei :
>> Yes, the tiny version will not give any advantages in security without
>> future enhancements.
>> It is not difficult to add object classes and permissions.
>> If necessary, I'll add checks them with corresponding permissions.
>>
>> One anxiety is Po
Hello
look on:
postgres=# explain select count(*) over () from x;
QUERY PLAN
-
WindowAgg (cost=0.00..265.00 rows=1 width=0)
-> Seq Scan on x (cost=0.00..140.00 rows=1 width=0)
(2 rows)
Time: 1,473
Josh Berkus wrote:
> On 7/16/09 12:53 PM, Robert Haas wrote:
> > I think perhaps we should ask the patch author to remove the NOT NULL
> > stuff first?
>
> Yes, current status is "Waiting on Author".
OK, I removed "FORCE NOT NULL" stuff from the patch.
The attached patch only adds "FORCE QUOTE *
2009/7/16 KaiGai Kohei :
> Yes, the tiny version will not give any advantages in security without
> future enhancements.
> It is not difficult to add object classes and permissions.
> If necessary, I'll add checks them with corresponding permissions.
>
> One anxiety is PostgreSQL specific object cl
Robert Haas wrote:
> 2009/7/16 KaiGai Kohei :
>> Updated SE-PgSQL patch is here:
>>
>> http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2196.patch.gz
>>
>> Unused definitions of SELinux's permissions are ripped out from
>> the permission table.
>
> OK, I'm looking at this version of
On Tue, Jul 14, 2009 at 5:33 PM, Stefan
Kaltenbrunner wrote:
>> If you have time, that would be great; if not I will do it.
>
> well you just volunteered...
I was trying hard not to.
But, done.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
Rebased to correct for pg_indent changes.
Applies cleanly.
Compiles cleanly.
Passes regression tests.
Comments and format look good.
No documentation changes needed.
No regression test changes needed.
Performance tests to follow in a day or two.
-Kevin
Index: src/bin/pg_dump/pg_backup_archive
On Thu, Jul 16, 2009 at 9:02 PM, Greg Stark wrote:
> I started looking at this patch and it looks pretty good as far as it
> goes. But I think we can do a lot more. It seems to me the cases where
> foreign key relationships exist are likely to be really big use cases.
I agree. But that seems a lo
2009/7/16 KaiGai Kohei :
> Updated SE-PgSQL patch is here:
>
> http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2196.patch.gz
>
> Unused definitions of SELinux's permissions are ripped out from
> the permission table.
OK, I'm looking at this version of the patch, and my first reactio
I summarized the design proposal and issues currently we have.
I would like to see any comments corresponding to the proposition.
Especially, selection of the snapshot is a headach issue for me.
This project tries to solve two items listed at:
http://wiki.postgresql.org/wiki/To
I started looking at this patch and it looks pretty good as far as it
goes. But I think we can do a lot more. It seems to me the cases where
foreign key relationships exist are likely to be really big use cases.
I have one big worry though. Currently you're detecting the unique
property using the
Brendan Jurd wrote:
app-text/openjade 1.3.2-r1
app-text/docbook-sgml 1.0
app-text/docbook-sgml-dtd 4.2-r2
app-text/docbook-sgml-utils 0.6.14
app-text/docbook-dsssl-stylesheets 1.79
... plus some other packages which were pulled in to satisfy
dependencies on the above.
The version is only a b
Brendan Jurd wrote:
> The only trick was working out exactly which
> packages I needed to install.
Which were?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas escribió:
> But I can't say I've ever had much trouble building the docs. I find
> it a bit odd that "make" in the doc directory does nothing; and "make"
> in doc/src does nothing, but "make" in doc/src/sgml does what you
> expect. I also find the slowness of openjade to be pretty an
2009/7/17 Kevin Grittner :
> Brendan Jurd wrote:
>
>> The only trick was working out exactly which
>> packages I needed to install.
>
> Which were?
>
Currently I have:
app-text/openjade 1.3.2-r1
app-text/docbook-sgml 1.0
app-text/docbook-sgml-dtd 4.2-r2
app-text/docbook-sgml-utils 0.6.14
app-tex
On Thu, Jul 16, 2009 at 8:07 PM, Brendan Jurd wrote:
> 2009/7/17 Josh Berkus :
>> This seems like a serious issue for development. Reviewers, how many of you
>> are able to build docs with each patch?
>
> Being able to build docs did require some fidgeting with the docbook
> packages (on Gentoo).
On Fri, 2009-07-17 at 09:51 +1000, Brendan Jurd wrote:
> I like that idea ... although how would this interact (if at all) with
> the existing pg_index.isunique flag? Would it become deprecated in
> favour of using indconstrats, or would you actually look at switching
> isunique to TRUE if somebod
Robert Haas wrote:
> 2009/7/16 KaiGai Kohei :
>> However, I don't think the initial proposal of the largeobject
>> security is now on the state to be reviewed seriously.
>
> OK, I am moving this patch to returned with feedback.
If possible, I would like to have a discussion to make consensus
abou
2009/7/17 Josh Berkus :
> This seems like a serious issue for development. Reviewers, how many of you
> are able to build docs with each patch?
Being able to build docs did require some fidgeting with the docbook
packages (on Gentoo). The only trick was working out exactly which
packages I neede
2009/7/17 Jeff Davis :
> Another idea that I thought about is that:
>
> ALTER TABLE foo ADD UNIQUE (a, b) USING foo_idx;
>
> could be a shorthand for:
>
> ALTER TABLE foo ADD INDEX CONSTRAINT (a =, b =) USING foo_idx;
>
> The benefit is that it could go over GiST indexes or hash indexes, not
>
Tom Lane wrote:
Greg Smith writes:
On Thu, 16 Jul 2009, Josh Berkus wrote:
Well, after an hour of tinkering with docbook DTDs and openjade I've given up
on building docs for the patch I was reviewing on my Mac.
It's easier to get the whole chain working under Linux, but e
Greg Smith writes:
> On Thu, 16 Jul 2009, Josh Berkus wrote:
>> Well, after an hour of tinkering with docbook DTDs and openjade I've given
>> up
>> on building docs for the patch I was reviewing on my Mac.
> It's easier to get the whole chain working under Linux, but even that
> isn't trivial.
"Kevin Grittner" writes:
> ...
> We were able to get to much cleaner code by rewriting the parser to
> have a "dumb" phase to get the overall structure into an AST, and then
> use a tree-walker phase to do all the lookups and type resolution
> after we had the rough structure, writing another AST
Tom Lane wrote:
> One problem that wasn't obvious when I started is that if you are
> trying to use a reentrant lexer, Bison insists on including its
> YYSTYPE union in the call signature of the lexer. Of course,
> YYSTYPE means different things to the core grammar and plpgsql's
> grammar. I
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Bernd Helmle
> Sent: Thursday, July 16, 2009 8:47 AM
> To: Grzegorz Jaskiewicz
> Cc: pgsql-hackers Hackers
> Subject: Re: [HACKERS] boolean in C
>
> --On 16. Juli 200
--On 16. Juli 2009 13:32:03 +0100 Grzegorz Jaskiewicz
wrote:
oh, another thing.
stdbool is C99 standard feature. Not gcc extension.
There might be compiler versions out there which claims to be C99 but do
not provide full compliant include headers. SUN Studio 12 at least has the
followi
On Thursday 16 July 2009 23:04:58 Tom Lane wrote:
> Andres Freund writes:
> > Query planning via GEQO currently can yield a different plan on every
> > invokation of the planner due to its non-exhaustive nature.
> > This often can be inconvenient because at times there may be a very
> > bad plan.
On Thu, Jul 16, 2009 at 2:57 AM, Jaime
Casanova wrote:
> Hi,
>
> I'm reviewing this patch:
> http://archives.postgresql.org/message-id/3f0b79eb0907022341m1d36a841x19c3e2a5a6906...@mail.gmail.com
Another thing that took my attention, i don't think this is safe (it
assumes only one auxiliary process
Merlin Moncure escreveu:
> Isn't it possible though to write and/or review the documentation
> patch without building it?
>
cd pgsql/doc/src/sgml && gmake check
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Andres Freund writes:
> Query planning via GEQO currently can yield a different plan on every
> invokation of the planner due to its non-exhaustive nature.
> This often can be inconvenient because at times there may be a very
> bad plan. It also makes it very hard to reproduce a problem with GEQO.
Chris Spotts wrote:
As for importing data from programs that produce all values in quotes
including null/missing values (your pro case above), arguably what we
need is another flag that would turn an empty string into a null.
h, TODO, please? There's a lot of this out there, and I've ha
On Thu, 16 Jul 2009, Josh Berkus wrote:
Well, after an hour of tinkering with docbook DTDs and openjade I've given up
on building docs for the patch I was reviewing on my Mac.
It's easier to get the whole chain working under Linux, but even that
isn't trivial. I think one useful step here wo
On Thursday 07 May 2009 05:23:41 Dickson S. Guedes wrote:
> This is a WIP patch (for the TODO item in the subject) that I'm putting
> in the Commit Fest queue for 8.5.
The problem I'm seeing with this is that currently it resolves
%v (client) = 8.5devel
%V (server) = 8.5.0
Besides being inconsis
Josh Berkus wrote:
Andrew,
AFAICT on a brief look at the patch, it doesn't affect the quoting of
nulls on export, it just allows * as an alias for all columns for FORCE
QUOTE (as well as FORCE NOT NULL). But FORCE QUOTE has never forced
quoting of null values, only non-null values. We have neve
On Thu, Jul 16, 2009 at 2:34 PM, Josh Berkus wrote:
> All,
>
> Well, after an hour of tinkering with docbook DTDs and openjade I've given
> up on building docs for the patch I was reviewing on my Mac.
>
> If I'm encountering this difficulty building docs, so are many of the other
> new patch review
Andrew,
AFAICT on a brief look at the patch, it doesn't affect the quoting of
nulls on export, it just allows * as an alias for all columns for FORCE
QUOTE (as well as FORCE NOT NULL). But FORCE QUOTE has never forced
quoting of null values, only non-null values. We have never quoted null
values
On Thu, Jul 16, 2009 at 06:49:08PM +0200, Andres Freund wrote:
> On Thursday 16 July 2009 17:59:58 Tom Lane wrote:
> > Andres Freund writes:
> > > The default settings currently make it relatively hard to trigger geqo at
> > > all.
> >
> > Yes, and that was intentional. One of the implications of
Kevin Grittner wrote:
> We would probably want to modify psql, pg_dump, etc. to put the
> application name into this connection property, at least by default.
> We may want to add a command-line switch to allow user override -- to
> provide something more detailed. For example,
> --application-na
On 7/16/09 12:53 PM, Robert Haas wrote:
On Thu, Jul 16, 2009 at 2:47 PM, Josh Berkus wrote:
Unless there are other things we want to test (CLOBs?) I think the patch is
probably ready for code review of the FORCE QUOTE * portion.
I think perhaps we should ask the patch author to remove the NOT
Greg Stark wrote:
> Kevin Grittner wrote:
>> On the admin list there was a request for an application name
>> column in pg_stat_activity.
>>
>> http://archives.postgresql.org/pgsql-admin/2009-07/msg00095.php
>>
>> This is available in a lot of other DBMS products, can be useful to
>> DBAs, and see
On Thu, Jul 16, 2009 at 2:47 PM, Josh Berkus wrote:
> Unless there are other things we want to test (CLOBs?) I think the patch is
> probably ready for code review of the FORCE QUOTE * portion.
I think perhaps we should ask the patch author to remove the NOT NULL
stuff first?
...Robert
--
Sent v
David E. Wheeler wrote:
On Jul 14, 2009, at 3:21 PM, Andrew Dunstan wrote:
Yes, really. What you suggest here is just not adequate, IMNSHO. I
don't want to have to scroll to the top or bottom of the page to get
navigation, and I want to be able to see the navigation and go where
I want dire
On Thu, Jul 16, 2009 at 1:09 PM, Greg Stark wrote:
> On Thu, Jul 16, 2009 at 4:41 PM, Heikki
> Linnakangas wrote:
>> Rick Gigger wrote:
>>> If you use an rsync like algorithm for doing the base backups wouldn't
>>> that increase the size of the database for which it would still be
>>> practical to
On Thu, Jul 16, 2009 at 8:08 PM, Kevin
Grittner wrote:
> On the admin list there was a request for an application name
> column in pg_stat_activity.
>
> http://archives.postgresql.org/pgsql-admin/2009-07/msg00095.php
>
> This is available in a lot of other DBMS products, can be useful to
> DBAs, an
Jaime Casanova wrote:
> Kevin Grittner wrote:
>> On the admin list there was a request for an application name
>> column in pg_stat_activity.
> ah? how do you implement that? and what's the use case for?
It would be passed as a connection property. (If that's not feasible,
perhaps a session
Josh Berkus wrote:
Andrew,
FORCE NOT NULL is in any case a fairly blunt instrument - it doesn't
work for a column of any type that doesn't accept an empty string as
valid input, such as numeric types.
Con: this allows COPY to produce output which cannot be reloaded into
PostgreSQL.
Pro:
On Jul 16, 2009, at 11:09 AM, Greg Stark wrote:
On Thu, Jul 16, 2009 at 4:41 PM, Heikki
Linnakangas wrote:
Rick Gigger wrote:
If you use an rsync like algorithm for doing the base backups
wouldn't
that increase the size of the database for which it would still be
practical to just re-sync?
On Jul 14, 2009, at 3:21 PM, Andrew Dunstan wrote:
Yes, really. What you suggest here is just not adequate, IMNSHO. I
don't want to have to scroll to the top or bottom of the page to get
navigation, and I want to be able to see the navigation and go where
I want directly.
Hey Andrew,
Che
On Thu, Jul 16, 2009 at 2:08 PM, Kevin
Grittner wrote:
> On the admin list there was a request for an application name
> column in pg_stat_activity.
>
> http://archives.postgresql.org/pgsql-admin/2009-07/msg00095.php
>
> This is available in a lot of other DBMS products, can be useful to
> DBAs, an
On the admin list there was a request for an application name
column in pg_stat_activity.
http://archives.postgresql.org/pgsql-admin/2009-07/msg00095.php
This is available in a lot of other DBMS products, can be useful to
DBAs, and seems pretty cheap and easy. Could we get that onto the
TODO l
Andrew,
FORCE NOT NULL is in any case a fairly blunt instrument - it doesn't
work for a column of any type that doesn't accept an empty string as
valid input, such as numeric types.
Con: this allows COPY to produce output which cannot be reloaded into
PostgreSQL.
Pro: there is a lot of extr
Peter Eisentraut wrote:
> On Thursday 16 July 2009 07:09:22 Bruce Momjian wrote:
> > Uh, how is this going to behave in 8.5? Do we still dump sequences, and
> > if so, aren't we heading down the road of dumping stuff only because a
> > previous release needed it?
>
> Which leads me to a related q
All,
1) Patch applies cleanly against CVS head.
2) Patch compiles and builds cleanly.
3) Unable to check docs because of general doc build problems.
4) Tested the following commands, using a 10MB table of PostgreSQL log data:
postgres=# COPY marchlog TO '/tmp/marchlog1.csv' with csv header;
C
All,
Well, after an hour of tinkering with docbook DTDs and openjade I've
given up on building docs for the patch I was reviewing on my Mac.
If I'm encountering this difficulty building docs, so are many of the
other new patch reviewers. Which means we're *not* reviewing docs for
completene
Sorry about that. Here it is again as an attachment.
-Caleb
On 7/16/09 7:16 AM, "Peter Eisentraut" wrote:
On Wednesday 27 May 2009 02:07:33 Caleb Welton wrote:
> Patch for plpythonu
This patch doesn't apply; I think it got mangled during email transport.
(Tabs changed to spaces, it looks lik
2009/7/16 KaiGai Kohei :
> However, I don't think the initial proposal of the largeobject
> security is now on the state to be reviewed seriously.
OK, I am moving this patch to returned with feedback.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On Thursday 16 July 2009 19:22:30 Robert Haas wrote:
> On Thu, Jul 16, 2009 at 11:32 AM, Tom Lane wrote:
> > I wrote:
> >> If I set both collapse_limit variables to very high values (I used 999),
> >> it takes ... um ... not sure; I gave up waiting after half an hour.
> >> I also tried with geqo_ef
Robert Haas writes:
> On Thu, Jul 16, 2009 at 11:32 AM, Tom Lane wrote:
>> So maybe a redesign of the equivalence-class joinclause mechanism is in
>> order. Still, this is unlikely to fix the fundamental issue that the
>> time for large join problems grows nonlinearly.
> Nonlinear is one thing,
On Thursday 16 July 2009 19:13:55 Robert Haas wrote:
> On Thu, Jul 16, 2009 at 12:49 PM, Andres Freund wrote:
> > On Thursday 16 July 2009 17:59:58 Tom Lane wrote:
> >> Andres Freund writes:
> >> > The default settings currently make it relatively hard to trigger geqo
> >> > at all.
> >>
> >> Yes,
On Thu, Jul 16, 2009 at 11:32 AM, Tom Lane wrote:
> I wrote:
>> If I set both collapse_limit variables to very high values (I used 999),
>> it takes ... um ... not sure; I gave up waiting after half an hour.
>> I also tried with geqo_effort reduced to the minimum of 1, but that
>> didn't produce a
On Thu, 2009-07-16 at 15:22 +1000, Brendan Jurd wrote:
> I had a play around with the feature in psql. I think the syntax is
> okay, but using "ALTER TABLE ... ADD" as you mentioned upthread could
> be a better option.
Ok, I think we're pretty much settled on that option then.
Another idea that
On Thu, Jul 16, 2009 at 12:49 PM, Andres Freund wrote:
> On Thursday 16 July 2009 17:59:58 Tom Lane wrote:
>> Andres Freund writes:
>> > The default settings currently make it relatively hard to trigger geqo at
>> > all.
>>
>> Yes, and that was intentional. One of the implications of what we're
>
On Thu, Jul 16, 2009 at 4:41 PM, Heikki
Linnakangas wrote:
> Rick Gigger wrote:
>> If you use an rsync like algorithm for doing the base backups wouldn't
>> that increase the size of the database for which it would still be
>> practical to just re-sync? Couldn't you in fact sync a very large
>> da
On Thursday 16 July 2009 17:59:58 Tom Lane wrote:
> Andres Freund writes:
> > The default settings currently make it relatively hard to trigger geqo at
> > all.
>
> Yes, and that was intentional. One of the implications of what we're
> discussing here is that geqo would get used a lot more for "t
On Thursday 16 July 2009 18:23:06 Tom Lane wrote:
> Andres Freund writes:
> > On Thursday 16 July 2009 17:16:31 Tom Lane wrote:
> >> I tried the example query and couldn't get "Failed to make a valid plan"
> >> out of it ... what settings do you need for that?
> >
> > It unfortunately depends on s
Andres Freund writes:
> On Thursday 16 July 2009 17:16:31 Tom Lane wrote:
>> I tried the example query and couldn't get "Failed to make a valid plan"
>> out of it ... what settings do you need for that?
> It unfortunately depends on settings and luck. This dependence on luck was
> the
> reason
2009/7/16 Hitoshi Harada :
> 2009/7/16 Greg Stark :
>> On Wed, Jul 15, 2009 at 11:18 AM, Pavel Stehule
>> wrote:
>>> postgres=# select avg(a) from (select a, row_number() over (order by
>>> a) as r, count(*) over () as rc from x ) p where r in
>>> ((rc+1)/2,(rc+2)/2) ;
>>
>> How does this compare
Andres Freund writes:
> The default settings currently make it relatively hard to trigger geqo at all.
Yes, and that was intentional. One of the implications of what we're
discussing here is that geqo would get used a lot more for "typical
complex queries" (if there is any such thing as a typica
On Thursday 16 July 2009 17:27:39 Greg Stark wrote:
> On Thu, Jul 16, 2009 at 4:16 PM, Tom Lane wrote:
> > However, I do observe that this seems a sufficient counterexample
> > against the theory that we can just remove the collapse limits and let
> > GEQO save us on very complex queries. On my ma
Greg Stark writes:
> On Thu, Jul 16, 2009 at 4:32 PM, Tom Lane wrote:
>> So maybe a redesign of the equivalence-class joinclause mechanism is in
>> order. Still, this is unlikely to fix the fundamental issue that the
>> time for large join problems grows nonlinearly.
> Perhaps it's GEQO's fault
Rick Gigger wrote:
> If you use an rsync like algorithm for doing the base backups wouldn't
> that increase the size of the database for which it would still be
> practical to just re-sync? Couldn't you in fact sync a very large
> database if the amount of actual change in the files was a small
>
On Thu, Jul 16, 2009 at 4:32 PM, Tom Lane wrote:
> samples % image name symbol name
> 886498 53.8090 postgres have_relevant_eclass_joinclause
> 460596 27.9574 postgres bms_overlap
>
> So maybe a redesign of the equivalence-class joinclause
On Thursday 16 July 2009 17:16:31 Tom Lane wrote:
> Andres Freund writes:
> > On Thursday 16 July 2009 15:13:02 Tom Lane wrote:
> >> Andres Freund writes:
> >>> "Error: Failed to make a valid plan"
> >>
> >> We're not going to be able to fix this unless you show us examples.
> >
> > In the other
Grzegorz Jaskiewicz writes:
> On 16 Jul 2009, at 15:17, Tom Lane wrote:
>> That's hardly going to improve readability for anyone. Also, it will
>> flat out not work for the catalog struct declarations. When we say
>> "bool relhasindex;" the compiler had better think that that's a
>> one-byte fie
On Thu, Jul 16, 2009 at 04:27:39PM +0100, Greg Stark wrote:
> On Thu, Jul 16, 2009 at 4:16 PM, Tom Lane wrote:
> > However, I do observe that this seems a sufficient counterexample
> > against the theory that we can just remove the collapse limits and let
> > GEQO save us on very complex queries. ?
I wrote:
> If I set both collapse_limit variables to very high values (I used 999),
> it takes ... um ... not sure; I gave up waiting after half an hour.
> I also tried with geqo_effort reduced to the minimum of 1, but that
> didn't produce a plan in reasonable time either (I gave up after ten
> mi
Grzegorz Jaskiewicz píše v čt 16. 07. 2009 v 14:59 +0100:
> >
> >> Why C89, and not C99 ? Virtually all compilers for last 4 years have/
> >> had C99 support.
> >
> > Well, I think we want to run on systems that are older than 4 years,
> > too.
>
>
> Sure, but that's probably less than 1% of
On Thu, Jul 16, 2009 at 4:16 PM, Tom Lane wrote:
> However, I do observe that this seems a sufficient counterexample
> against the theory that we can just remove the collapse limits and let
> GEQO save us on very complex queries. On my machine, the example query
> takes about 22 seconds to plan us
Andres Freund writes:
> On Thursday 16 July 2009 15:13:02 Tom Lane wrote:
>> Andres Freund writes:
>>> "Error: Failed to make a valid plan"
>> We're not going to be able to fix this unless you show us examples.
> In the other thread I attached a similar to the real schema + example query.
> No
On 16 Jul 2009, at 15:17, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
That's hardly going to improve readability for anyone. Also, it will
flat out not work for the catalog struct declarations. When we say
"bool relhasindex;" the compiler had better think that that's a
one-byte field.
Sur
On Thursday 16 July 2009 17:00:03 Robert Haas wrote:
> On Mon, Jul 13, 2009 at 5:51 PM, Peter Eisentraut wrote:
> > So I think either decoration is added to all of these files or none of
> > them. And I think the former is not going to go over well.
>
> We do have some things that are conditioned o
Grzegorz Jaskiewicz writes:
> On 16 Jul 2009, at 14:53, Peter Eisentraut wrote:
the standard does not promise that type _Bool has size = 1 byte.
We have to have that because of on-disk compatibility requirements.
>>> I think the latter is easily fixable, or forceable to be one byte.
>>
Revision to previous hstore patch to fix (and add tests for) some edge
case bugs with nulls or empty arrays.
--
Andrew (irc:RhodiumToad)
hstore_20090716.patch.gz
Description: hstore patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On Wednesday 27 May 2009 02:07:33 Caleb Welton wrote:
> Patch for plpythonu
This patch doesn't apply; I think it got mangled during email transport.
(Tabs changed to spaces, it looks like.) Could you resend the patch as a
separate attachment in a way that it doesn't get mangled?
--
Sent via
On Mon, Jul 13, 2009 at 5:51 PM, Peter Eisentraut wrote:
> So I think either decoration is added to all of these files or none of them.
> And I think the former is not going to go over well.
We do have some things that are conditioned on __cplusplus already,
such as "c.h", "pg_config.h.in", and "p
On 16 Jul 2009, at 14:53, Peter Eisentraut wrote:
On Thursday 16 July 2009 16:23:31 Grzegorz Jaskiewicz wrote:
On 16 Jul 2009, at 14:20, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
oh, another thing.
stdbool is C99 standard feature.
We are still targeting C89, not C99.
Another reason not
On Thursday 16 July 2009 16:23:31 Grzegorz Jaskiewicz wrote:
> On 16 Jul 2009, at 14:20, Tom Lane wrote:
> > Grzegorz Jaskiewicz writes:
> >> oh, another thing.
> >> stdbool is C99 standard feature.
> >
> > We are still targeting C89, not C99.
> >
> > Another reason not to depend on stdbool is tha
On Thursday 16 July 2009 00:38:31 Fernando Ike de Oliveira wrote:
> I applied the Tom Lane and Peter considerations, but I had that
> remove one column (Owner) of out command \dL to compatibility with 7.4
> version.
The mandate is to work as best as they can with older versions, not to provide
2009/7/16 Pavel Stehule :
>> I'm also not sure how to handle this if the set has to be spooled to
>> disk. Quicksort and Quickselect do a lot of scans throught he data and
>> wouldn't perform well on disk.
>
> I thing, so problem is in aggregate func used as window func - or some
> missing optimali
Grzegorz Jaskiewicz writes:
> Why C89, and not C99 ? Virtually all compilers for last 4 years have/
> had C99 support.
Not everybody is running a compiler released within the last 4 years.
The short answer is that C99 doesn't appear to offer enough advantage
over C89, *for our purposes*, to jus
On Thursday 16 July 2009 15:18:01 Andres Freund wrote:
> On Thursday 16 July 2009 15:13:02 Tom Lane wrote:
> > Andres Freund writes:
> > > The queries on the second reporting schema unfortunately are different.
> > > Its the one were I copied the crazy example I attached in the original
> > > thre
On 16 Jul 2009, at 14:20, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
oh, another thing.
stdbool is C99 standard feature.
We are still targeting C89, not C99.
Another reason not to depend on stdbool is that, so far as I can see,
the standard does not promise that type _Bool has size = 1 by
Grzegorz Jaskiewicz writes:
> oh, another thing.
> stdbool is C99 standard feature.
We are still targeting C89, not C99.
Another reason not to depend on stdbool is that, so far as I can see,
the standard does not promise that type _Bool has size = 1 byte.
We have to have that because of on-disk
On Thursday 16 July 2009 15:13:02 Tom Lane wrote:
> Andres Freund writes:
> > The queries on the second reporting schema unfortunately are different.
> > Its the one were I copied the crazy example I attached in the original
> > thread. With geqo=off a good part of the queries used daily use too m
Andres Freund writes:
> The queries on the second reporting schema unfortunately are different. Its
> the
> one were I copied the crazy example I attached in the original thread.
> With geqo=off a good part of the queries used daily use too much memory to
> plan
> sensibly and geqo=on outright
2009/7/16 Greg Stark :
> On Wed, Jul 15, 2009 at 11:18 AM, Pavel Stehule
> wrote:
>> postgres=# select avg(a) from (select a, row_number() over (order by
>> a) as r, count(*) over () as rc from x ) p where r in
>> ((rc+1)/2,(rc+2)/2) ;
>
> How does this compare to the plain non-windowing SQL imple
Peter Eisentraut writes:
> Which leads me to a related question: Do you plan to maintain one
> version of pg_migrator that can upgrade any version to any other
> version (within reason), or will there be separate binaries, say
> pg_migrator-8.4 and pg_migrator-8.5, that each can only upgrade from
1 - 100 of 118 matches
Mail list logo
