On Tue, 2009-11-24 at 09:24 +0200, Heikki Linnakangas wrote:
> Greg Smith wrote:
> > Heikki Linnakangas wrote:
> >> So I guess what I'm asking is: Does anyone see any show-stoppers in
> >> removing VACUUM FULL
> > Here's the disclaimers attached to the new VACUUM REPLACE implementation
> > from Ita
Teodor Sigaev wrote:
> we'd like to present contrib module for CVS HEAD, which contains
> implementation of knn (k nearest neighbourhood) search in PostgreSQL,
> see README.knngist for
> details.
Cool!
> Old way:
> SELECT coordinates, (coordinates <-> '5.0,5.0'::point) AS dist FROM spots
> order
Greg Smith wrote:
> Heikki Linnakangas wrote:
>> So I guess what I'm asking is: Does anyone see any show-stoppers in
>> removing VACUUM FULL
> Here's the disclaimers attached to the new VACUUM REPLACE implementation
> from Itagaki:
>
> "We still need traditional VACUUM FULL behavior for system cat
Itagaki Takahiro wrote:
> VACUUM FULL is still reserved for system catalogs in my patch
> because we cannot modify relfilenodes for the catalog tables.
> Do you have solutions for it?
Tom had an idea on that:
http://archives.postgresql.org/message-id/19750.1252094...@sss.pgh.pa.us
--
Heikki L
>> * Can we use error messages that looks like existing privilege errors?
>>ERRCODE_INSUFFICIENT_PRIVILEGE:
>> => permission denied to rename database
>
> Here is a point that we should provide users a hint which enables
> to make clear the reason of access violations. So, I think we shou
Hi,
>> What would probably be helpful here is to take the mess of raw data
>> above and turn it into a simpler partitioning roadmap.
>
> Thanks for summarising.
>
Yeah, excellent summary Greg. As you rightly pointed out, partitioning
needs a broad roadmap so that the community can contribute in u
Itagaki Takahiro wrote:
> I'm reviewing SE-PgSQL patch and have some comments.
> https://commitfest.postgresql.org/action/patch_view?id=212
>
> Forgive me, but I'm a novice of SELinux. Some of the comments
> and question might be nonsense.
Itagaki-san, thanks for your volunteering so much!
> ===
2009/11/24 Caleb Cushing :
>> CREATE OR REPLACE FUNCTION emptystr(text)
>> RETURNS bool AS $$
>> SELECT $1 <> ''; -- it is SQL not C
>> $$ LANGUAGE sql;
>>
>> CREATE TABLE users(
>> username TEXT CHECK (NOT emptystr(username)),
>
> although I'm not going to continue discussing the request. this c
Tom Lane wrote:
> What we need first is an explicit representation of partitioning, and
> then to build routing code on top of that. I haven't looked at
> Itagaki-san's syntax patch at all, but I think it's at least starting
> in a sensible place.
I have the following development plan for part
Caleb,
I can understand why you want this. However, it would be tricky to
implement because of data typing, and is fairly easily worked around
using either domains or functions. So I don't think anyone is going to
want to add it to the TODO list, sorry.
Of course, Postgres is fully hackable if
Andrew Dunstan wrote:
> I mean it should be in the Explain output:
> http://www.postgresql.org/2009/explain";>
> SELECT '' AS zero, BOOLTBL1.*
> A number of users (including me) badly want to be able to extract the
> explain output from the log files with the query text included.
I s
Itagaki Takahiro wrote:
Andrew Dunstan wrote:
Basically it includes the text of the query being explained in the
explain output.
I expected the query text is printed in "STATEMENT" section.
Do you mean the query should be merged into "LOG" section?
Are there any situation where "ST
I'm reviewing SE-PgSQL patch and have some comments.
https://commitfest.postgresql.org/action/patch_view?id=212
Forgive me, but I'm a novice of SELinux. Some of the comments
and question might be nonsense.
Patch overview
The patch itself is large (>13K), but more than half of it are
wel
Greg Smith wrote:
I haven't heard anything from Andrew about ragged CVS import either.
I think that ultimately those features are useful, but just exceed
what the existing code could be hacked to handle cleanly.
The patch is attached for your edification/amusement. I have backpatched
it t
> CREATE OR REPLACE FUNCTION emptystr(text)
> RETURNS bool AS $$
> SELECT $1 <> ''; -- it is SQL not C
> $$ LANGUAGE sql;
>
> CREATE TABLE users(
> username TEXT CHECK (NOT emptystr(username)),
although I'm not going to continue discussing the request. this code
as the opposite desired effect. i
Tom Lane wrote:
Those discussions don't have a lot of credibility if they didn't take
place on the public mailing lists.
You know how people complain about how new contributors are treated
here? Throwing out comments like this, that come off as belittling to
other people's work, doesn't hel
Jeff Janes wrote:
> Just a quick note: this patch does not apply cleanly to HEAD due to
> the subsequent removal from explain.c of the near-by lines:
Thanks for reporting.
The attached patch is rebased to current CVS.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
explain_bu
Heikki Linnakangas wrote:
> So I guess what I'm asking is: Does anyone see any show-stoppers in
> removing VACUUM FULL, and does anyone want to step up to the plate and
> promise to do it before release?
I'm working on "New VACUUM FULL" patch, that shrinks tables
using CLUSTER-like rewrites.
ht
Tom Lane wrote:
> > [ TRIGGER WHEN patch ]
> Applied with assorted revisions. AFAICT the system column issue is only
> a problem for NEW references in BEFORE triggers --- those columns do
> read correctly in OLD, and all the time in AFTER triggers. I revised
> the parsing logic to enforce that
On 23/11/2009 11:35 PM, Tom Lane wrote:
> Andrew Gierth writes:
>> "Tom" == Tom Lane writes:
>> Tom> Well, that's pretty much exactly the question --- are there? It
>> Tom> would certainly make it easier for someone to exploit any other
>> Tom> security weakness they might find.
>
>> Loops i
Andrew Dunstan wrote:
> Basically it includes the text of the query being explained in the
> explain output.
I expected the query text is printed in "STATEMENT" section.
Do you mean the query should be merged into "LOG" section?
Are there any situation where "STATEMENT" section does not work?
On Mon, Nov 23, 2009 at 4:20 PM, Tom Lane wrote:
> pgsql-hackers had some preliminary discussions a couple months back
> on refactoring COPY to allow things like this --- see the thread
> starting here:
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg00486.php
> While I don't think we ar
Greg Smith writes:
> Robert Haas wrote:
>> I'm fuzzy on what problem this is attempting to solve... as mentioned
>> in the above guidelines, it's usually good to start with some design
>> discussions before writing/submitting code.
> This has been through some heavy design discussions with a few
On Mon, Nov 23, 2009 at 4:03 PM, Daniel Farina wrote:
> Yes. Take a look at the tests introduced to core PostgeSQL (see patch
> 2), where instead of returning a text[] I return just a single text of
> the verbatim output of the copy. You could imagine making that an SRF
> instead. It would have
On Mon, Nov 23, 2009 at 3:46 PM, Andrew Dunstan wrote:
> I recently found myself trying to push data through dblink() and ended up
> writing code to make a call to the target to call a function which called
> back to the source to select the data and insert it. The speedup was
> massive, so I'll b
Greg Smith wrote:
Robert Haas wrote:
I'm fuzzy on what problem this is attempting to solve... as mentioned
in the above guidelines, it's usually good to start with some design
discussions before writing/submitting code.
This has been through some heavy design discussions with a few PG
hacker
On Mon, Nov 23, 2009 at 2:16 PM, Robert Haas wrote:
> On Mon, Nov 23, 2009 at 4:34 PM, Daniel Farina wrote:
>> Signed-off-by: Daniel Farina
>
> Thanks for the patch. You may want to take a look at this:
>
> http://wiki.postgresql.org/wiki/Submitting_a_Patch
>
> I'm fuzzy on what problem this is
Robert Haas wrote:
I'm fuzzy on what problem this is attempting to solve... as mentioned
in the above guidelines, it's usually good to start with some design
discussions before writing/submitting code.
This has been through some heavy design discussions with a few PG
hackers you know and some y
On Mon, Nov 23, 2009 at 4:34 PM, Daniel Farina wrote:
> Signed-off-by: Daniel Farina
Thanks for the patch. You may want to take a look at this:
http://wiki.postgresql.org/wiki/Submitting_a_Patch
I'm fuzzy on what problem this is attempting to solve... as mentioned
in the above guidelines, it
Signed-off-by: Daniel Farina
---
contrib/dblink/expected/dblink.out | 272
contrib/dblink/sql/dblink.sql | 112 +++
2 files changed, 384 insertions(+), 0 deletions(-)
diff --git a/contrib/dblink/expected/dblink.out
b/contrib/dblink/expecte
On ons, 2009-11-18 at 01:39 -0200, Euler Taveira de Oliveira wrote:
> I noticed that some example functions don't contain the magic block and that
> leads to error while loading those examples in 8.2 or later.
>
> Attached is a patch that adds it. I also add some missing header file. Don't
> have
This relatively small change enables all sort of new and shiny evil by
allowing specification of a function to COPY that accepts each
produced row's content in turn. The function must accept a single
INTERNAL-type argument, which is actually of the type StringInfo.
Patch highlights:
- Grammar
Signed-off-by: Daniel Farina
---
src/test/regress/input/copy.source | 38 +++
src/test/regress/output/copy.source | 69 +++
src/test/regress/regress.c | 56
3 files changed, 163 insertions(+), 0 deletions
This patch enables dblink to be used for the purpose of efficient
bulk-loading via COPY and libpq in combination with the COPY TO
FUNCTION patch.
The following functions were added to accomplish this:
dblink_connection_reset: useful when handling errors and one just
wants to restore a connection
I have extended COPY to support using a UDF as a target instead of the
normal 'file' or STDOUT targets. This dovetails nicely with a couple
of extensions I have also written for dblink for the purposes of
enabling direct cross-node bulk loading and replication. Please
peruse the patches (the non-
On mån, 2009-11-23 at 12:50 -0500, Caleb Cushing wrote:
> and domains
> only seem right if it's something, like a zip code, that has a very
> specific set of rules, that is in reality it's own type.
A domain is not really its own type, it's a domain over its base type.
Hence the name.
> where
> s
Hi,
I'd like to improve the way PL/Perl handles arrays as function input
parameters. In PL/Perl arrays are passed as plain text strings, and getting a
value of an array element requires additional perl code to parse that string.
I'd like to make this easier by converting each postgresq array pa
2009/11/23 Caleb Cushing :
> On Mon, Nov 23, 2009 at 4:17 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> do you know domains? It is very similar to your proposal.
>>
>
> obviously since I cited it.
>
>> constraint cannot be part of expression.
>>
> why not? NOT NULL is a contraint, UNIQUE is a conts
On Thu, Oct 15, 2009 at 3:29 AM, Itagaki Takahiro
wrote:
>
> Robert Haas wrote:
>
>> In this case, I think that the auto_explain changes out to be part of
>> the same patch as the core EXPLAIN changes
>
> Here is a rewritten patch to add EXPLAIN (ANALYZE, BUFFERS) and
> support for it by contrib/
> "Tom" == Tom Lane writes:
>> Loops in plain SQL are no problem: see generate_series. The last
>> time we discussed this I demonstrated reasonably straightforward
>> SQL examples of how to do things like password-cracking (and that
>> was long before we had CTEs, so it would be even easi
On Mon, Nov 23, 2009 at 4:17 AM, Pavel Stehule wrote:
> Hello
>
> do you know domains? It is very similar to your proposal.
>
obviously since I cited it.
> constraint cannot be part of expression.
>
why not? NOT NULL is a contraint, UNIQUE is a contstraint.
> CREATE OR REPLACE FUNCTION emptys
Hi there,
http://www.sigaev.ru/misc/knngist-0.11.tar.gz
we'd like to present contrib module for CVS HEAD, which contains implementation
of knn (k nearest neighbourhood) search in PostgreSQL, see README.knngist for
details. KNNGiST is an extension of existing GiST, which inherits most of
their
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
I'm thinking that the most appropriate fix is to have pg_regress
continue to use -w, but only on Windows.
Well, the filter could be as simple as something like this in the
Makefile for the mingw case:
On Mon, 2009-11-23 at 12:23 -0500, Greg Smith wrote:
> What would probably be helpful here is to take the mess of raw data
> above and turn it into a simpler partitioning roadmap.
Thanks for summarising.
I briefly tried to do that on the thread for Itagaki-san's patch. That's
a first stab at
Simon Riggs wrote:
...Read my detailed comments in response to Kedar's patch and post
comments on that thread to say you didn't agree with that proposal and
that you were thinking of another way entirely.
Useful background here is:
http://wiki.postgresql.org/wiki/Table_partitioning
http://archi
Simon Riggs writes:
> Anyway, I want data routing, as is the intention of this patch. I just
> don't think this patch is a useful way to do it. It is too narrow in its
> scope and potentially buggy in its approach to developing a cache and
> using trigger-like stuff.
FWIW, I agree --- there are
2009/11/23 Teodor Sigaev :
> point <@ box
> point <@ polygon
> point <@ circle
I've always wondered why we didn't have these
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
On Mon, 2009-11-23 at 10:43 -0500, Emmanuel Cecchet wrote:
> Simon Riggs wrote:
> > I was unaware you were developing these ideas and so was unable to
> > provide comments until now.
> The first patch was published to this list on September 10 (almost 2.5
> months ago) along with the wiki page d
Andrew Dunstan writes:
> Tom Lane wrote:
>> I'm thinking that the most appropriate fix is to have pg_regress
>> continue to use -w, but only on Windows.
> Well, the filter could be as simple as something like this in the
> Makefile for the mingw case:
> perl -spi.bak -e 's/(? rm expecte
Tom Lane wrote:
Magnus Hagander writes:
On Mon, Nov 23, 2009 at 06:58, Andrew Dunstan wrote:
They might not be using the same CVS programs, though. It appears that
Windows CVS (which, for example, red_bat uses) translates line endings to
CRLF, which is why it passed the regression t
On Mon, 2009-11-23 at 10:24 -0500, Emmanuel Cecchet wrote:
> I think there is a misunderstanding between what Simon wants
> ('Anyway, I want data routing, as is the intention of this patch.') and
> what this patch is about. This patch is just supposed to load tuples in
> a hierarchy of tables a
Simon Riggs wrote:
I was unaware you were developing these ideas and so was unable to
provide comments until now.
The first patch was published to this list on September 10 (almost 2.5
months ago) along with the wiki page describing the problem and the
solution.
What should I have done to rai
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Well, that's pretty much exactly the question --- are there? It
> Tom> would certainly make it easier for someone to exploit any other
> Tom> security weakness they might find.
> Loops in plain SQL are no problem: see generate_series.
On Mon, 2009-11-23 at 09:39 -0500, Emmanuel Cecchet wrote:
> I think you should read the thread and the patch
I did read the thread and patch in full before posting. My opinions are
given to help you and the community towards a desirable common goal.
I was unaware you were developing these idea
On Mon, 2009-11-23 at 09:39 -0500, Emmanuel Cecchet wrote:
> I think you should read the thread and the patch
I did read the thread and patch in full before posting. My opinions are
given to help you and the community towards a desirable common goal.
I was unaware you were developing these idea
Tom Lane wrote:
Thom Brown writes:
As for having plpgsql installed by default, are there any security
implications?
Well, that's pretty much exactly the question --- are there? It would
certainly make it easier for someone to exploit any other security
weakness they might find. I
Robert Haas wrote:
On Mon, Nov 23, 2009 at 9:39 AM, Emmanuel Cecchet wrote:
I think you should read the thread and the patch before making any false
statements like you did in your email.
1. The patch does not use any trigger for routing.
Whoa, whoa! I don't think that Simon said th
> "Tom" == Tom Lane writes:
> Thom Brown writes:
>> As for having plpgsql installed by default, are there any security
>> implications?
Tom> Well, that's pretty much exactly the question --- are there? It
Tom> would certainly make it easier for someone to exploit any other
Tom> secur
2009/11/23 Tom Lane
> Thom Brown writes:
> > As for having plpgsql installed by default, are there any security
> > implications?
>
> Well, that's pretty much exactly the question --- are there? It would
> certainly make it easier for someone to exploit any other security
> weakness they might
On Mon, Nov 23, 2009 at 9:39 AM, Emmanuel Cecchet wrote:
> I think you should read the thread and the patch before making any false
> statements like you did in your email.
>
> 1. The patch does not use any trigger for routing.
Whoa, whoa! I don't think that Simon said that it did. But even if
Simon,
I think you should read the thread and the patch before making any false
statements like you did in your email.
1. The patch does not use any trigger for routing.
2. This is just an option for COPY that is useful for loading operations
in the datawarehouse world. It is not meant to imp
Thom Brown writes:
> As for having plpgsql installed by default, are there any security
> implications?
Well, that's pretty much exactly the question --- are there? It would
certainly make it easier for someone to exploit any other security
weakness they might find. I believe plain SQL plus SQL
On Sun, Nov 22, 2009 at 11:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane wrote:
>>> CREATE IF NOT EXISTS has been proposed and rejected before, more than
>>> once. Please see the archives.
>
>> Search for CINE to find the discussions. This is a good
Peter Eisentraut writes:
> What is the plan behind keeping the old format? Are we going to remove
> it after one release if no one complains, or are we seriously expecting
> that someone has code that actually parses this?
Plan? Do we need a plan? The extra support consists of about two lines
On Mon, Nov 23, 2009 at 15:23, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Nov 23, 2009 at 06:58, Andrew Dunstan wrote:
>>> They might not be using the same CVS programs, though. It appears that
>>> Windows CVS (which, for example, red_bat uses) translates line endings to
>>> CRLF, whic
Magnus Hagander writes:
> On Mon, Nov 23, 2009 at 06:58, Andrew Dunstan wrote:
>> They might not be using the same CVS programs, though. It appears that
>> Windows CVS (which, for example, red_bat uses) translates line endings to
>> CRLF, which is why it passed the regression tests, but MinGW CVS
Hi!
patch implements operator class for GiST over points. Supported operations:
point << point
point >> point
point <^ point
point >^ point
point ~= point
point <@ box
box @> point
point <@ polygon
polygon @> point
point <@ circle
circle @> point
--
Teodor Sigaev
Hi there,
attached is a patch, which contains implementation of a red-black
tree, a self-balanced implementation of binary tree. The main goal of
this patch is to improve creation time of GIN index in the corner cases.
While creation, GIN collects data in memory in binary tree until it
reach s
Thanks, applied!
//Magnus
2009/11/23 Hiroshi Saito :
> Hi.
>
> Only for CVS-HEAD, not need backpatch.
> I checked REL8_4_STABLE is this.
> ==
> nmake -f win32.mak
> ...
> Microsoft (R) Manifest Tool version 5.2.3790.2076
> Copyright (c) Microsoft Corporation 2005.
> All rights reserved.
> c
On Mon, Nov 23, 2009 at 06:58, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>
>>>
>>> Tom Lane wrote:
>>>
Remove -w (--ignore-all-space) option from pg_regress's diff calls.
>>
>>
>>>
>>> Looks like this has broken on Windows due to different line endin
On Wed, 2009-11-11 at 19:53 -0500, Emmanuel Cecchet wrote:
> Hi,
> >> I have extracted the partitioning option for COPY (removed the error
> >> logging part) from the previous patch.
> >>
> >
> > We can use an INSERT trigger to route tuples into partitions even now.
> > Why do you need an add
2009/11/23 Tom Lane
> CREATE OR REPLACE has got far safer semantics from the viewpoint of a
> script that wants to bull through without having any actual error
> handling (which is more or less the scenario we are arguing here, no?)
> After successful execution of the command you know exactly wha
Hello
do you know domains? It is very similar to your proposal.
http://www.postgresql.org/docs/8.2/static/sql-createdomain.html
Regards
Pavel Stehule
2009/11/23 Caleb Cushing :
> So last time I checked this wasn't possible (at least not that anyone
> has told me). I'd like to be able to create
So last time I checked this wasn't possible (at least not that anyone
has told me). I'd like to be able to create constraints that aren't
tied to a specific table/column.
I think that the syntax would look something like this
CREATE CONSTRAINT empty CHECK (VALUE = '\0' );
this should allow us to
On sön, 2009-11-22 at 00:23 -0500, Tom Lane wrote:
> Roger Leigh writes:
> > Attached is an updated patch with a couple of tweaks to ensure output
> > is formatted and spaced correctly when border=0, which was off in the
> > last patch.
>
> Applied wih minor editorialization. Notably, I renamed
75 matches
Mail list logo
