On Tue, 2011-03-01 at 22:56 +, Simon Riggs wrote:
On Tue, 2011-03-01 at 12:42 -0800, Josh Berkus wrote:
That response is just dodging the hard question, so whatever. Tom's
cleanup is not going to break things, or at least it's going to fix
more than it breaks on net. Sync rep, on
Thanks, Tom !
Oleg
On Wed, 2 Mar 2011, Tom Lane wrote:
Teodor Sigaev teo...@sigaev.ru writes:
[ builtin_knngist_contrib_btree_gist-0.12 patch ]
Applied with some corrections --- mostly, that the upgrade script was
all wet. I added some documentation too.
regards,
Teodor Sigaev teo...@sigaev.ru writes:
[ builtin_knngist_contrib_btree_gist-0.12 patch ]
Applied with some corrections --- mostly, that the upgrade script was
all wet. I added some documentation too.
regards, tom lane
--
Sent via pgsql-hackers mailing list
I did a quick look at this patch. The major problem with it is of
course that it needs to be fixed for the recent extension-related
changes. I transposed the .sql.in changes into additions to
btree_gist--1.0.sql (attached), but haven't really sanity-checked
them beyond checking that the
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 28, 2011 at 2:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Given that it is a contrib module, I personally wouldn't object to it
getting patched later, like during alpha or beta. But somebody's got
to do the work, and I've got a dozen
On Tue, Mar 1, 2011 at 1:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 28, 2011 at 2:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Given that it is a contrib module, I personally wouldn't object to it
getting patched later, like during alpha or
Since we appear to be still holding the commitfest open for Sync Rep,
I guess this ought to get reviewed.
Or else we should close the CommitFest and cut alpha4. Anyone have an
opinion on which way to go?
I think we can give Sync Rep until the 15th, given the pace of work on
it. It is a
On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus j...@agliodbs.com wrote:
Since we appear to be still holding the commitfest open for Sync Rep,
I guess this ought to get reviewed.
Or else we should close the CommitFest and cut alpha4. Anyone have an
opinion on which way to go?
I think we can
On Tue, Mar 1, 2011 at 20:26, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus j...@agliodbs.com wrote:
Since we appear to be still holding the commitfest open for Sync Rep,
I guess this ought to get reviewed.
Or else we should close the CommitFest and cut
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus j...@agliodbs.com wrote:
I think we can give Sync Rep until the 15th, given the pace of work on
it. It is a major feature, and a complicated one.
Sure, but there are other features, major and minor, that we
On Tue, Mar 1, 2011 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus j...@agliodbs.com wrote:
I think we can give Sync Rep until the 15th, given the pace of work on
it. It is a major feature, and a complicated
On Tue, Mar 1, 2011 at 2:38 PM, Magnus Hagander mag...@hagander.net wrote:
Frankly, I think we should be aiming to get a beta out in April, not
another alpha.
That would be good, but in order to get there, +1 for cutting a new
alpha even if syncrep isn't ready for it yet. That way we can at
As I understand it, it requires only the steps described here:
http://wiki.postgresql.org/wiki/Alpha_release_process
That all looks pretty straightforward, assuming you can log into
developer.postgresql.org, which I can't. I think I remember having an
ftp account at some point, but it's
On Tue, Mar 1, 2011 at 2:52 PM, Josh Berkus j...@agliodbs.com wrote:
Ideally, we want to have some binaries/packages for the final alpha.
Those broaden testing considerably.
When we have a version that needs that treatment, we can simply call
it beta1. If it's too half-baked for that, then I
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 1, 2011 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd say that if there's a plausible chance that Sync Rep will be
committable by the end of *this* week (and I mean Friday not Sunday),
I'm willing to wait that long for it. Otherwise,
On 3/1/11 11:58 AM, Tom Lane wrote:
If we do hold up the release, I'll probably go back and reopen the
postgresql_fdw patch as well as btree_gist. So I won't run out of
things to do. But I'm not terribly satisfied with the decision-making
process here.
OK, well, we gave it an extra 15 days,
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 1, 2011 at 2:52 PM, Josh Berkus j...@agliodbs.com wrote:
Ideally, we want to have some binaries/packages for the final alpha.
Those broaden testing considerably.
When we have a version that needs that treatment, we can simply call
it
On Tue, Mar 1, 2011 at 3:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 1, 2011 at 2:52 PM, Josh Berkus j...@agliodbs.com wrote:
Ideally, we want to have some binaries/packages for the final alpha.
Those broaden testing considerably.
When we
On Tue, Mar 1, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 1, 2011 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd say that if there's a plausible chance that Sync Rep will be
committable by the end of *this* week (and I mean
On Tue, 2011-03-01 at 14:26 -0500, Robert Haas wrote:
On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus j...@agliodbs.com wrote:
Since we appear to be still holding the commitfest open for Sync Rep,
I guess this ought to get reviewed.
Or else we should close the CommitFest and cut alpha4.
On Tue, Mar 1, 2011 at 3:01 PM, Josh Berkus j...@agliodbs.com wrote:
On 3/1/11 11:58 AM, Tom Lane wrote:
If we do hold up the release, I'll probably go back and reopen the
postgresql_fdw patch as well as btree_gist. So I won't run out of
things to do. But I'm not terribly satisfied with the
That's still missing the point, which is that the code is unlikely to
be up to our usual standards at that point.
I was talking about when do we close the CF and start building an
alpha, not synch rep particularly. Tom said he wants until Friday
anyway just for some cleanup.
--
On Tue, Mar 1, 2011 at 3:36 PM, Josh Berkus j...@agliodbs.com wrote:
That's still missing the point, which is that the code is unlikely to
be up to our usual standards at that point.
I was talking about when do we close the CF and start building an
alpha, not synch rep particularly. Tom
Robert Haas robertmh...@gmail.com writes:
Bruce has been going through the open items for the past several weeks
(at least) and tells me that he hasn't found very much. I'm not sure
what your thought is on what's required to get us from here to beta,
but I am thinking it could be done in a
That response is just dodging the hard question, so whatever. Tom's
cleanup is not going to break things, or at least it's going to fix
more than it breaks on net. Sync rep, on the other hand, is going to
do the opposite, probably by a large margin.
Well, we need to at least give Simon and
On Tue, Mar 1, 2011 at 3:40 PM, Robert Haas robertmh...@gmail.com wrote:
Sync rep, on the other hand, is going to
do the opposite, probably by a large margin.
Are you sure of that? the code is very centralized and the bugs we
found last week weren't that difficult to address, the prove for
On Tue, Mar 1, 2011 at 4:55 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Tue, Mar 1, 2011 at 3:40 PM, Robert Haas robertmh...@gmail.com wrote:
Sync rep, on the other hand, is going to
do the opposite, probably by a large margin.
Are you sure of that? the code is very centralized and
On Tue, Mar 1, 2011 at 4:58 PM, Robert Haas robertmh...@gmail.com wrote:
So where is the new patch, and the test reports from all the people
who found problems in the last version?
Simon do this in his public repo here:
git://github.com/simon2ndQuadrant/postgres.git
It has been just one day
On Tue, 2011-03-01 at 12:42 -0800, Josh Berkus wrote:
That response is just dodging the hard question, so whatever. Tom's
cleanup is not going to break things, or at least it's going to fix
more than it breaks on net. Sync rep, on the other hand, is going to
do the opposite, probably by
On Fri, Feb 18, 2011 at 1:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
There might be more issues, I haven't read the patch in detail.
But anyway, I'm going to set it to Waiting on Author. I think it
needs at least a day or so's work, and I can't put in that kind of
time on it now.
Since no one
Since no one has stepped up to fix these issues, I have marked this
patch Returned with Feedback.
This is just contrib/btree_GIST, yes?
--
-- Josh Berkus
PostgreSQL Experts Inc.
On Mon, Feb 28, 2011 at 1:53 PM, Josh Berkus j...@agliodbs.com wrote:
Since no one has stepped up to fix these issues, I have marked this
patch Returned with Feedback.
This is just contrib/btree_GIST, yes?
Yes, core KNN was committed by Tom during the November CommitFest.
--
Robert Haas
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 28, 2011 at 1:53 PM, Josh Berkus j...@agliodbs.com wrote:
Since no one has stepped up to fix these issues, I have marked this
patch Returned with Feedback.
This is just contrib/btree_GIST, yes?
Yes, core KNN was committed by Tom during
On Mon, Feb 28, 2011 at 2:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 28, 2011 at 1:53 PM, Josh Berkus j...@agliodbs.com wrote:
Since no one has stepped up to fix these issues, I have marked this
patch Returned with Feedback.
This is just
Teodor Sigaev teo...@sigaev.ru writes:
I've applied all of this, and written documentation for all of it,
Thank you a lot
except for the contrib/btree_gist additions which still need to be
redone for the revised API (and then documented!). My patience ran out
Done, btree_gist is reworked
On Sun, Dec 26, 2010 at 08:13:40PM -0500, Tom Lane wrote:
[ thinks for a bit... ] One reason for having a different structure
would be if we needed to represent abstract semantics for some operators
that couldn't be associated with a btree opclass. This is clearly not
an issue for what RANGE
Martijn van Oosterhout klep...@svana.org writes:
On Sun, Dec 26, 2010 at 08:13:40PM -0500, Tom Lane wrote:
[ thinks for a bit... ] One reason for having a different structure
would be if we needed to represent abstract semantics for some operators
that couldn't be associated with a btree
I've applied all of this, and written documentation for all of it,
Thank you a lot
except for the contrib/btree_gist additions which still need to be
redone for the revised API (and then documented!). My patience ran out
Done, btree_gist is reworked for a new API.
I'm very sorry, but I'm
2010/12/4 Tom Lane t...@sss.pgh.pa.us:
What we have at this point (pending contrib/btree_gist fixes) is
nearest-neighbor searching capability for point columns. And
trigram-based nearest-neighbor for text strings, if you install
contrib/pg_trgm. That doesn't seem like a lot of return for the
Hitoshi Harada umi.tan...@gmail.com writes:
Catching up tonight, I wonder I could propose to add ordering
operators in btree, not in gist, for basic types.
I thought about that for a bit while working on the knngist patch, but
couldn't really see any useful application. In particular, I don't
On Sun, Dec 26, 2010 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
Catching up tonight, I wonder I could propose to add ordering
operators in btree, not in gist, for basic types.
I thought about that for a bit while working on the knngist patch,
2010/12/27 Robert Haas robertmh...@gmail.com:
On Sun, Dec 26, 2010 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
Catching up tonight, I wonder I could propose to add ordering
operators in btree, not in gist, for basic types.
I thought about that
Hitoshi Harada umi.tan...@gmail.com writes:
2010/12/27 Robert Haas robertmh...@gmail.com:
As far as window functions go, we clearly need some kind of type
interface feature, but I am unclear whether we should sandwhich it
into the btree opclass machinery or whether it might be better to
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
2010/9/13 Teodor Sigaev teo...@sigaev.ru:
[updated patch]
I realize I'm repeating myself, but... this patch needs
documentation. It's not optional.
I've applied all of this, and written documentation for all of it,
except
On Wed, Dec 22, 2010 at 8:04 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
2010/9/13 Teodor Sigaev teo...@sigaev.ru:
[updated patch]
I realize I'm repeating myself, but... this patch needs
documentation. It's not optional.
I've
On Sat, 4 Dec 2010, Greg Stark wrote:
On Sat, Dec 4, 2010 at 6:07 PM, Oleg Bartunov o...@sai.msu.su wrote:
We'll sync contrib/btree_gist with current API. Also, we're thinking
about distance for ltree, boxes, circles. I'm not sure about polygons,
though.
So, we'll have rather complete set of
Thanks to all for patience !
We'll sync contrib/btree_gist with current API. Also, we're thinking
about distance for ltree, boxes, circles. I'm not sure about polygons, though.
So, we'll have rather complete set of knn-fied data types.
Oleg
On Sat, 4 Dec 2010, Tom Lane wrote:
Robert Haas
On Sat, Dec 4, 2010 at 6:07 PM, Oleg Bartunov o...@sai.msu.su wrote:
We'll sync contrib/btree_gist with current API. Also, we're thinking
about distance for ltree, boxes, circles. I'm not sure about polygons,
though.
So, we'll have rather complete set of knn-fied data types.
I kind of assumed
Greg Stark gsst...@mit.edu writes:
I kind of assumed the natural client for KNN-gist was the tsearch full
text search indexes handling sorting by relevance. For example if I
search for Postgres DBA I should find documents where those words
appear adjacent first and documents where the two
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Greg Stark gsst...@mit.edu writes:
I kind of assumed the natural client for KNN-gist was the tsearch full
text search indexes handling sorting by relevance. For example if I
search for Postgres DBA I should find documents where those words
Robert Haas robertmh...@gmail.com writes:
2010/9/13 Teodor Sigaev teo...@sigaev.ru:
[updated patch]
I realize I'm repeating myself, but... this patch needs
documentation. It's not optional.
I've applied all of this, and written documentation for all of it,
except for the contrib/btree_gist
On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On balance I'm inclined to leave the unique key as per previous proposal
(with a purpose column) and add the
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm satisfied to say that only one sort order can be associated with a
particular operator in a particular opclass, which is what would be
implied by using AMOP_SEARCH/AMOP_ORDER as
On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm satisfied to say that only one sort order can be associated with a
particular operator in a particular
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It would be the first, because simply assigning another strategy number
only satisfies one of the unique constraints on pg_amop. To allow
arbitrary flexibility here, we would have to
I wrote:
We will probably *also* want to pass these details explicitly to the
index AM, but that doesn't solve the problem that some catalog somewhere
has to say what it is that the opclass can do.
... although having said that, the obvious question is why that catalog
has to be pg_amop.
On Tue, Nov 23, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It would be the first, because simply assigning another strategy number
only satisfies one of the unique
I've done some *very* preliminary review of this patch now. I think
that the way to move forward is to first commit the work surrounding
changes to pg_amop, including suitable changes to CREATE/ALTER OPERATOR
CLASS/FAMILY so that there's a way to put the new info into the table.
The system won't
I wrote:
As far as the syntax of CREATE/ALTER OPERATOR CLASS/FAMILY is concerned,
I like Robert's proposal (OPERATOR ... FOR ORDER or FOR SEARCH) better
than Teodor's, though we don't need the multiple-purposes-per-entry
aspect of it. This is mainly because it looks more easily extensible
if
On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason I bring this up now is that it affects the decision as to
what the unique key for pg_amop ought to be. Instead of having an
enum purpose column, maybe we should consider that the unique key
is (operator oid,
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On balance I'm inclined to leave the unique key as per previous proposal
(with a purpose column) and add the which-sort-order-is-that
information as payload columns that aren't part of
Robert Haas robertmh...@gmail.com writes:
2010/11/12 Teodor Sigaev teo...@sigaev.ru:
My variants informs GiST by SK_ORDER flags and consistentFn looks at
strategy number (strategy numbers are different for different purposes).
Yeah. At ten thousand feet, I think the open design question here
On Sun, Nov 21, 2010 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I haven't spent any time on this patch yet (hope to start looking at it
next week). As for your specific question above, I don't have a big
problem with reusing ScanKey this way, but I do agree that using
RestrictInfo for
Robert Haas robertmh...@gmail.com writes:
That doesn't seem very hard on its face. The trick is what to do with
that information once you've got it. As far as I can tell, you need
to drill some kind of hole that lets you pass additional details
about the desired sort order to the index AM.
2010/11/12 Teodor Sigaev teo...@sigaev.ru:
Slightly-more-fleshed out proof of concept patch attached, with actual
syntax, documentation, and pg_dump support added. This might be
thought of as a subset of the builtin_knngist_core patch, without the
parts that make it actually do something
Robert, it is great you are taking this on. This is really a well-known
area of the code for you, but not so much for Teodor and Oleg, so I am
sure they appreciate your assistance.
---
Robert Haas wrote:
On Sat, Oct 16,
Slightly-more-fleshed out proof of concept patch attached, with actual
syntax, documentation, and pg_dump support added. This might be
thought of as a subset of the builtin_knngist_core patch, without the
parts that make it actually do something useful (which is mostly
match_pathkey_to_index -
2010/10/22 Teodor Sigaev teo...@sigaev.ru:
You can define the additional argument as providing all of the extra
info about how the operator is being used, and, if it's being used for
ordering, the details of the requested order. What is your thinking
on the matter?
Maby be useful, but it
You can define the additional argument as providing all of the extra
info about how the operator is being used, and, if it's being used for
ordering, the details of the requested order. What is your thinking
on the matter?
Maby be useful, but it seems to me to be a bit overengineering for now.
On Mon, Oct 18, 2010 at 04:13:04PM +0100, Mark Cave-Ayland wrote:
David Fetter wrote:
For my vote, I'd prefer either the Oid of a custom type or an array
of Oid, Datum pairs - i.e. something we can extend in the future if
required.
This sounds a lot like a foreign key to another table.
3) 3-rd boolean column (amopopr, amopfamily, amoporder)
- could be two records per operator
+ operator could be used in both roles
+ strategy number could be different for different roles
How can #3 work at all? It's ignoring a couple of critical index
columns. In particular, I
Thinking about it that way, perhaps we could add an integer column
amop_whats_it_good_for that gets used as a bit field. That wouldn't
require changing the index structure, although it might break some
other things.
OPERATOR strategy_number ( op_type [ , op_type ] ) [ FOR { SEARCH |
ORDER }
combination of parameters is one that it can handle. I'm thinking
perhaps in lieu of a boolean, we can add another indexam method which,
if not InvalidOid, gets called when we're wondering about whether a
given clause is something that the index can order by. Although
knngist focuses on a the
2010/10/19 Teodor Sigaev teo...@sigaev.ru:
Thinking about it that way, perhaps we could add an integer column
amop_whats_it_good_for that gets used as a bit field. That wouldn't
require changing the index structure, although it might break some
other things.
OPERATOR strategy_number (
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive enough beast that just having 64-bits would make me
happy. As a general matter though, a bytea?
P
For my vote, I'd prefer either the Oid of a custom type or an array of
Oid, Datum pairs - i.e.
On Mon, Oct 18, 2010 at 11:41:06AM +0100, Mark Cave-Ayland wrote:
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive enough beast that just having 64-bits would make me
happy. As a general matter though, a bytea?
P
For my vote, I'd prefer
David Fetter wrote:
For my vote, I'd prefer either the Oid of a custom type or an array
of Oid, Datum pairs - i.e. something we can extend in the future if
required.
This sounds a lot like a foreign key to another table. Are you not
proposing doing that because of performance considerations?
On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive enough beast that just having 64-bits would make me
happy. As a general matter though, a bytea?
P
For my vote, I'd prefer
On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive enough beast that just having 64-bits would make me
happy.
On mån, 2010-10-18 at 15:36 -0400, Robert Haas wrote:
On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive
On Mon, Oct 18, 2010 at 3:40 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-10-18 at 15:36 -0400, Robert Haas wrote:
On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
Paul Ramsey wrote:
So what
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 18, 2010 at 3:40 PM, Peter Eisentraut pete...@gmx.net wrote:
Frankly, I have no idea what knngist has to do with any of this, as I
haven't followed that topic at all.
Me neither, except for the fact that the PostGIS guys are interested
in
On Fri, Oct 15, 2010 at 08:45:26PM -0400, Robert Haas wrote:
But I'm also not sure how far this gets us with KNNGIST, where the
issue is not the typmods but the auxilliary information about the
context of the sort and/or whether this is a sort or qual.
ISTM there are two issues here. With
(And, if we are going to break everything
in sight, now would be a good time to think about changing typmod to
something more flexible than one int32.)
As someone who is jamming geometry type, spatial reference number and
dimensionality into said 32bit typmod, let me say emphatically ...
On lör, 2010-10-16 at 09:23 -0700, Paul Ramsey wrote:
(And, if we are going to break everything
in sight, now would be a good time to think about changing typmod to
something more flexible than one int32.)
As someone who is jamming geometry type, spatial reference number and
On Sat, Oct 16, 2010 at 10:17 AM, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-10-16 at 09:23 -0700, Paul Ramsey wrote:
(And, if we are going to break everything
in sight, now would be a good time to think about changing typmod to
something more flexible than one int32.)
As
On Sat, Oct 16, 2010 at 6:13 PM, Paul Ramsey pram...@cleverelephant.ca wrote:
On Sat, Oct 16, 2010 at 10:17 AM, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-10-16 at 09:23 -0700, Paul Ramsey wrote:
(And, if we are going to break everything
in sight, now would be a good time to
On Fri, Oct 15, 2010 at 9:39 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 15, 2010 at 8:45 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 15, 2010 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps we should think of pg_amop not so much
as a way to tell the AM what to
On Fri, Oct 15, 2010 at 7:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I still feel vaguely uneasy about the fact that the proposed patch
can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit
more last night when I read Peter's patch to
forward. Tom and I laid out a technical design back in January and I
still think it's a good one, even though I know you think it's silly.
We may just have to agree to disagree on this point.
As I remember, there were several suggested designs:
1) 5-th boolean column (amopfamily,
Teodor Sigaev teo...@sigaev.ru writes:
As I remember, there were several suggested designs:
1) 5-th boolean column (amopfamily, amoplefttype, amoprighttype,
amopstrategy,
amoporder) to point kind of operator (search or order)
+ saves one record for operator in pg_amop
- operator
On Fri, Oct 15, 2010 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, have we discussed the idea of embedding the role in the strategy
number? For example, require regular operators to have strategy
numbers 1-, while ordering operators have numbers 1-1,
leaving room for a
On Fri, Oct 15, 2010 at 5:35 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 15, 2010 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, have we discussed the idea of embedding the role in the strategy
number? For example, require regular operators to have strategy
numbers 1-,
Robert Haas robertmh...@gmail.com writes:
I still feel vaguely uneasy about the fact that the proposed patch
can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit
more last night when I read Peter's patch to add collation support.
Good point.
We could possibly cram ASC/DESC
On Fri, Oct 15, 2010 at 7:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I still feel vaguely uneasy about the fact that the proposed patch
can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit
more last night when I read Peter's patch to
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 15, 2010 at 7:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, we cannot avoid changing pg_amop, or at least changing its
interpretation, because the current scheme simply can't represent
indexable operators that are used for anything except
On Fri, Oct 15, 2010 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps we should think of pg_amop not so much
as a way to tell the AM what to do, but just a way to tell it what
operator is logically involved without relying on the name or OID.
I already think of it that way ...
OK.
On Fri, Oct 15, 2010 at 8:45 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 15, 2010 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps we should think of pg_amop not so much
as a way to tell the AM what to do, but just a way to tell it what
operator is logically involved without
Robert,
Are you sure postgres doesn't have limitation at all ? There are a lot ot them.
Of course, there are limitation and limitation and we should avoid limitations,
which will require incompatible changes in future in user's code, or which
prevent future improvements (getting rid
On Tue, Oct 5, 2010 at 5:05 PM, Oleg Bartunov o...@sai.msu.su wrote:
Are you sure postgres doesn't have limitation at all ? There are a lot ot
them. Of course, there are limitation and limitation and we should avoid
limitations, which will require incompatible changes in future in user's
code,
1 - 100 of 113 matches
Mail list logo
