Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types
Date
Msg-id CAFj8pRA9nLzFq9upEQ6XQoZL_SBvoJsDPokDVvDuP37ULekTNQ@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types  (Artur Zakirov <a.zakirov@postgrespro.ru>)
List pgsql-hackers
Hi



2015-12-21 16:21 GMT+01:00 Artur Zakirov <a.zakirov@postgrespro.ru>:
Hi.
I have tried to do some review of this patch. Below are my comments.

Introduction:

This patch fixes and adds the following functionality:
- %TYPE - now can be used for composite types.
- %ARRAYTYPE - new functionality, provides the array type from a variable or table column.
- %ELEMENTTYPE - new funcitonality, provides the element type of a given array.

New regression tests are included in the patch. Changes to the documentation are not provided.

Initial Run:

The patch applies correctly to HEAD. Regression tests pass successfully, without errors. It seems that the patch work as you expected.

Performance:

It seems patch have not possible performance issues for the existing functionality.

Coding:

The style looks fine. I attached the patch that does some corrections in code and documentation. I have corrected indentation in pl_comp.c and "read_datatype" function in pl_gram.y. I think changes in "read_datatype" function would be better to avoid a code duplication. But I could be wrong of course.

Conclusion:

The patch could be applied on master with documentation corrections. But I'm not sure that your task could be resloved only by adding %ARRAYTYPE and %ELEMENTTYPE. Maybe you will give some examples?

Thank you for review. The changes in code are good idea.

I waited with documentation if there will be some objections to syntax. The month later, there are not any known objection.

The target of this feature isn't using for storing of database objects only, but for storing the values of polymorphic parameters.

CREATE OR REPLACE FUNCTION buble_sort(a anyarray)
RETURNS anyarray AS $$
DECLARE
  aux a%ELEMENTTYPE;
  repeat_again boolean DEFAULT true;
BEGIN
  -- Don't use this code for large arrays!
  -- use builtin sort
  WHILE repeat_again
    repeat_again := false;
    FOR i IN array_lower(a, 1) .. array_upper(a, 2)
    LOOP
      IF a[i] > a[i+1] THEN
        aux := a[i+1];
        a[i+1] := a[i]; a[i] := aux;
        repeat_again := true;
      END IF;
    END LOOP;
  END WHILE;
  RETURN a;
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION array_init(v anyelement, size integer)
RETURNS anyarray AS $$
DECLARE result v%ARRAYTYPE DEFAULT '{}';
BEGIN
  -- prefer builtin function array_fill
  FOR i IN 1 .. size
  LOOP
    result := result || v;
  END LOOP;
  RETURN result;
END;
$$ LANGUAGE plpgsql;


Regards

Pavel
 

--
Artur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Avoiding pin scan during btree vacuum
Next
From: David Rowley
Date:
Subject: Re: Patch to improve a few appendStringInfo* calls