On Sun, Feb 14, 2010 at 12:24 PM, Tom Lane wrote:
> Robert Haas 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 id
Robert Haas 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 arguments.
Also, I'd sugg
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 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
> something into contri
On Sat, Feb 13, 2010 at 3:58 PM, Tom Lane wrote:
> Robert Haas 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
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.
I
Tom Lane writes:
> Teodor Sigaev 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 th
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 numbe
Robert Haas 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 will be broken by t
On Sat, Feb 13, 2010 at 2:38 PM, Tom Lane wrote:
> Hitoshi Harada 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 least, to be applied
now. I actuall
Robert Haas writes:
> On Sat, Feb 13, 2010 at 3:02 PM, Tom Lane 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_VER
On Sat, Feb 13, 2010 at 3:02 PM, Tom Lane 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 < something
> #define
Robert Haas writes:
> On Sat, Feb 13, 2010 at 2:03 PM, Joshua Tolley 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 that requires changes to all kinds
Hitoshi Harada 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 changes to your subsc
2010/2/14 Robert Haas :
> 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 similar; but that's n
2010/2/14 Tom Lane :
> Teodor Sigaev 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
On Sat, Feb 13, 2010 at 2:03 PM, Joshua Tolley 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 wrote:
>> > Teodor Sigaev writes:
>> >> I see your point. May be it's better to introduce new system table?
>> >> pg_amorderop
>> >>
On Sat, Feb 13, 2010 at 01:31:44PM -0500, Robert Haas wrote:
> On Sat, Feb 13, 2010 at 1:28 PM, Tom Lane wrote:
> > Teodor Sigaev 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
Teodor Sigaev 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 category
of opc
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
On Fri, Feb 12, 2010 at 10:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane wrote:
>>> Robert Haas 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
>>>
Robert Haas writes:
> On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane wrote:
>> Robert Haas 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 the strategy number and the high 16 bits as the
On Fri, Feb 12, 2010 at 10:10 PM, Tom Lane wrote:
> Robert Haas 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 in
Robert Haas 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?
regards, tom lane
--
Se
On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 becomes moot.
On Fri, Feb 12, 2010 at 9:10 PM, Robert Haas wrote:
> On Fri, Feb 12, 2010 at 7:30 PM, Tom Lane 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, a
On Fri, Feb 12, 2010 at 7:30 PM, Tom Lane 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 ranges are a
Robert Haas 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 returning bool,
>
On Fri, Feb 12, 2010 at 3:44 PM, Oleg Bartunov 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 save
> neigh
On Fri, Feb 12, 2010 at 3:44 PM, Oleg Bartunov 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 no fair or
On Fri, 12 Feb 2010, Robert Haas wrote:
2010/2/11 Oleg Bartunov :
> On Thu, 11 Feb 2010, Robert Haas wrote:
>
>> On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov wrote:
version I saw hadn't any documentation whatever. =A0It's not committab=
le
on documentation grounds alone, even i
2010/2/11 Oleg Bartunov :
> On Thu, 11 Feb 2010, Robert Haas wrote:
>
>> On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov 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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Feb 11, 2010 at 03:19:14PM +0100, Dimitri Fontaine wrote:
> Robert Haas 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 he
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
t
On Thu, 11 Feb 2010, Greg Stark wrote:
On Thu, Feb 11, 2010 at 1:18 PM, Robert Haas 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,
On Thu, 11 Feb 2010, Robert Haas wrote:
On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov 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 p
On Thu, Feb 11, 2010 at 1:18 PM, Robert Haas 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 match what I'v
Robert Haas 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 getting more
and more f
On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov 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 documen
On Thu, Feb 11, 2010 at 3:38 AM, Oleg Bartunov 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 paid
> you
On Thu, 11 Feb 2010, Robert Haas wrote:
2010/2/11 Oleg Bartunov :
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 we
On Thu, 11 Feb 2010, Tom Lane wrote:
Oleg Bartunov 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
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
2010/2/11 Oleg Bartunov :
> 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
Oleg Bartunov 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 reviewing the pa
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
-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. Sa
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 m
49 matches
Mail list logo
