Hi,
Heikki Linnakangas writes:
> I think a better way to address that need is to provide a built-in
> mechanism for the standby to request a base backup and have it sent over
> the wire. That makes the initial setup very easy.
Great idea :)
So I'll reproduce the sketch I did in this other mail
Hi,
I'm reviewing this patch:
http://archives.postgresql.org/message-id/3f0b79eb0907022341m1d36a841x19c3e2a5a6906...@mail.gmail.com
This one applies almost cleanly, except for a minor hunk in elog.c and
postinit.c
Compiles and pass regression tests (i tried both steps in a debian
lenny amd turion
Hi,
On Thu, Jul 16, 2009 at 6:03 AM, Heikki
Linnakangas wrote:
> I don't think there's much point assigning more reviewers to Synch Rep
> at this point. I believe we have consensus on four major changes:
Thanks for clarifying the issues! Okey, I'll rework the patch.
> 1. Change the way synchroni
Tom Lane writes:
> Bruce Momjian writes:
>> A larger question is what do we do with pg_migrator now. I am
>> embarrassed I didn't find these errors before, but now that they are
>> known, and will probably need an 8.4.1 to fix, should I remove the
>> pg_migrator 8.4 source code from pgfoundry?
Hi Robert, Hi all,
The patch applies cleanly and works as intended - no surprise here. After the
changes the documentation is at least as easy to understand as before and the
code changes look sensible
Also not surprisingly that's not the area I expected problems I guess ;-)
For performance tes
Fujii Masao wrote:
> On Thu, Jul 16, 2009 at 6:03 AM, Heikki
> Linnakangas wrote:
>> 1. Change the way synchronization is done when standby connects to
>> primary. After authentication, standby should send a message to primary,
>> stating the point (where is an XLogRecPtr, not a WAL
>> segment na
Hi folks,
Today I got bitten a bit, trying to write C function for postgresql,
that also includes some of company's internal stuff. Needles to say,
our stuff defines BOOL, as well as postgresql's c.h include file.
Now, for us, we will probably change it, but is there any reason for
postgr
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 question: Do you plan to maintain on
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 implementation:
select a from x order
> 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 optimalisation.
when I replaced count(*)
Committed.
Fujii Masao wrote:
> Hi,
>
> On Thu, Jun 25, 2009 at 10:09 PM, Magnus Hagander wrote:
>> The second question is, is it worth doing this so extremely late in the
>> 8.4 development? After mentioning it quickly in an offlist discussion
>> with Heikki, I think our conclusion was that we s
Hi Petr,
> this is first public version of our DefaultACLs patch as described on
> http://wiki.postgresql.org/wiki/DefaultACL .
I have been assigned by Robert to do an initial review of your "GRANT
ON ALL" patch mentioned here
(http://archives.postgresql.org/pgsql-hackers/2009-07/msg00207.php)
D
Dimitri Fontaine wrote:
> Tom Lane writes:
>
> > Bruce Momjian writes:
> >> A larger question is what do we do with pg_migrator now. I am
> >> embarrassed I didn't find these errors before, but now that they are
> >> known, and will probably need an 8.4.1 to fix, should I remove the
> >> pg_mig
--On 16. Juli 2009 11:12:34 +0100 Grzegorz Jaskiewicz
wrote:
Now, for us, we will probably change it, but is there any reason for
postgresql nowadays not to use stdbool.h, apart from fact, that no one
made an effort ? Having said that, wouldn't it be easy as just replacing
all TRUE/FALSE/BO
Nikhil Sontakke wrote:
Does this new DefaultACL patch nullify this earlier one? Or it is
different and should be looked at first since it was added to the
commitfest before the defaultACL patch? It is a bit confusing. Please
clarify.
No, DefaultACLs applies to objects created in the future whi
On Jul 16, 2009, at 12:07 AM, Heikki Linnakangas wrote:
Dimitri Fontaine wrote:
Le 15 juil. 09 à 23:03, Heikki Linnakangas a écrit :
Furthermore, the counter-argument against having the primary
able to send data from the archives to some standby is that it should
still work when primary's dead,
On 16 Jul 2009, at 12:52, Bernd Helmle wrote:
--On 16. Juli 2009 11:12:34 +0100 Grzegorz Jaskiewicz > wrote:
Now, for us, we will probably change it, but is there any reason for
postgresql nowadays not to use stdbool.h, apart from fact, that no
one
made an effort ? Having said that, woul
oh, another thing.
stdbool is C99 standard feature. Not gcc extension.
Just in case, someone thinks otherwise.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
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
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
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
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 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
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
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
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
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
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 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 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 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
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
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.
>>
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
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
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 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
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
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
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. ?
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 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
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
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
>
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
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
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
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:
> 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
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
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 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 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, 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 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 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,
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: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
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
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
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
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
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
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
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
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 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 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?
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:
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
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
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
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 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
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 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
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 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
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 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
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 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
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
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
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.
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
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 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
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
> -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
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
"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
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.
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
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
>
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
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
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
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).
1 - 100 of 118 matches
Mail list logo
