Joe Conway wrote:
> OK, so now I see why we want this fixed for dblink and walreceiver, but
> doesn't this approach leave every other WIN32 libpq client out in the
> cold? Is there nothing that can be done for the general case, or is it a
> SMOP?
The problem only applies to libpq calls from the ba
2010/1/22 Robert Haas :
> On Thu, Jan 21, 2010 at 2:25 PM, Pavel Stehule
> wrote:
>> 2010/1/21 Robert Haas :
>>> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule
>>> wrote:
add to state structure field like lexer_error. This field will be
checked before execution
it could be ugly
On 01/21/2010 10:33 PM, Heikki Linnakangas wrote:
> Joe Conway wrote:
>> I have not been really following this thread, but why can't we put the
>> "#ifdef WIN32" and special definition of these functions into libpq. I
>> don't understand why we need special treatment for dblink.
>
> The problem is
Joe Conway wrote:
> +#ifdef WIN23
> ^
> I assume you meant WIN32 here ;-)
Yeah. I admit I haven't tested this on Windows, I just commented out
those #ifdef's and tested on Linux. Will need to verify that this
actually solves the problem on Windows before committing.
> +#define PQexec(
The attached patch is a revised version.
List of updates:
- cleanup: getBlobs() was renamed to getBlobOwners()
- cleanup: BlobsInfo was renamed to BlobOwnerInfo
- bugfix: pg_get_userbyid() in SQLs were replaced by username_subquery which
constins a right subquery to obtain a username for
On Thu, Jan 21, 2010 at 2:25 PM, Pavel Stehule wrote:
> 2010/1/21 Robert Haas :
>> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule
>> wrote:
>>> add to state structure field like lexer_error. This field will be
>>> checked before execution
>>> it could be ugly for metacommands, there will be lot
On Jan 21, 2010, at 4:55 PM, Andrew Dunstan wrote:
> *shrug* I don't have a strong opinion about it, and it's pretty easy to
> change, if there's a consensus we should. I have certainly found over the
> years that perl warnings from some modules can be annoyingly verbose, which
> is probably wh
"Kevin Grittner" writes:
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> So add me to the list of people who think that if
>>> these are going to be recurring, we should look at moving from
>>> cvs to git as soon as 9.0 is released.
>>
>> The gating factor is not release schedule; it is the s
Tom Lane wrote:
> Now your original posts back in December were okay, since you were
> just letting people know that you intended to work on this over a
> long period. But IIRC you've made more than one post with actual
> code in it that you seemed to be hoping people would review, and
> that I
On Jan 21, 2010, at 4:02 PM, Eric B. Ridge wrote:
> On Jan 21, 2010, at 12:35 PM, David E. Wheeler wrote:
>
>> And where do you think baby powder comes from? Sheesh.
>
> You won the thread!
Heh, who's the wise guy that posted the second comment on
http://www.betanews.com/article/EU-clears-Oracl
Robert Haas wrote:
> people get bogged down and don't have time to finish the work.
Ok, I moved this patch to the next commit fest for 9.1 alpha 1.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On 01/21/2010 04:46 AM, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
>> Magnus Hagander wrote:
>>> 2010/1/17 Heikki Linnakangas :
We could replace the blocking PQexec() calls with PQsendQuery(), and use
the emulated version of select() to wait.
>>> Hmm. That would at least theor
On 01/11/2010 07:43 PM, Takahiro Itagaki wrote:
> There is a memory leak in dblink when we cancel a query during
> returning tuples. It could leak a PGresult because memory used
> by it is not palloc'ed one. I wrote a patch[1] before, but I've
> badly used global variables to track the resource.
>
Tom Lane wrote:
Andrew Dunstan writes:
Jim Nasby wrote:
Why does warn; in plperl log as NOTICE in Postgres?
Where would you like the warning to go? This has been this way for
nearly 5 years, it's not new (and before that the warning didn't go
anywhere).
I think h
On Thu, Jan 21, 2010 at 5:35 PM, Peter Eisentraut wrote:
> On tor, 2010-01-21 at 17:06 -0500, Robert Haas wrote:
>> But let me ask this. For which
>> release were you hoping to make this change? If 9.0, then it seems to
>> me that you've missed the deadline, which - according to my
>> understand
Tom Lane wrote:
> What I do think is that the quoted code snippet has no business being
> outside the planner proper. It'd be better to put it in planner.c
> or someplace like that.
Ah, I see. My concern was the dummy planner approach is using internal
functions of planner. It would be better
"Larry Rosenman" writes:
> On Thu, January 21, 2010 5:53 pm, Andreas Joseph Krogh wrote:
>> Care to shed some light on what features (yes, we users care about
>> features) warrant this major version-bump? Is there a link somewhere?
> AFAIR, it was stated if Hot Standby AND Streaming Replication h
Andrew Dunstan writes:
> Jim Nasby wrote:
>> Why does warn; in plperl log as NOTICE in Postgres?
> Where would you like the warning to go? This has been this way for
> nearly 5 years, it's not new (and before that the warning didn't go
> anywhere).
I think he's suggesting that it ought to tran
On Thu, Jan 21, 2010 at 7:11 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> If you want an example of something I *do* have a process problem
>>> with, it's Kevin Grittner's attempts
>
>> Hmmm Plural? I've made exactly one post on the subject since
>> the CF started,
"Kevin Grittner" writes:
> Tom Lane wrote:
>> If you want an example of something I *do* have a process problem
>> with, it's Kevin Grittner's attempts
> Hmmm Plural? I've made exactly one post on the subject since
> the CF started, unless you count review of Markus's dtester code,
> whic
On Thu, January 21, 2010 5:53 pm, Andreas Joseph Krogh wrote:
> On Thursday 21. January 2010 10.37.41 Dave Page wrote:
>> In an attempt to pre-empt the normally drawn-out discussions about
>> what the next version of PostgreSQL will be numbered. the core team
>> have discussed the issue and follow
(2010/01/21 19:42), Takahiro Itagaki wrote:
>
> KaiGai Kohei wrote:
>
>>> I'm not sure whether we need to make groups for each owner of large objects.
>>> If I remember right, the primary issue was separating routines for dump
>>> BLOB ACLS from routines for BLOB COMMENTS, right? Why did you mak
On Thursday 21. January 2010 10.37.41 Dave Page wrote:
> In an attempt to pre-empt the normally drawn-out discussions about
> what the next version of PostgreSQL will be numbered. the core team
> have discussed the issue and following a lenghty debate lasting
> literally a few minutes decided that
Jim Nasby wrote:
Why does warn; in plperl log as NOTICE in Postgres?
On a related note, what's the logic behind perl DEBUG logging as DEBUG2 instead
of DEBUG1 or DEBUG5? Still seems kind of odd, but at least nowhere near as
surprising as warn becoming NOTICE...
Where would you like the
Tom Lane wrote:
> If you want an example of something I *do* have a process problem
> with, it's Kevin Grittner's attempts
Hmmm Plural? I've made exactly one post on the subject since
the CF started, unless you count review of Markus's dtester code,
which he posted before the CF but didn
One other point about this, before anyone asks: we will of course have
to go through the source code and docs to s/8.5/9.0/. The plan is to do
that between the conclusion of the current commitfest and the release of
the final alpha version (which will therefore call itself 9.0alpha4 not
8.5alpha4)
Tom Lane wrote:
> If you want an example of something I *do* have a process problem
> with, it's Kevin Grittner's attempts to get people to put a
> significant number of cycles into thinking about true
> serializability.
> Right now is not the time for that to be happening. I've been
> politely
Andrew Dunstan writes:
> Peter Eisentraut wrote:
>> But I don't think that should mean everyone has to drop everything when
>> the clock strikes midnight and must now only look at things that the
>> magic commitfest page has pre-approved.
> Well, we used to have the idea of a feature freeze ...
On Fri, Jan 22, 2010 at 12:29 AM, Andrew Chernow wrote:
>
>>> 9.0.
>>>
>>
>> You don't have a code-name. All the cool kids have code-names for their
>> projects.
>>
>>
> Black Dog
>
> yup, I'm a zeppelin fan :)
>
+1
:)
--
Regards,
Michael Paquier
NIPPON TELEGRAPH AND
TELEPHONE CORPORATION
NTT
On Jan 21, 2010, at 3:05 PM, Andrew Dunstan wrote:
> Well, we used to have the idea of a feature freeze ... is that going to apply
> at the end of the commitfest?
>
> I generally agree that we need to have a bit of wiggle room at this stage -
> small and non-controversial items can be allowed t
Why does warn; in plperl log as NOTICE in Postgres?
On a related note, what's the logic behind perl DEBUG logging as DEBUG2 instead
of DEBUG1 or DEBUG5? Still seems kind of odd, but at least nowhere near as
surprising as warn becoming NOTICE...
--
Jim C. Nasby, Database Architect
Peter Eisentraut wrote:
But I don't think that should mean everyone has to drop everything when
the clock strikes midnight and must now only look at things that the
magic commitfest page has pre-approved.
Well, we used to have the idea of a feature freeze ... is that going to
apply at t
On tor, 2010-01-21 at 17:06 -0500, Robert Haas wrote:
> But let me ask this. For which
> release were you hoping to make this change? If 9.0, then it seems to
> me that you've missed the deadline, which - according to my
> understanding of the agreed-upon schedule - was six days ago.
By that log
On Jan 21, 2010, at 12:35 PM, David E. Wheeler wrote:
> And where do you think baby powder comes from? Sheesh.
You won the thread!
eric
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dimitri Fontaine wrote:
Heikki Linnakangas writes:
Yeah, a lot of that logic and states is completely unnecessary until we
have a synchronous mode. Even then, it seems complex.
I hope we'll find something less complex, what I proposed is heavily
inspired from londiste (Skytools) table
Heikki Linnakangas writes:
> Yeah, a lot of that logic and states is completely unnecessary until we
> have a synchronous mode. Even then, it seems complex.
I hope we'll find something less complex, what I proposed is heavily
inspired from londiste (Skytools) table addition to a replication set
(
On Thu, Jan 21, 2010 at 4:24 PM, Peter Eisentraut wrote:
>> Why bother?
>
> Because unique constraints and primary keys are different things and it
> would be slightly less confusing that way.
I don't really see why it would be any less confusing. You could
argue that someone might not know that
On tor, 2010-01-21 at 16:29 -0500, Tom Lane wrote:
> regression=# alter table foo add primary key (f1);
> NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "foo_pkey"
> for table "foo"
> ERROR: could not create unique index "foo_pkey"
> DETAIL: Key (f1)=(1) is duplicated.
He he,
Rafael Martinez writes:
> Tom Lane wrote:
>> I think this is normal behavior now, if you have an unloaded server.
>> pg_start_backup now forces a segment switch, so if nothing much else is
>> happening it's quite likely that the recorded start point will be the
>> beginning of the WAL segment (plu
Tom Lane wrote:
> Rafael Martinez writes:
>
>> All PITR backup history files created when running a PITR base backup on
>> all PostgreSQL clusters running in this new server (at different hours
>> during the night) got an identical 2nd part file name.
>
>> <24 digits>.0020.backup e.g.00
Peter Eisentraut writes:
> On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
>> This patch fails to cover all cases (index build being the obvious
>> omission, but I think there might be other paths as well where the
>> information is not so readily available).
> This is the user-visible error m
On tor, 2010-01-21 at 15:47 -0500, Robert Haas wrote:
> On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
> > Here is a small patch that changes the error message
> >
> >duplicate key value violates unique constraint "%s"
> >
> > into
> >
> >duplicate key value violates primary key
On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
> >> Here is a small patch that changes the error message
> >>
> >> duplicate key value violates unique constraint "%s"
> >>
> >> into
> >>
> >> duplicate key
Rafael Martinez writes:
> After upgrading to 8.3.9 and moving some our PostgreSQL clusters to a
> new server yesterday, we have experienced a strange thing this past night.
> All PITR backup history files created when running a PITR base backup on
> all PostgreSQL clusters running in this new ser
Robert Haas writes:
> On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
>> Here is a small patch that changes the error message
>>
>> duplicate key value violates unique constraint "%s"
>>
>> into
>>
>> duplicate key value violates primary key "%s"
>>
>> when the constraint is in
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
> Here is a small patch that changes the error message
>
> duplicate key value violates unique constraint "%s"
>
> into
>
> duplicate key value violates primary key "%s"
>
> when the constraint is in fact a primary key.
>
> Comments?
On Thu, 2010-01-21 at 21:26 +0100, Stefan Kaltenbrunner wrote:
>
> http://www.postgresql.org/docs/current/static/release-6-5.html
That was another great release IMHO.
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~li
Here is a small patch that changes the error message
duplicate key value violates unique constraint "%s"
into
duplicate key value violates primary key "%s"
when the constraint is in fact a primary key.
Comments?
PS: Yes, this would need a handful of regression test updates if
accepte
Grzegorz Jaskiewicz wrote:
On 21 Jan 2010, at 09:37, Dave Page wrote:
In an attempt to pre-empt the normally drawn-out discussions about
what the next version of PostgreSQL will be numbered. the core team
have discussed the issue and following a lenghty debate lasting
literally a few minutes de
On 21 Jan 2010, at 09:37, Dave Page wrote:
> In an attempt to pre-empt the normally drawn-out discussions about
> what the next version of PostgreSQL will be numbered. the core team
> have discussed the issue and following a lenghty debate lasting
> literally a few minutes decided that the next r
Hello
After upgrading to 8.3.9 and moving some our PostgreSQL clusters to a
new server yesterday, we have experienced a strange thing this past night.
All PITR backup history files created when running a PITR base backup on
all PostgreSQL clusters running in this new server (at different hours
du
Le 15/01/2010 18:53, Guillaume Lelarge a écrit :
> Le 08/01/2010 23:22, Guillaume Lelarge a écrit :
>> Le 07/01/2010 19:13, Robert Haas a écrit :
>>> On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
>>> wrote:
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
> Le 29/12/2009 14:12, Guill
2010/1/21 Robert Haas :
> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule
> wrote:
>> add to state structure field like lexer_error. This field will be
>> checked before execution
>> it could be ugly for metacommands, there will be lot of new checks :(
>
> Eh? The only places where we should nee
On Mon, Jan 18, 2010 at 3:55 AM, Takahiro Itagaki
wrote:
> Robert Haas wrote:
>> A couple of preliminary comments on this:
>
> Thanks.
> The attached is rebased on HEAD, with additional documentation.
>
>> 1. If we're thinking that this syntax should eventually result in
>> inserts (and updates?)
On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule wrote:
> add to state structure field like lexer_error. This field will be
> checked before execution
> it could be ugly for metacommands, there will be lot of new checks :(
Eh? The only places where we should need new tests are the places
that che
On Thu, Jan 21, 2010 at 1:28 PM, Leonardo F wrote:
>> Well, the expression cases would be more likely to cost more if
>> implemented as a sort, but that doesn't mean that a sort couldn't be a
>> win. Besides, even if you blow off the expression case, what about
>> nulls first/last, nondefault opc
> Well, the expression cases would be more likely to cost more if
> implemented as a sort, but that doesn't mean that a sort couldn't be a
> win. Besides, even if you blow off the expression case, what about
> nulls first/last, nondefault opclasses, etc?
Ok, let's split the problem in 2 parts:
On Jan 21, 2010, at 10:06 AM, Tom Lane wrote:
> Well, without a context that explains *why* you're doing that, it's hard
> to consider what a better solution would look like. Personally I
> usually prefer solutions involving WHERE oid = 'foo.bar'::regclass,
> because that scales easily to either
"David E. Wheeler" writes:
> The names of schemas in which to find functions, tables, views, triggers,
> etc. etc. I have lots of stuff like this:
> SELECT true
> FROM pg_catalog.pg_namespace n
> JOIN pg_catalog.pg_class c ON n.oid = c.relnamespace
> WHERE c.
On Jan 21, 2010, at 12:02 PM, Tom Lane wrote:
David Christensen writes:
Should the error messages between the SHOW cases and the others be
consistent ("ERROR: unsupported command" or similar)? It's worth
noting that this is only in the psql client, but we could simulate
the
ereport output
David Christensen writes:
> Should the error messages between the SHOW cases and the others be
> consistent ("ERROR: unsupported command" or similar)? It's worth
> noting that this is only in the psql client, but we could simulate the
> ereport output from the server.
No. Not unless you w
On Jan 21, 2010, at 11:56 AM, Tom Lane wrote:
David Christensen writes:
Enclosed is a patch adding a 'regschema' OID type.
What in the world is the point of that? The regfoo types are for
things
that have schema-qualified names.
Perhaps the naming is a bit disingenuous, and I'm not ti
On Jan 21, 2010, at 9:57 AM, Tom Lane wrote:
> Schema names of what? It sounds to me like you're failing to use the
> existing regfoo types in appropriate places ...
The names of schemas in which to find functions, tables, views, triggers, etc.
etc. I have lots of stuff like this:
SELE
2010/1/21 David Christensen :
>
> On Jan 21, 2010, at 11:48 AM, Florian Weimer wrote:
>
>> * David Christensen:
>>
>>> Currently, a session will look like the following:
>>>
>>> machack:machack:5485=# show tables;
>>> See:
>>> \d
>>> or \? for general help with psql commands
>>> ma
"David E. Wheeler" writes:
> OOh, /me likey! This would save me a ton of code in pgTAP (about half its
> queries have to join to pg_namespace to get schema names).
Schema names of what? It sounds to me like you're failing to use the
existing regfoo types in appropriate places ...
On Jan 21, 2010, at 11:48 AM, Florian Weimer wrote:
* David Christensen:
Currently, a session will look like the following:
machack:machack:5485=# show tables;
See:
\d
or \? for general help with psql commands
machack:machack:5485=#
Said formatting looks like it could use
David Christensen writes:
> Enclosed is a patch adding a 'regschema' OID type.
What in the world is the point of that? The regfoo types are for things
that have schema-qualified names.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
2010/1/21 Robert Haas :
> On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule
> wrote:
>> 2010/1/21 Robert Haas :
>>> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'd like to proceed by committing an ini
On Jan 21, 2010, at 9:46 AM, David Christensen wrote:
> It uses the same quoting mechanism as regclass, and I've tested against some
> odd schema names such as "foo""schema"; I updated the docs as I was able, but
> am not familiar enough with the regression tests to add those yet. I hope to
>
* David Christensen:
> Currently, a session will look like the following:
>
> machack:machack:5485=# show tables;
> See:
> \d
> or \? for general help with psql commands
> machack:machack:5485=#
>
> Said formatting looks like it could use some improvement, open to
> suggest
Hey -hackers,
Enclosed is a patch adding a 'regschema' OID type. I'm really just
hoping to get this out there, don't worry about committing it at this
point. This is something that I've always wanted in the field (yes,
I'm lazy). Many thanks to RhodiumToad for pointers about the
necess
On Jan 19, 2010, at 9:26 PM, Andrew Dunstan wrote:
> The first thing I think we need to do is move the GUC processing code out of
> _PG_init() and into plperl_init_interp(), protected by a flag to make sure
> it's only called successfully once. I'm trying to work out a neat way to put
> the val
On Jan 21, 2010, at 9:19 AM, Robert Haas wrote:
> As far as I can see, there is absolutely zero reason to care about
> whether the product is called Postgres or PostgreSQL.
How about simply "Post"? Or just "SQL"? ;-P
> If it were
> called WeGrindUpTheBonesOfSmallChildrenSQL, maybe a change wou
On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule wrote:
> 2010/1/21 Robert Haas :
>> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
>>> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
Robert Haas writes:
> I'd like to proceed by committing an initial patch which changes the
>
On Thu, 2010-01-21 at 10:14 +0100, Joachim Wieland wrote:
> On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis wrote:
> > Here's the problem as I see it:
>
> You are writing a lot of true facts but I miss to find a real
> problem... What exactly do you see as a problem?
I worded that in a confusing way
On Thu, Jan 21, 2010 at 11:59 AM, Pavel Stehule wrote:
Better yet, how about we bite the bullet and make the name change
official. Seems like a major version bump is the right time
to do it.
>>
>>> I thought we ended up that thread already?
>>
>> Well, the thread may have ended, but
Leonardo F writes:
> I hoped that since people mostly (>95%?) use plain btree indexes,
> a patch that helped CLUSTER with using such indexes would be fine
> (at least at first...). I guess that a patch that deals with all other types
> of
> indexes would be way more complicated (not at the "plann
> > I meant to add only ASC/DESC; I would leave all other cases
> > (non-btrees, custom expression btrees) to use the old index-scan method.
>
> That hardly seems acceptable.
Well I brought up that in an earlier post:
http://old.nabble.com/Re%3A-About-%22Our-CLUSTER-implementation-is-pessimal%2
2010/1/21 Greg Sabino Mullane :
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
>>> Better yet, how about we bite the bullet and make the name change
>>> official. Seems like a major version bump is the right time
>>> to do it.
>
>> I thought we ended up that thread already?
>
> Well,
2010/1/21 Robert Haas :
> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
>> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
>>> Robert Haas writes:
I'd like to proceed by committing an initial patch which changes the
"Escaping Strings for Inclusion in SQL Commands" to use a
"Greg Sabino Mullane" wrote:
> many people are loathe to see the discussion come up again,
> but as long as the project is saddled with its ugly and
> unweildy official name, it has a large problem.
I don't particularly like the official stance on pronouncing it, but
other than that I see no p
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> Better yet, how about we bite the bullet and make the name change
>> official. Seems like a major version bump is the right time
>> to do it.
> I thought we ended up that thread already?
Well, the thread may have ended, but the problem rema
Magnus Hagander writes:
> So the list really isn't very long. I think it's perfectly possible to
> clear it off before the release. Because we still only want to change
> after the release, or are you saying once those are fixed, we can
> change even if we happen to be in beta at the time?
When a
Leonardo F writes:
>> By the time you make this actually work in all cases, it's probably
>> going to be more of a mess than the other way;
> I meant to add only ASC/DESC; I would leave all other cases
> (non-btrees, custom expression btrees) to use the old index-scan method.
That hardly seems
Boszormenyi Zoltan writes:
> You expressed stability concerns coming from this patch.
> Were these concerns because of locks timing out making
> things fragile or because of general feelings about introducing
> such a patch at the end of the release cycle? I was thinking
> about the former, hence
> By the time you make this actually work in all cases, it's probably
> going to be more of a mess than the other way;
I meant to add only ASC/DESC; I would leave all other cases
(non-btrees, custom expression btrees) to use the old index-scan method.
> not to mention that it
> doesn't work *at
Tom Lane írta:
> Robert Haas writes:
>
>> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote:
>>
>>> I would like a mini-review on the change I made in the latest
>>> patch by introducing the validator function. Is it enough
>>> to check for
>>>(source == PGC_S_DEFAULT || sourc
Robert Haas writes:
> On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane wrote:
>> Why is this a good idea at all? I can easily see somebody feeling that
>> he'd like autovacuums to fail rather than block on locks for a long
>> time, for example.
> What I can see happening is someone setting this GUC i
Leonardo F writes:
>> one idea could be to actually prepare a query using SPI for "select * from
>> table order by " and then peek inside
>> to see which plan was generated.
> I like that!!!
> Here's a first attempt, it looks like it's working...
> (I still have to skip non-btree indexes and ex
Tom Lane wrote:
> I have noticed that CVS operations (at least from the user's
> viewpoint) work in local time. So even if the clocks are synced,
> a different TZ setting could conceivably lead to issues.
Hmmm... If that were the issue I would think we'd've seen the
problem more often. From
On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote:
>>> I would like a mini-review on the change I made in the latest
>>> patch by introducing the validator function. Is it enough
>>> to check for
>>> (source ==
Robert Haas writes:
> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote:
>> I would like a mini-review on the change I made in the latest
>> patch by introducing the validator function. Is it enough
>> to check for
>> (source == PGC_S_DEFAULT || source == PGC_S_SESSION)
>> to ensure on
>one idea could be to actually prepare a query using SPI for "select * from
>table order by " and then peek inside
> to see which plan was generated.
I like that!!!
Here's a first attempt, it looks like it's working...
(I still have to skip non-btree indexes and expression indexes, plus
add a AS
Greg Stark wrote:
> What would be useful is a tool which given a list of standby
> databases and list of base backup images can apply a set of policy
> rules to determine which base backups and archived logs to delete.
>
> The policy might look something like "keep one base backup per
> week go
Takahiro Itagaki writes:
> * I'd prefer to separate cost calculation routines from create_index_path()
>and cost_sort(), rather than using a dummy planner.
Don't go that way. The cost functions have enough dependencies on
low-level planner functionality that making them be standalone would
9.0.
You don't have a code-name. All the cool kids have code-names for their
projects.
Black Dog
yup, I'm a zeppelin fan :)
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
On Thu, Jan 21, 2010 at 07:30, Robert Haas wrote:
> On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker wrote:
>> Seems to me a comment about the above might be nice. Something like
>> /* Things after here are should always be default null */ in
>> pg_attribute.h ?
>
> Well... that wouldn't actually
Andrew Dunstan wrote:
> "Bullwinkle" (This time for sure!)
LOL
But that trick never works...
http://www.youtube.com/watch?v=e7mmrF-4rUE
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote:
> Thanks. So it means that this patch will considered for 9.1.
Yeah, I think that's best.
> I would like a mini-review on the change I made in the latest
> patch by introducing the validator function. Is it enough
> to check for
> (so
On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I'd like to proceed by committing an initial patch which changes the
>>> "Escaping Strings for Inclusion in SQL Commands" to use a
>>> with one per function (as we
1 - 100 of 136 matches
Mail list logo
