Dimitri Fontaine wrote:
Then there's the metric space which is a data type with a distance
function. This function must be non-negative, commutative, etc.
So I guess what we need here is a Operator Group to define our plus and
minus operators, and the fact that it's a group says (by convention,
Robert Haas robertmh...@gmail.com writes:
OK. In that case, any objections to my applying the attached patch,
which I believe implements this as you suggested?
Um, did you test this version? It looks like the macros are still
defined according to the idea that SearchSysCache takes five
On Sun, Feb 14, 2010 at 12:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
OK. In that case, any objections to my applying the attached patch,
which I believe implements this as you suggested?
Um, did you test this version? It looks like the macros are
However, that does make it even uglier to have category shoehorned in as
part of a different field. Back to wanting 5-key syscaches ...
Sigh.
I see your point. May be it's better to introduce new system table? pg_amorderop
to store ordering operations for index.
--
Teodor Sigaev
Teodor Sigaev teo...@sigaev.ru writes:
I see your point. May be it's better to introduce new system table?
pg_amorderop
to store ordering operations for index.
We could, but that approach doesn't scale to wanting more categories
in the future --- you're essentially decreeing that every new
On Sat, Feb 13, 2010 at 01:31:44PM -0500, Robert Haas wrote:
On Sat, Feb 13, 2010 at 1:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Teodor Sigaev teo...@sigaev.ru writes:
I see your point. May be it's better to introduce new system table?
pg_amorderop
to store ordering operations for index.
On Sat, Feb 13, 2010 at 2:03 PM, Joshua Tolley eggyk...@gmail.com wrote:
On Sat, Feb 13, 2010 at 01:31:44PM -0500, Robert Haas wrote:
On Sat, Feb 13, 2010 at 1:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Teodor Sigaev teo...@sigaev.ru writes:
I see your point. May be it's better to introduce
2010/2/14 Tom Lane t...@sss.pgh.pa.us:
Teodor Sigaev teo...@sigaev.ru writes:
I see your point. May be it's better to introduce new system table?
pg_amorderop
to store ordering operations for index.
We could, but that approach doesn't scale to wanting more categories
in the future ---
2010/2/14 Robert Haas robertmh...@gmail.com:
If we want to allow 5-key syscaches, we have to add an extra parameter
to SearchSysCache and friends. So everyone caller of SearchSysCache
is going to break. (Well, unless we instead leave SearchSysCache
alone and add SearchSysCacheExtended or
Hitoshi Harada umi.tan...@gmail.com writes:
And we don't have time to invent such new world.
Huh? This is all discussion for 9.1 (or even later). There's
plenty of time.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 13, 2010 at 2:03 PM, Joshua Tolley eggyk...@gmail.com wrote:
(Realizing I'm a lurker in this conversation, and hoping not to ask
irritating
questions) Do we need to rename SearchSysCache et al. to SearchSysCache1,
etc.? It seems to me
On Sat, Feb 13, 2010 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What would probably be the recommended solution for backwards-compatible
source code is to convert the actual calls to new style, and then
provide a block of macro definitions along the lines of
#if CATALOG_VERSION_NO
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 13, 2010 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What would probably be the recommended solution for backwards-compatible
source code is to convert the actual calls to new style, and then
provide a block of macro definitions along
On Sat, Feb 13, 2010 at 2:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
And we don't have time to invent such new world.
Huh? This is all discussion for 9.1 (or even later). There's
plenty of time.
Just to be clear, I was intending this patch, at
Robert Haas robertmh...@gmail.com writes:
Just to be clear, I was intending this patch, at least, to be applied
now. I actually think there's a good argument that we should do at
least this much for 9.0, namely that now is probably the time when
there are the fewest outstanding patches that
Reflecting on it, it seems to me that the separate SearchSysCacheN()
macros are obviously cleaner and closer to preferred project style than
the existing code with all those explicit zeroes. So I think there's
a case for migrating to that style even if we didn't have a concern
about the max
Tom Lane t...@sss.pgh.pa.us writes:
Teodor Sigaev teo...@sigaev.ru writes:
I see your point. May be it's better to introduce new system table?
pg_amorderop
to store ordering operations for index.
We could, but that approach doesn't scale to wanting more categories
in the future --- you're
On Sat, 2010-02-13 at 13:28 -0500, Tom Lane wrote:
If we didn't already have the plus/minus-for-WINDOW-RANGE example
staring us in the face, I might think that an extensible solution
wasn't needed here ... but we do so I think we really need to allow
for multiple categories in some form.
Is
On Sat, Feb 13, 2010 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Just to be clear, I was intending this patch, at least, to be applied
now. I actually think there's a good argument that we should do at
least this much for 9.0, namely that now is
Robert Haas robertmh...@gmail.com writes:
...
2. Modify pg_amop by adding a new column amopcategory, probably either
int2 or maybe even just char.
...
I'm not prepared to endorse doing #3 in core for 9.0, but I wonder if
it would be feasible to think about doing #1 and #2 and putting
2010/2/11 Oleg Bartunov o...@sai.msu.su:
On Thu, 11 Feb 2010, Robert Haas wrote:
On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov o...@sai.msu.su wrote:
version I saw hadn't any documentation whatever. It's not committable
on documentation grounds alone, even if everybody was satisfied about
On Fri, 12 Feb 2010, Robert Haas wrote:
2010/2/11 Oleg Bartunov o...@sai.msu.su:
On Thu, 11 Feb 2010, Robert Haas wrote:
On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov o...@sai.msu.su wrote:
version I saw hadn't any documentation whatever. =A0It's not committab=
le
on documentation
On Fri, Feb 12, 2010 at 3:44 PM, Oleg Bartunov o...@sai.msu.su wrote:
This is not fair,Robert. Everything was discussed in -hackers.I assume
reviewer
should follow discussion at least, he is a member of our community. Mailing
list archive was/is/will our the best knowledge base.
Dude, there's
On Fri, Feb 12, 2010 at 3:44 PM, Oleg Bartunov o...@sai.msu.su wrote:
We tried to find compromise for 9.0 (Tom suggests contrib module), but all
variants are ugly and bring incompatibility in future. If there are no
hackers
willing/capable to review our patches, then, please, help us how to
Robert Haas robertmh...@gmail.com writes:
Tom remarked in another email that he wasn't too happy with the
opclass changes. They seem kind of grotty to me, too, but I don't
immediately have a better idea. My fear is that there may be places
in the code that rely on opclass operators only ever
On Fri, Feb 12, 2010 at 7:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe a more general idea would be to invent categories of opclass
members, where the only existing category is index search qualifier,
and these new knngist thingies are another, and maybe plus and minus for
window function
On Fri, Feb 12, 2010 at 9:10 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Feb 12, 2010 at 7:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe a more general idea would be to invent categories of opclass
members, where the only existing category is index search qualifier,
and these new
Robert Haas robertmh...@gmail.com writes:
Well, if you were willing to change pg_amop so that the key was
(amopfamily, amoplefttype, amoprighttype, amopcategory) rather than
just (amopfamily, amoplefttype, amoprighttype), the issue of what to
do if an operator can be in more than one category
On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, if you were willing to change pg_amop so that the key was
(amopfamily, amoplefttype, amoprighttype, amopcategory) rather than
just (amopfamily, amoplefttype, amoprighttype), the
Robert Haas robertmh...@gmail.com writes:
OK, here's another idea. Let's just add a new column to pg_amop
called amoporderstrategy. If an operator can only be used for one
purpose or the other, we'll set the other value to -1.
... problem for unique index, no?
On Fri, Feb 12, 2010 at 10:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
OK, here's another idea. Let's just add a new column to pg_amop
called amoporderstrategy. If an operator can only be used for one
purpose or the other, we'll set the other value to
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
This is a bit ugly, but one idea that occurs to me is to change
amopstrategy from int16 to int32. Internally, we'll treat the low 16
bits as
On Fri, Feb 12, 2010 at 10:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
This is a bit ugly, but one idea that occurs to me is to change
On Thu, 11 Feb 2010, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su writes:
This is very disgraceful from my point of view and reflects real problem
in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
reworked Nov 25. Long holidays in December-January, probably are reason
On Thu, 11 Feb 2010, Robert Haas wrote:
2010/2/11 Oleg Bartunov o...@sai.msu.su:
This is very disgraceful from my point of view and reflects real problem
in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
reworked Nov 25. Long holidays in December-January, probably are
On Thu, Feb 11, 2010 at 3:38 AM, Oleg Bartunov o...@sai.msu.su wrote:
Robert, please accept my public apology, if you feel I offense you. There
are
nothing against you. Your contribution is very important and I really don't
understand why on the Earth you're not paid ! I remember discussion to
On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov o...@sai.msu.su wrote:
version I saw hadn't any documentation whatever. It's not committable
on documentation grounds alone, even if everybody was satisfied about
the code.
well, there is enough documentation to review patch.
Where is there any
Robert Haas robertmh...@gmail.com writes:
It seems that you're sort of frustrated with the system and the need
to go through a process before committing a patch;
I've been handling arround here for years (since 2005 or before) and I
think there always was a process. The only change is it's
On Thu, Feb 11, 2010 at 1:18 PM, Robert Haas robertmh...@gmail.com wrote:
In my understanding
this was always enough to submit code. User's documentation is depend on
discussion and review and can be added later
before releasing beta.
Several people have said this lately, but it doesn't
On Thu, 11 Feb 2010, Robert Haas wrote:
On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov o...@sai.msu.su wrote:
version I saw hadn't any documentation whatever. It's not committable
on documentation grounds alone, even if everybody was satisfied about
the code.
well, there is enough
On Thu, 11 Feb 2010, Greg Stark wrote:
On Thu, Feb 11, 2010 at 1:18 PM, Robert Haas robertmh...@gmail.com wrote:
In my understanding
this was always enough to submit code. User's documentation is depend on
discussion and review and can be added later
before releasing beta.
Several people
On Thu, 11 Feb 2010, Oleg Bartunov wrote:
On Thu, 11 Feb 2010, Tom Lane wrote:
My own feeling about it is that I much preferred the original proposal
of a contrib module with little or no change to core code. I don't want
to be changing core code for this at this late hour. If it were only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Feb 11, 2010 at 03:19:14PM +0100, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
It seems that you're sort of frustrated with the system and the need
to go through a process before committing a patch;
I've been
Hello,
I noticed this morning that the k nearest neighbor gist patch
https://commitfest.postgresql.org/action/patch_view?id=230 was still being
considered for inclusion in 9. Sadly, this feature appears to have been
dropped from 9.
It seems to me that the functionality this brings is one of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Feb 10, 2010 at 04:49:59PM -0800, Ragi Y. Burhum wrote:
Hello,
I noticed this morning that the k nearest neighbor gist patch
https://commitfest.postgresql.org/action/patch_view?id=230 was still being
considered for inclusion in 9. Sadly,
This is very disgraceful from my point of view and reflects real problem
in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
reworked Nov 25. Long holidays in December-January, probably are reason why
there were no any movement on reviewing the patch. People with
inspiration
Oleg Bartunov o...@sai.msu.su writes:
This is very disgraceful from my point of view and reflects real problem
in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
reworked Nov 25. Long holidays in December-January, probably are reason why
there were no any movement on
2010/2/11 Oleg Bartunov o...@sai.msu.su:
This is very disgraceful from my point of view and reflects real problem
in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
reworked Nov 25. Long holidays in December-January, probably are reason why
there were no any movement on
I have to say that as a 3rd party observer it is quite obvious to
understand why the PostgreSQL software is so good - people are very
passionate about the work they are doing. However, in this instance,
as a by-stander, it seems that there is a lot of energy being spent on
pointing fingers. At the
49 matches
Mail list logo
