Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group