2009/11/26 Teodor Sigaev :
> 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 ar
On Wed, 2009-12-30 at 00:00 -0500, Robert Haas wrote:
> I generally agree with those
> ideas, although I think that trying to make the existing aggregate
> interface serve this purpose will probably turn out to be trying to
> make a square peg fit a round hole.
I didn't think that they intended to
On Wed, Dec 30, 2009 at 12:56 AM, Daniel Farina wrote:
> On Tue, Dec 29, 2009 at 9:46 PM, Robert Haas wrote:
>> Sure. If you think you can make it work using bytea, that seems
>> clearly better than using an internal type, all things being equal.
>
> I think both are perfectly viable and can be
On Tue, Dec 29, 2009 at 9:46 PM, Robert Haas wrote:
> Sure. If you think you can make it work using bytea, that seems
> clearly better than using an internal type, all things being equal.
I think both are perfectly viable and can be supported simultaneously,
actually...I simply like INTERNAL bec
On Wed, Dec 30, 2009 at 12:26 AM, Daniel Farina wrote:
> I think you may be right about this, so we could basically move most
> things from the COPY option list into a new DDL option list...I am
> more ambivalent, but it seems that would require a catalog, and so on,
> which is why I did not leap
On Tue, Dec 29, 2009 at 9:11 PM, Robert Haas wrote:
> I think we should try to put an interface layer in place in the first
> iteration. I don't really see this as having much value without that.
> If we implement this strictly as a series of COPY options, we're
> going to be committed to suppor
On Tue, Dec 29, 2009 at 11:47 PM, Daniel Farina wrote:
> On Tue, Dec 29, 2009 at 8:11 PM, Robert Haas wrote:
>> It might be possible to do this without introducing a notion of an
>> explicit object, but there are a couple of problems with that. First,
>> it requires the user to specify a lot of
Hi Tom-san.
Um, How do you consider sample which cannot build?
Regards,
Hiroshi Saito
- Original Message -
From: "Tom Lane"
"Hiroshi Saito" writes:
test/example does not support win32.
The proposed added #includes seem quite inappropriate. postgres_fe.h
is meant for PG-proj
On Tue, Dec 29, 2009 at 11:44 PM, Jeff Davis wrote:
> On Tue, 2009-12-29 at 23:11 -0500, Robert Haas wrote:
>> I fear that to make this really useful we would need to define some
>> new SQL syntax, like:
>>
>> CREATE [OR REPLACE] COPY TARGET name (STARTUP function_name, STREAM
>> function_name, SH
"Hiroshi Saito" writes:
> test/example does not support win32.
The proposed added #includes seem quite inappropriate. postgres_fe.h
is meant for PG-project code, it is not supposed to have to be included
by all end-user code.
regards, tom lane
--
Sent via pgsql-hackers
Hi.
test/example does not support win32.
Although I posted also in the past, I am slightly persistent.
I think whether it also needs correction of a document.
== CVS-HEAD on as for MinGW + gcc ==
testlibpq2.c: In function `main':
testlibpq2.c:98: error: `fd_set' undeclared (first use in this
On Tue, Dec 29, 2009 at 8:11 PM, Robert Haas wrote:
> It might be possible to do this without introducing a notion of an
> explicit object, but there are a couple of problems with that. First,
> it requires the user to specify a lot of details on every COPY
> invocation, which is awkward. Second
On Tue, 2009-12-29 at 23:11 -0500, Robert Haas wrote:
> I fear that to make this really useful we would need to define some
> new SQL syntax, like:
>
> CREATE [OR REPLACE] COPY TARGET name (STARTUP function_name, STREAM
> function_name, SHUTDOWN function_name);
> DROP COPY TARGET name;
> GRANT USA
Rod Taylor writes:
> With the update_process_title parameter set to off some PostgreSQL
> processes still change their ps title to a different name than the
> default.
s/some/all/ ... they all do that. It's as designed. The parameter is
intended to suppress the overhead of changing the title fo
On Tue, Dec 22, 2009 at 3:27 AM, Takahiro Itagaki
wrote:
> Cedric Villemain wrote:
>> Le vendredi 18 decembre 2009 09:44:40, Takahiro Itagaki a ecrit :
>> > I'd like to add per-query buffer usage into contrib/pg_stat_statements.
>
> Here is a patch to add buffer usage columns into pg_stat_stateme
On Tue, Dec 29, 2009 at 9:56 PM, Daniel Farina wrote:
> On Tue, Dec 29, 2009 at 6:48 PM, Robert Haas wrote:
>> I think there's clear support for a version of COPY that returns rows
>> like a SELECT statement, particularly for use with CTEs. There seems
>> to be support both for a mode that retur
On Tue, 2009-12-29 at 21:48 -0500, Robert Haas wrote:
> Anyway, my specific reaction to your suggestions in the email that I
> quoted is that it seems a bit baroque and that I'm not really sure
> what it's useful for in practice. I'm certainly not saying it ISN'T
> useful, because I can't believe
With the update_process_title parameter set to off some PostgreSQL
processes still change their ps title to a different name than the
default. I appreciate this setting came about for performance reasons
which the logger, wal writer, autovacuum, and stats collector would
not have but I actually req
Jeff Davis wrote:
> On Tue, 2009-12-29 at 11:50 -0600, Kevin Grittner wrote:
> > Would you be able to help with the development in any way?
>
> Yes, I'd be willing to invest some time.
>
> For an area of active research such as this, I obviously can't promise
> much in the way of results. But I c
Josh Berkus writes:
> My thoughts on dealing with this intelligently without a major change to
> statstics gathering went along these lines:
> 1. add columns to pg_statistic to hold estimates of upper and lower
> bounds growth between analyzes.
This seems like a fundamentally broken approach, fi
On Tue, Dec 29, 2009 at 6:48 PM, Robert Haas wrote:
> I think there's clear support for a version of COPY that returns rows
> like a SELECT statement, particularly for use with CTEs. There seems
> to be support both for a mode that returns text[] or something like it
> and also for a mode that re
All,
One of our clients is having query plan issues with a table with a
continuously advancing timestamp column (i.e. one with default now()).
The newest rows, which are the most in demand, are always estimated to
be fewer than they are or even non-existant. As a result, the user has
to analyze t
On Tue, Dec 29, 2009 at 9:23 PM, Daniel Farina wrote:
> On Tue, Dec 29, 2009 at 5:57 PM, Robert Haas wrote:
>> I am very fuzzy on where we stand with this patch. There's a link to
>> the initial version on the commitfest application, but there has been
>> so much discussion since then that I thi
2009/12/30 Tom Lane :
> Hitoshi Harada writes:
>> I found the struct IntArray defined in c.h is actually used only in
>> execQual.c. ISTM the definition should be at least moved to the right
>> place.
>
> It's a general-purpose datatype that might be used anywhere that array
> indexing happens. I
Hi,
I try to build msvc version of postgres using the current cvs and
get the following error.
Unable to determine vcbuild version from first line of output! at
src/tools/msvc/Solution.pm line 70.
The error comes from the following output of vcbuild /? in my
environment.
Microsoft(R) Visu
On Tue, Dec 29, 2009 at 5:57 PM, Robert Haas wrote:
> I am very fuzzy on where we stand with this patch. There's a link to
> the initial version on the commitfest application, but there has been
> so much discussion since then that I think there are probably some
> revisions to be made, though I
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yep. It would also lower the barrier to future innovations of that
>> type, which would be a good thing, IMO. Unfortunately we'd likely
>> need to continue to support the existing syntax at least for
>> attstattarget, whi
On Fri, Dec 18, 2009 at 4:39 PM, Peter Eisentraut wrote:
> On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote:
>> On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler
>> wrote:
>> > On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
>> >
>> >> Should we create a json type before adding all kin
Robert Haas writes:
> Yep. It would also lower the barrier to future innovations of that
> type, which would be a good thing, IMO. Unfortunately we'd likely
> need to continue to support the existing syntax at least for
> attstattarget, which is kind of a bummer, but seems managable. I
> think
On Tue, Dec 29, 2009 at 8:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> Having separate properties for regular attdistinct and inherited
>> attdistinct seems fairly worthwhile, but I share your lack of
>> enthusiasm for solving the problem by adding more columns to
>> pg_attribute. One possibi
On Sat, Dec 5, 2009 at 3:32 AM, Daniel Farina wrote:
> On Mon, Nov 30, 2009 at 12:14 PM, Greg Smith wrote:
>> Jeff Davis wrote:
>>
>> COPY target FROM FUNCTION foo() WITH RECORDS;
>>
>>
>> In what format would the records be?
>
> As a not-quite aside, I think I have a better syntax suggestion. I
Robert Haas writes:
> Having separate properties for regular attdistinct and inherited
> attdistinct seems fairly worthwhile, but I share your lack of
> enthusiasm for solving the problem by adding more columns to
> pg_attribute. One possibility would be to create a new system catalog
> to hold "
2009/12/16 KaiGai Kohei :
> It is a patch for the matter which I reported before.
>
> When a column is inherited from multiple relations, ALTER TABLE with
> RENAME TO option is problematic.
> This patch fixes the matter. In correctly, it prevent to rename columns
> inherited from multiple relations
On Mon, Dec 28, 2009 at 3:22 AM, Robert Haas wrote:
> I have scrutinized the latest version of this patch and I feel that it
> is a modest improvement on the status quo and that there is really no
> downside. Absent strong objections, I will commit it later this week.
Committed.
...Robert
--
On Tue, Dec 29, 2009 at 3:32 PM, Tom Lane wrote:
> I wrote:
>> Following up on the discussion here
>> http://archives.postgresql.org/message-id/4b3875c602250002d...@gw.wicourts.gov
>> I'd like to propose making the following changes that would allow saner
>> planning for queries involving inhe
I wrote:
> 3. Ideally autovacuum would know enough to perform ANALYZEs on
> inheritance parents after enough churn has occurred in their child
> table(s). I am not entirely clear about a good way to do that.
> We could have it just directly force an ANALYZE on parent(s) of any
> table it has chose
On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On Tuesday 29 December 2009 16:22:54 Tom Lane wrote:
> >> This seems like a fairly bad idea. One of the intended use-cases is to
> >> be able to manually "kill -INT" a misbehaving backend. Assuming that
> >> there wil
On Tue, 2009-12-29 at 14:14 +0100, Joachim Wieland wrote:
> haven't received a reply on it yet.
Apologies for that. I replied today, just forgot to hit send until now.
Thanks again for the patch.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hac
On Thu, 2009-12-24 at 21:38 +0100, Joachim Wieland wrote:
> On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane wrote:
> > We are using NOTICE, not NOTIFY, assuming that we use anything at all
> > (which I still regard as unnecessary). Please stop injecting confusion
> > into the discussion.
>
> Attached i
I wrote:
> Following up on the discussion here
> http://archives.postgresql.org/message-id/4b3875c602250002d...@gw.wicourts.gov
> I'd like to propose making the following changes that would allow saner
> planning for queries involving inheritance:
I've committed the easy aspects of this (still
hello
here is patch
pa...@postgres:5432=# \set foo 'hello world'
pa...@postgres:5432=# SELECT :'foo' AS :"foo";
hello world
-
hello world
(1 row)
Regards
Pavel
2009/12/29 Pavel Stehule :
> 2009/12/29 Tom Lane :
>> Pavel Stehule writes:
>>> 2009/12/29 Alvaro Herrera :
Can we
2009/12/29 Tom Lane :
> Pavel Stehule writes:
>> 2009/12/29 Alvaro Herrera :
>>> Can we use a trick similar to pg_dump's?
>
>> I see it - we can move function (content) fmtId from dumputils.c to libpq.
>
> This is not a good idea. pg_dump can be expected to be up-to-date with
> the backend's keyw
Pavel Stehule writes:
> 2009/12/29 Alvaro Herrera :
>> Can we use a trick similar to pg_dump's?
> I see it - we can move function (content) fmtId from dumputils.c to libpq.
This is not a good idea. pg_dump can be expected to be up-to-date with
the backend's keyword list, but libpq cannot.
Just
2009/12/29 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/12/29 Alvaro Herrera :
>> > Pavel Stehule escribió:
>> >> 2009/12/29 Tom Lane :
>> >> > Pavel Stehule writes:
>> >> >> so we cannot simply implement quote_ident on client side :(. So we
>> >> >> have to use a real query.
>> >> >
>> >> >
Pavel Stehule escribió:
> 2009/12/29 Alvaro Herrera :
> > Pavel Stehule escribió:
> >> 2009/12/29 Tom Lane :
> >> > Pavel Stehule writes:
> >> >> so we cannot simply implement quote_ident on client side :(. So we
> >> >> have to use a real query.
> >> >
> >> >> It is acceptable for you?
> >> >
> >
2009/12/29 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/12/29 Tom Lane :
>> > Pavel Stehule writes:
>> >> so we cannot simply implement quote_ident on client side :(. So we
>> >> have to use a real query.
>> >
>> >> It is acceptable for you?
>> >
>> > No, certainly not --- that adds a boatlo
2009/12/29 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/12/29 Tom Lane :
>> > Pavel Stehule writes:
>> >> so we cannot simply implement quote_ident on client side :(. So we
>> >> have to use a real query.
>> >
>> >> It is acceptable for you?
>> >
>> > No, certainly not --- that adds a boatlo
Pavel Stehule escribió:
> 2009/12/29 Tom Lane :
> > Pavel Stehule writes:
> >> so we cannot simply implement quote_ident on client side :(. So we
> >> have to use a real query.
> >
> >> It is acceptable for you?
> >
> > No, certainly not --- that adds a boatload of failure conditions.
> > Just quo
2009/12/29 Tom Lane :
> Pavel Stehule writes:
>> so we cannot simply implement quote_ident on client side :(. So we
>> have to use a real query.
>
>> It is acceptable for you?
>
> No, certainly not --- that adds a boatload of failure conditions.
> Just quote it unconditionally.
ok
this function
On Dec 29, 2009, at 8:57 AM, Pavel Stehule
wrote:
Hello
I am working on new patch. I see a problem with copy quote_ident on
client side. This function call ScanKeywordLookup function.
const ScanKeyword *keyword = ScanKeywordLookup(ident,
Sc
On Tue, 2009-12-29 at 11:50 -0600, Kevin Grittner wrote:
> Would you be able to help with the development in any way?
Yes, I'd be willing to invest some time.
For an area of active research such as this, I obviously can't promise
much in the way of results. But I can help explore and implement
de
Pavel Stehule writes:
> so we cannot simply implement quote_ident on client side :(. So we
> have to use a real query.
> It is acceptable for you?
No, certainly not --- that adds a boatload of failure conditions.
Just quote it unconditionally.
regards, tom lane
--
Sent
On Monday 28 December 2009 23:59:43 Andres Freund wrote:
> On Monday 28 December 2009 23:54:51 Andres Freund wrote:
> > On Saturday 12 December 2009 21:38:41 Andres Freund wrote:
> > > On Saturday 12 December 2009 21:36:27 Michael Clemmons wrote:
> > > > If ppl think its worth it I'll create a tick
Jeff Davis wrote:
> On Mon, 2009-12-28 at 11:54 -0600, Kevin Grittner wrote:
>> Serializable transaction isolation is attractive for shops with
>> active development by many programmers against a complex schema
>> because it guarantees data integrity with very little staff time
>
> I would like t
Hello
I am working on new patch. I see a problem with copy quote_ident on
client side. This function call ScanKeywordLookup function.
const ScanKeyword *keyword = ScanKeywordLookup(ident,
ScanKeywords,
NumSc
Andres Freund writes:
> On Tuesday 29 December 2009 16:22:54 Tom Lane wrote:
>> This seems like a fairly bad idea. One of the intended use-cases is to
>> be able to manually "kill -INT" a misbehaving backend. Assuming that
>> there will be valid info about the signal in shared memory will break
On Tuesday 29 December 2009 16:22:54 Tom Lane wrote:
> Joachim Wieland writes:
> > If we use the same signal for both cases, the receiving backend cannot
> > tell what the intention of the sending backend was. That's why I
> > proposed to make SIGINT similar to SIGUSR1 where we write a reason to
>
Florian G. Pflug wrote:
> I believe the hard part of implementing true serializability is
> not the actual SSI or S2PL algorithm, but rather the necessary
> predicate locking strategy.
>
> So I think checking how InnoDB tackles that and how much of it's
> code is invovled might give a more reali
matt wrote:
We are trying to gather statistics about our queries and get automatic
suggestions for what indexes to utilize ...its easier to figure that on queries
that are in some format else we have to effectively parse the queries ourself
or hack the postgresql parser...which we dont want to
Hitoshi Harada writes:
> I found the struct IntArray defined in c.h is actually used only in
> execQual.c. ISTM the definition should be at least moved to the right
> place.
It's a general-purpose datatype that might be used anywhere that array
indexing happens. I think the fact that it's curren
Simon Riggs writes:
> On Mon, 2009-12-28 at 17:41 -0500, Tom Lane wrote:
>> 2. When ANALYZE is invoked on a table that has inheritance children,
>> it will perform its normal duties for just that table (creating or
>> updating entries with stainherit = false) and then perform a second
>> scan that
Alvaro Herrera writes:
> But it would be broken in very obvious ways, no? It's not like it would
> be silently broken and thus escape testing ...
Well, if we wanted to adopt that approach, we should add the count to
*all* SELECT tags not just a small subset. As the patch stands it
seems entirel
Joachim Wieland writes:
> If we use the same signal for both cases, the receiving backend cannot
> tell what the intention of the sending backend was. That's why I
> proposed to make SIGINT similar to SIGUSR1 where we write a reason to
> a shared memory structure first and then send the signal (se
2009/12/29 matt :
>
>
> --- On Mon, 12/28/09, Andres Freund wrote:
>
>> From: Andres Freund
>> Subject: Re: [HACKERS] parse tree to XML format
>> To: pgsql-hackers@postgresql.org
>> Cc: "Robert Haas" , "matt"
>> Date: Monday, December 28, 2009, 7:39 PM
>> On Tuesday 29 December 2009 01:35:25
>>
--- On Mon, 12/28/09, Andres Freund wrote:
> From: Andres Freund
> Subject: Re: [HACKERS] parse tree to XML format
> To: pgsql-hackers@postgresql.org
> Cc: "Robert Haas" , "matt"
> Date: Monday, December 28, 2009, 7:39 PM
> On Tuesday 29 December 2009 01:35:25
> Robert Haas wrote:
> > On Mon,
On Tuesday 29 December 2009 15:30:00 matt wrote:
> --- On Mon, 12/28/09, Andres Freund wrote:
> > From: Andres Freund
> > Subject: Re: [HACKERS] parse tree to XML format
> > To: pgsql-hackers@postgresql.org
> > Cc: "Robert Haas" , "matt"
> > Date: Monday, December 28, 2009, 7:39 PM
> > On Tuesda
Tom Lane escribió:
> Boszormenyi Zoltan writes:
> > Tom Lane �rta:
> >> It's more the possibility of doing strcmp(tag, "SELECT") on the command
>
> > Actually it's strncmp(tag, "SELECT ", 7), so when you mix old server
> > with new clients or new server with old client, it will just work as
> > b
Mark Cave-Ayland wrote:
> The attached patch is a prototype which allows the user to specify a
> new MODULEDIR variable in a module makefile which, if specified,
> will install DATA and DOCS items in contrib/$(MODULEDIR) rather than
> just contrib. If MODULEDIR is left unspecified, the files will
On Sun, Dec 27, 2009 at 10:42 PM, Simon Riggs wrote:
> Thanks for the report. I'll see about a fix.
In the end we are about to use SIGINT for two use cases:
- cancel an idle transaction
- cancel a running query
Previously a backend that was DoingCommandRead == true didn't do
anything upon rec
Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
> Le 28/12/2009 22:59, Tom Lane a écrit :
>> Guillaume Lelarge writes:
>>> Le 28/12/2009 17:06, Tom Lane a écrit :
I think we were stalled on the question of whether to use one array
or two parallel arrays. Do you want to try coding up a
Hi all,
Since moving PostGIS over to PGXS for the 1.4 release, we've been
looking at how we can support multiple versions of PostGIS being
installed in different databases within the same cluster.
We are able to version the .so file produced by PGXS without too much
difficulty, however PGXS
On Tue, 2009-12-29 at 12:42 +0100, Magnus Hagander wrote:
> 2009/12/28 Josh Rovero :
> > Has anyone built postgresql (or just libpq.a) on Windows SFU/SUA?
> > Would prefer to not reinvent any wheels
>
> Not that I know of.
>
> Can't you use the native win32 libpq.dll? IIRC I read somewhere th
2009/12/28 Josh Rovero :
> Has anyone built postgresql (or just libpq.a) on Windows SFU/SUA?
> Would prefer to not reinvent any wheels
Not that I know of.
> We have a number of Unix/Linux applications that are also compiled
> under Microsoft Windows SFU 3.5. We need to have a SFU-compatible
On Tuesday 29 December 2009 11:48:10 Greg Stark wrote:
> On Tue, Dec 29, 2009 at 2:05 AM, Andres Freund wrote:
> > Reads Completed:2,8KiB Writes Completed: 2362,
> > 29672KiB New:
> > Reads Completed:0,0KiB Writes Completed: 550,
> > 5960KiB
>
>
2009/12/29 Tarun Sharma :
> hi
>
> when a superuser is logged in to the postgres server ,he has priveledge to
> access all the databases.
>
> can we hide the structure of some of the databases from the superuser?
> like if he gives command to open such a database the postgres may ask for
> access
hi
when a superuser is logged in to the postgres server ,he has priveledge to
access all the databases.
can we hide the structure of some of the databases from the superuser?
like if he gives command to open such a database the postgres may ask for
access password again.
as in Oracle Database
On Tue, Dec 29, 2009 at 2:05 AM, Andres Freund wrote:
> Reads Completed: 2, 8KiB Writes Completed: 2362,
> 29672KiB
> New:
> Reads Completed: 0, 0KiB Writes Completed: 550,
> 5960KiB
It looks like the new method is only doing 1/6th as much i/o. Do
On Tue, 2009-12-15 at 11:17 +0900, Takahiro Itagaki wrote:
> Simon Riggs wrote:
>
> > I have enough items emerging from HS to keep me busy much longer than I
> > thought. I'll run with VF if that's OK, since I have some other related
> > changes in that area and it makes sense to understand that
On Mon, 2009-12-28 at 17:41 -0500, Tom Lane wrote:
> Following up on the discussion here
> http://archives.postgresql.org/message-id/4b3875c602250002d...@gw.wicourts.gov
> I'd like to propose making the following changes that would allow saner
> planning for queries involving inheritance:
Sou
I found the struct IntArray defined in c.h is actually used only in
execQual.c. ISTM the definition should be at least moved to the right
place.
Attached is a trivial fix. Addition to the explanation above, I
replaced IntArray by simple int array bounded with MAXDIM and remove
local variable lInd
On Mon, Dec 28, 2009 at 12:10 PM, Tom Lane wrote:
> Boszormenyi Zoltan writes:
>> attached is a small patch that makes it possible for clients
>> to receive row count for SELECT ... INTO ... and CREATE TABLE ... AS ...
>
>> Comments?
>
> This doesn't look tremendously well thought out to me.
>
>
81 matches
Mail list logo
