Re: Backend-internal SPI operations

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 #

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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