Is this all addresssed?
> On Sat, 14 Jul 2001, Tom Lane wrote:
>
> > ... however, if you want to do some of the legwork yourself, here are
> > the ideas I had about what to do:
>
> OK. We'll dig into problem in august. At least we'll try.
> How many possible problems would arise after changing
On Sat, 14 Jul 2001, Tom Lane wrote:
> ... however, if you want to do some of the legwork yourself, here are
> the ideas I had about what to do:
OK. We'll dig into problem in august. At least we'll try.
How many possible problems would arise after changing of pg_opclass ?
Does existing code will
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> How many possible problems would arise after changing of pg_opclass ?
> Does existing code will handle this change somewhat automagically
> or we have to find and modify relevant code ?
There's a fair amount of code that would need to be touched. One t
> Note that this doesn't address Oleg's concerns about haskeytype,
> lossiness, etc. AFAICS those issues are not related to the contents
> of pg_am. Later on, I am going to have some proposals for altering
> pg_opclass and related tables to deal with those issues...
>
> Comments? Any other fest
... however, if you want to do some of the legwork yourself, here are
the ideas I had about what to do:
pg_opclass should have, not just one row for each distinct opclass name,
but one row for each supported combination of index AM and opclass name.
Doing it this way would allow us to put additio
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> Any chance you'd untie a knot for our development in 7.2 development
> cycle ?
I am trying to focus on getting concurrent VACUUM done, because I think
that's a "must do" for 7.2. I hope to have some time during August to
deal with your GIST issues, but
On Fri, 13 Jul 2001, Tom Lane wrote:
> Since I am about to add a "bulk delete" routine to the index access
> method APIs for concurrent VACUUM, I need to add a column to pg_am
> to define the associated procedure for each index AM. This seems like
> a fine time to clean up some of the other outs
Since I am about to add a "bulk delete" routine to the index access
method APIs for concurrent VACUUM, I need to add a column to pg_am
to define the associated procedure for each index AM. This seems like
a fine time to clean up some of the other outstanding TODO items for
pg_am:
1. Add boolean
