On tor, 2009-11-26 at 10:57 +0200, Peter Eisentraut wrote:
> When using the "service" parameter in a libpq connection (e.g., psql
> service=foo), and the service name is not defined in pg_service.conf,
> then the setting is silently ignored and the connection proceeds with
> whatever other settings
Peter Eisentraut wrote:
> When using the "service" parameter in a libpq connection (e.g., psql
> service=foo), and the service name is not defined in pg_service.conf,
> then the setting is silently ignored and the connection proceeds with
> whatever other settings and defaults apply. That does not
On Thu, Nov 26, 2009 at 4:25 PM, Robert Haas wrote:
> Current version of patch is attached. I've revised it to use the
> reloptions stuff, but I don't think it's committable as-is because it
> currently thinks that extracting options from a pg_tablespace tuple is
> a cheap operation, which was tr
On Thu, Nov 26, 2009 at 6:13 PM, David Fetter wrote:
> It'd be nice to make this available to the next revision of DBI-Link
> and it'll be pretty handy for our SQL/MED whenever that happens.
Okay, so this thread sort of wandered into how we could refactor other
elements of COPY. Do we have a goo
On Thu, Nov 26, 2009 at 10:11:12AM -0500, Andrew Dunstan wrote:
> On Thu, November 26, 2009 2:22 am, Jeff Davis wrote:
> > On Thu, 2009-11-26 at 00:35 -0500, Andrew Dunstan wrote:
> >> On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote:
> >> >
> >> > I worry that we're getting further away from th
On Thu, Nov 26, 2009 at 4:14 PM, Dan Eloff wrote:
> Hi Hackers,
>
> I've familiarized myself a little with the architecture of postgresql,
> largely because it's interesting. There's one thing I can't quite
> figure out though, and it seems that there's no better group of people
> in the world to
Dan Eloff wrote:
At the lower levels in PG, reading from the disk into cache, and
writing from the cache to the disk is always done in pages.
Why does PG work this way? Is it any slower to write whole pages
rather than just the region of the page that changed? Conversely, is
it faster? From w
On Thu, 2009-11-26 at 16:31 -0500, Robert Haas wrote:
> On Thu, Nov 26, 2009 at 4:33 AM, Jeff Davis wrote:
> > Thanks, I applied it. The only significant thing I changed was that I
> > did not inline the "index_elem" because it made it fairly hard to read.
> > Instead, I renamed it "exclude_elem"
On Thu, Nov 26, 2009 at 4:33 AM, Jeff Davis wrote:
> Thanks, I applied it. The only significant thing I changed was that I
> did not inline the "index_elem" because it made it fairly hard to read.
> Instead, I renamed it "exclude_elem" to make it a little more
> meaningful, which I assume may have
Jeff Davis writes:
> The following commit to release-8.5.sgml:
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=e043393bcc7ed484c3e3cd6a1ce4c63651ab46be
> broke the documentation (no end tag).
Ooops, my fault.
> Wouldn't the buildfarm notice
> this, or does it not build the do
Hi Hackers,
I've familiarized myself a little with the architecture of postgresql,
largely because it's interesting. There's one thing I can't quite
figure out though, and it seems that there's no better group of people
in the world to ask about it.
At the lower levels in PG, reading from the dis
The following commit to release-8.5.sgml:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=e043393bcc7ed484c3e3cd6a1ce4c63651ab46be
broke the documentation (no end tag). Wouldn't the buildfarm notice
this, or does it not build the docs?
Regards,
Jeff Davis
--
Sent via
On Thu, 26 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
On Wed, 25 Nov 2009, Tom Lane wrote:
I think you altered the wrong function. The function underlying
point <@ box is on_pb() not pt_contained_box ... in fact, I don't
even see a function named that.
sorry, I forgot to say, that I
Tom Lane wrote:
What this misses is EvalPlanQual, which can require
initialization of a new plan tree during execution.
Agh. You're right, I missed that.
When I realized this, my first thought was that we might as well drop
all the proposed changes that involve avoiding use of
es_result_rela
Michael Meskes írta:
> On Mon, Nov 16, 2009 at 11:58:04AM +0100, Boszormenyi Zoltan wrote:
>
>> I have rebased the ECPG patches to current CVS.
>> This mail contains the dynamic cursorname,
>> the fine-grained split-up was re-united as per
>> Alvaro's comment.
>>
>
> Rest of it committed to
Marko Tiikkaja writes:
> Attached is the latest version of the patch.
I started to look at this patch and soon noted that a very substantial
fraction of the delta had to do with getting rid of dependencies on
estate->es_result_relation_info. It seemed to me that if we were going
to do that, we s
pete...@gmx.net (Peter Eisentraut) writes:
> On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
>> Attached is a patch which adds a chapter to git in our documentation,
>> around where we have several chapters about cvs today. It also removes
>> a few very out of date comments about cvs
>
>
BTW, it's possible to add this feature to plain btree by changing
traversal algorithm, but I'm fill enough power to do it.
Sorry, I'm NOT fill enough power to do it.
%-), I'm NOT FEEL enough power to do it.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
BTW, it's possible to add this feature to plain btree by changing
traversal algorithm, but I'm fill enough power to do it.
Sorry, I'm NOT fill enough power to do it.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW
explain select col1 from s order by abs(col1 - 5) limit 10;
is the one-dimensional equivalent of the type of query you're proposing
Exactly, it's already done in next version of patch :)
and that doesn't work either until you put an index on abs(col1 - 5),
then it just works, but only for k
Hi!
Contrib module is reworked as a patch for current GiST. Now GiST supports
KNN-search, the query looks like
SELECT * FROM point_tbl ORDER BY f1 <-> '0,1';
or
SELECT * FROM point_tbl WHERE f1 <@ '(-10,-10),(10,10)':: box ORDER BY f1 <->
'0,1';
Plans are:
EXPLAIN (COSTS OFF)
SELECT * FROM poi
Michael Meskes writes:
> I wrote a hackish little script that checks if all rules in ecpg.addons are
> indeed used to create the precompiler's parser to catch renamed symbol and
> similar changes. Now I wonder whether this should be added to the build
> process. If it is, the buildfarm will catch
Magnus Hagander writes:
> I assume you are fine with the addition of some info about git, but
> what about the removal of those two chapters suggested?
I agree that we needn't try to cover material that's in the CVS manual.
As somebody mentioned upthread, a sentence or two about our branching
and
I wrote a hackish little script that checks if all rules in ecpg.addons are
indeed used to create the precompiler's parser to catch renamed symbol and
similar changes. Now I wonder whether this should be added to the build
process. If it is, the buildfarm will catch every such change, not just the
On Thu, Nov 26, 2009 at 16:38, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Robert Haas wrote:
>>> I have to say I'm not really impressed by the idea of removing things
>>> from our documentation and replacing them with pages on the wiki. The
>>> documentation is better-written and easier to
Updated application name patch, including a GUC assign hook to clean
the application name of any unsafe characters, per discussion.
Regards, Dave
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
appname-v4.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-h
2009/11/26 Jeff Davis :
> On Thu, 2009-11-26 at 05:01 +0100, Pavel Stehule wrote:
>> It working like:
>>
>> 1. EXECUTE SELECT 0 FROM generate_series(1,...);
>> 2. STORE RESULT TO TABLE zero;
>> 3. EXECUTE SELECT 1/i FROM zero;
>> 4. STORE RESULT TO TABLE tmp;
>>
>> Problem is in seq execution. Resu
Heikki Linnakangas writes:
> Robert Haas wrote:
>> I have to say I'm not really impressed by the idea of removing things
>> from our documentation and replacing them with pages on the wiki. The
>> documentation is better-written and easier to navigate.
> I agree in general, but information abou
Hannu Krosing wrote:
After triggers can't change tuple, thus cant change routing.
An after trigger can always issue an update of the tuple but that should
be trapped by the regular mechanism that will deal with updates (when we
have it available).
Also the description omits the execution of
On Thu, November 26, 2009 2:22 am, Jeff Davis wrote:
> On Thu, 2009-11-26 at 00:35 -0500, Andrew Dunstan wrote:
>> On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote:
>> >
>> > I worry that we're getting further away from the original problem.
>> Let's
>> > allow functions to get the bytes of data
On Thu, November 26, 2009 2:22 am, Jeff Davis wrote:
> On Thu, 2009-11-26 at 00:35 -0500, Andrew Dunstan wrote:
>> On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote:
>> >
>> > I worry that we're getting further away from the original problem.
>> Let's
>> > allow functions to get the bytes of data
Dave Page writes:
> OK - something like this? Should keep non-printable/control characters
> out of logs too...
Personally I'd use guc_strdup and then modify the string in-place,
but that's just a matter of taste I guess. Otherwise it seems
reasonable.
regards, tom lane
On Mon, Nov 16, 2009 at 11:58:04AM +0100, Boszormenyi Zoltan wrote:
> I have rebased the ECPG patches to current CVS.
> This mail contains the dynamic cursorname,
> the fine-grained split-up was re-united as per
> Alvaro's comment.
Rest of it committed to HEAD.
Thanks for your work.
Michael
--
Oleg Bartunov writes:
> On Wed, 25 Nov 2009, Tom Lane wrote:
>> I think you altered the wrong function. The function underlying
>> point <@ box is on_pb() not pt_contained_box ... in fact, I don't
>> even see a function named that.
> sorry, I forgot to say, that I created operator
Unless you ch
On Wed, Nov 25, 2009 at 10:01 PM, Tom Lane wrote:
> ISTM restricting the name to ASCII-only is the most reasonable tradeoff.
> Of course, as a speaker of English I may be a bit biased here --- but
> doing nothing about the issue doesn't seem acceptable.
OK - something like this? Should keep non-p
On Thu, Nov 26, 2009 at 6:44 AM, Magnus Hagander wrote:
> On Thu, Nov 26, 2009 at 12:29, Robert Haas wrote:
>> On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut wrote:
>>> On ons, 2009-11-25 at 22:15 +0100, Magnus Hagander wrote:
On Wed, Nov 25, 2009 at 22:07, Peter Eisentraut wrote:
On Thu, Nov 26, 2009 at 12:29, Robert Haas wrote:
> On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut wrote:
>> On ons, 2009-11-25 at 22:15 +0100, Magnus Hagander wrote:
>>> On Wed, Nov 25, 2009 at 22:07, Peter Eisentraut wrote:
>>> > On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
>>>
Robert Haas wrote:
> On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut wrote:
>> In the installation instructions chapter, there is a section "Getting
>> the Source", which could warrant a link or reference to the appropriate
>> instructions on the web site.
>
> I have to say I'm not really impre
On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut wrote:
> On ons, 2009-11-25 at 22:15 +0100, Magnus Hagander wrote:
>> On Wed, Nov 25, 2009 at 22:07, Peter Eisentraut wrote:
>> > On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
>> >> Attached is a patch which adds a chapter to git in ou
On Wed, Nov 25, 2009 at 11:34:35PM -0500, Tom Lane wrote:
> Roger Leigh writes:
> > The following patch adds in an nl_langinfo(CODESET) check in
> > addition to the existing client encoding check.
>
> I think the consensus is pretty clear that we should just set the
> default linestyle to ascii a
When using the "service" parameter in a libpq connection (e.g., psql
service=foo), and the service name is not defined in pg_service.conf,
then the setting is silently ignored and the connection proceeds with
whatever other settings and defaults apply. That does not look very
robust. Shouldn't th
On Thu, Nov 26, 2009 at 5:17 PM, Heikki Linnakangas
wrote:
> Yeah, that needs to be addressed regardless of HS, because you can
> otherwise start up (= fail over to) the standby too early, before the
> minimum recovery point has been reached.
Okey, I address that ASAP.
Regards,
--
Fujii Masao
Fujii Masao wrote:
> On Thu, Nov 26, 2009 at 4:55 PM, Heikki Linnakangas
> wrote:
>> Fujii Masao wrote:
>>> In current SR, since a backup history file is not replicated,
>>> the standby always starts an archive recovery without a backup
>>> history file, and a wrong minRecoveryPoint might be used.
On Thu, Nov 26, 2009 at 4:55 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> In current SR, since a backup history file is not replicated,
>> the standby always starts an archive recovery without a backup
>> history file, and a wrong minRecoveryPoint might be used. This
>> is not a problem f
44 matches
Mail list logo
