From: | Jan Wieck <janwieck(at)Yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Hollomon <mhh(at)nortelnetworks(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Backend-internal SPI operations |
Date: | 2000-08-30 11:52:37 |
Message-ID: | 200008301152.GAA05287@jupiter.jw.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> "Mark Hollomon" <mhh(at)nortelnetworks(dot)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 are totally
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/type description. A
function, returning a tuple or set of tuples, can return this
type or set of type as well as any other existing table/view
structure. So to create a function returning a set of tuples,
which have a structure different from any existing table,
someone creates a named structure, then the function
returning tuples of that type. These structures are just
entries in pg_class, pg_attribute and pg_type. There is no
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(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Hollomon | 2000-08-30 12:18:02 | Re: disallow LOCK on a view - the Tom Lane remix |
Previous Message | Alfred Perlstein | 2000-08-30 05:05:11 | Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Hollomon | 2000-08-30 12:18:02 | Re: disallow LOCK on a view - the Tom Lane remix |
Previous Message | Alfred Perlstein | 2000-08-30 05:05:11 | Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix |