RE: Raw constraint & pg_relcheck.rcsrc

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: Raw constraint & pg_relcheck.rcsrc
Date: 2000-08-04 00:02:33
Message-ID: 000201bffda7$4a427ba0$2801007e@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue(at)tpf(dot)co(dot)jp]
>
> > -----Original Message-----
> > From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> >
> > "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > > Is pg_relcheck.rcsrc equivalent to the original raw constraint ?
> >
> > To the best of deparse_expression()'s ability, it should be.
> > I'm not real sure why we bother to store it, rather than deparsing
> > rcbin on-the-fly on demand...
> >
>
> I'm looking at DefineRelation() in commands/creartinh.c.
> In case of inheritance,constraints of super classes are
> stored using their pg_relcheck.rcbin-s. It seems bad
> in case of multiple inheritance. rcsrc-s may be available
> instead.
>

Oops,I've been completely off the point.
The raw expression of constraints seems to be really needed.

Is there any way to convert rcbin(cooked text format) to the
raw(pre-cooked) Node expression ? Or is there a way to
convert rcsrc to the pre-cooked Node expression ?
Or is there a way to convert rcsrc to the cooked expression ?

Here's a simple bug case.

=# create table p1 (id int4);
CREATE
=# create table p2 (dt text check (dt = 'a'));
CREATE
=# create table inh () inherits (p1,p2);
CREATE
=# \d inh
Table "inh"
Attribute | Type | Modifier
-----------+---------+----------
id | integer |
dt | text |
Constraint: (id = 'a'::text)

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Bitmead 2000-08-04 00:21:28 Re: Anyone particularly wedded to func_tlist mechanism?
Previous Message Bruce Momjian 2000-08-03 23:22:40 Re: Anyone particularly wedded to func_tlist mechanism?