Eric Ridge <ebr@tcdi.com> writes:
> 1) Is it possible for an access method to receive some kind of "DROP
> INDEX" notification?
No.
> select * from test where stuff => 'stuff' AND NOT more_stuff =>
> '"drink beer"';
> has this plan:
To do better here, you'd need to invent a "not-=>' operator, so that the
above could be simplified to, say,
select * from test where stuff => 'stuff' AND more_stuff ~=> '"drink beer"';
and then define both => and ~=> as members of your index opclass, and
then build a two-column index on (stuff, more_stuff) ... whereupon
the planner would pass your index AM both clauses and it would be up
to you to do something intelligent. You might want to back off a little
on how much of this you really want to do in a first cut.
> 3) How does one get the $PGDATA directory?
DataDir. Why should you care? An index AM that wants to know this is
probably broken IMHO; it's certainly trying to do something that's
outside the charter of index AMs, and is likely to cause lots of
headaches.
> 4) Can a function be registered as part of a transaction, pre-commit --
> so the function can have an opportunity to abort the transaction.
Why would that be a good idea? When exactly would you expect it to be
called (relative to the other ninety-nine things that happen at commit)?
How are you going to recover if something else aborts the transaction,
either before or after your function runs?
I get the impression from your questions that you are trying to make an
end run around the transaction mechanism. This is almost certainly
doomed to failure. You need to find a way of storing all your data
within the ordinary index structure.
regards, tom lane