Re: Backend-internal SPI operations
От | Jan Wieck |
---|---|
Тема | Re: Backend-internal SPI operations |
Дата | |
Msg-id | 200008301152.GAA05287@jupiter.jw.home обсуждение исходный текст |
Ответ на | Re: Backend-internal SPI operations (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > "Mark Hollomon" <mhh@nortelnetworks.com> writes: > > Just out of curiousity, is there technical reason there isn't > > a (say) relisview attribute to pg_class? > > That might indeed be the most reasonable way to attack it, rather > than having to go messing about looking for a matching rule. > (Jan, any thoughts here?) The right way IMHO would be to give views another relkind. Then we could easily 1. detect if the final query after rewriting still tries to INSERT/UPDATE/DELETE a view - i.e. "missing rewrite rule(s)". 2. disable things like LOCK etc. The problem here is, that the relkind must change at rule creation/drop time. Fortunately rules on SELECT aretotally restricted to VIEW's since 6.4, and I don't see any reason to change this. And it's time to make more use of the relkind attribute. For 7.2, when we want to have tuple-set returns for functions,we might want to have structures as well (we talked about that already, Tom). A structure is just a row/typedescription. A function, returning a tuple or set of tuples, can return this type or set of type as well asany other existing table/view structure. So to create a function returning a set of tuples, which have a structuredifferent from any existing table, someone creates a named structure, then the function returningtuples of that type. These structures are just entries in pg_class, pg_attribute and pg_type. There isno file or any rules, triggers etc. attached to them. They just describe a typle that can be built in memory. > Adding a column to a core system table like pg_class is a good > exercise for the student ;-) ... it's not exactly automated, > and you have to find all the places that need to be updated. > You might want to keep notes and prepare a writeup for the > developer's FAQ. I thought of that the last time I did something > similar, but it was only at the end that I realized I should've > been keeping notes to start with. Meetoo :-} Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: