Hi,

    while  fixing  the  subselect  parseback  in the new ruleutil
    functions and checking if the output is now what's needed for
    dumping  rules/views  I  came  across  a little detail in the
    parser I'm confused about.

    Having a table

    CREATE TABLE t1 (a char(20));

    the two statements

    INSERT INTO t1 VALUES ('x');

    INSERT INTO t1 VALUES ('x'::bpchar);

    produce mainly the same parsetree (where the const value  'x'
    of  type 1042 is embedded into a call to bpchar(bpchar, int4)
    for the padding).

    But in the first case argument 1 is constbyval  TRUE  and  in
    the  second  one  FALSE (where I feel the second one is right
    for a bpchar const). Seems that it doesn't matter later.

    The ruleutil functions output the typecasting  any  time  and
    this  little  detail makes it harder for me to check if their
    output really recreates all the rules as the original  CREATE
    statements did.

    The  output  from  the  ruleutil functions can differ in many
    cases from the original CREATE commands  (for  'AS  funcname'
    where no one was given and in the subselects area where 'attr
    in (val, val, ...)'  will  be  explicit  OR  list,  'attr  IN
    (SELECT  ...' will be output as 'attr = ANY (SELECT ...'  and
    so on).  But the resulting rules will be the same AFAIK.

    For checking the output to be O.K. I took all the  pg_rewrite
    content from a regression database (plus some more views with
    subselects etc.) into a temp  file,  dropped  all  rules  and
    recreated  them from what pg_rules printed. Then I took again
    all the pg_rewrite content and expected the same (and got  it
    except for the constbyval diffs).

    I'll send in the fixes for ruleutils soon.

    If  someone likes to add dumping rules/views to pg_dump, some
    little background details:

        Views could be nested (one view selects another view). So
        restoring by CREATE VIEW depends on the correct order.

        But  a  view  could  also be recreated by a CREATE TABLE,
        CREATE RULE, UPDATE pg_rewrite sequence.  This  time,  if
        all  the  CREATE  TABLE statements are made first and the
        CREATE RULE ones later, they don't depend on  each  other
        any more.

        The  view  pg_rules  will  (as  mentioned  by  Keith) not
        include view rules any  longer.  So  pg_dump  should  use
        function  pg_get_ruledef()  directly on pg_rewrite to get
        all the rules definitions.

        To reconstruct anything correct it must  be  executed  in
        the following order:

        Step 1: Create all tables and views as regular tables.

        Step  2:  Insert  all  data  (where  tables  that have an
        INSTEAD rule on SELECT named _RET<tablename>  receive  no
        data at all).

        Step  3: Create all rules (except the ones named _RETpg_*
        from system views) and rename the  remaining  _RET*  ones
        from _ret* to _RET* (CREATE RULE converts the rulename to
        lower  case  -  that's  why  the  UPDATE  pg_rewrite   is
        required).

    Inserting  the  data before recreating the rules is necessary
    because rules could fire more actions  on  insert,  and  that
    isn't wanted at reload time.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Mon, 28 Sep 1998 18:56:39 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Little parser question
> Having a table
>     CREATE TABLE t1 (a char(20));
> the two statements
>     INSERT INTO t1 VALUES ('x');
>     INSERT INTO t1 VALUES ('x'::bpchar);
> produce mainly the same parsetree (where the const value  'x'
> of  type 1042 is embedded into a call to bpchar(bpchar, int4)
> for the padding).
> 
> But in the first case argument 1 is constbyval  TRUE  and  in
> the  second  one  FALSE (where I feel the second one is right
> for a bpchar const). Seems that it doesn't matter later.

Without actually looking at the code, I'm pretty sure that the
unspecified constant string in the first insert above is getting
interpreted as a string of type UNKNOWN. Apparently it actually tests
for the length of the string and tries to do a "pass by value" if it can
fit.

I don't see this as being a big win, and if you would find it easier we
could try to track it down and make UNKNOWN a pass by reference always.

btw, the call to bpchar(bpchar,int4) is part of my new type coersion
code; this is the first release that will actually check and truncate
strings as they are being stored into a table. In previous releases
longer strings which were the result of, for example, a concatenation
were not length-checked on storage into the table.

Anyway, let me know what you'd like...

                        - Tom

Tue, 29 Sep 1998 04:30:36 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Little parser question
> Hi,
> 
>     while  fixing  the  subselect  parseback  in the new ruleutil
>     functions and checking if the output is now what's needed for
>     dumping  rules/views  I  came  across  a little detail in the
>     parser I'm confused about.
> 
>     Having a table
> 
>     CREATE TABLE t1 (a char(20));
> 
>     the two statements
> 
>     INSERT INTO t1 VALUES ('x');
> 
>     INSERT INTO t1 VALUES ('x'::bpchar);
> 
>     produce mainly the same parsetree (where the const value  'x'
>     of  type 1042 is embedded into a call to bpchar(bpchar, int4)
>     for the padding).
> 
>     But in the first case argument 1 is constbyval  TRUE  and  in
>     the  second  one  FALSE (where I feel the second one is right
>     for a bpchar const). Seems that it doesn't matter later.

I have just committed a fix for this.  The parse_coerce code was not
setting the constbyval dependent on the type.  There were a few other
places where this was not set properly, and those are fixed now.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


Thu, 1 Oct 1998 18:51:49 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Little parser question