subject:"\[HACKERS\] Schemas not available for pl\/pgsql %TYPE...."

Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....

2002-09-17 Thread Bruce Momjian



Does pl/python even have a DECLARE section that can mimick the data type
of an existing table column?

---

Greg Copeland wrote:
-- Start of PGP signed section.
 Does anyone know if such effort is also required to pl/python to become
 schema aware?
 
 Regards,
 
   Greg Copeland
 
 
 On Wed, 2002-09-11 at 19:24, Bruce Momjian wrote:
  
  Patch applied.  Thanks.
  
  ---
  
  
  Joe Conway wrote:
   Tom Lane wrote:
Sean Chittenden [EMAIL PROTECTED] writes:

   ::sigh:: Is it me or does it look like all
   of pl/pgsql is schema un-aware (ie, all of the declarations).  -sc


Yeah.  The group of routines parse_word, parse_dblword, etc that are
called by the lexer certainly all need work.  There are some
definitional issues to think about, too --- plpgsql presently relies on
the number of names to give it some idea of what to look for, and those
rules are probably all toast now.  Please come up with a sketch of what
you think the behavior should be before you start hacking code.
   
   Attached is a diff -c format proposal to fix this. I've also attached a short 
   test script. Seems to work OK and passes all regression tests.
   
   Here's a breakdown of how I understand plpgsql's Special word rules -- I 
   think it illustrates the behavior reasonably well. New functions added by this 
   patch are plpgsql_parse_tripwordtype and plpgsql_parse_dblwordrowtype:
   
   
   Identifiers (represents)parsing function
   
   identifierplpgsql_parse_word
tg_argv
T_LABEL (label)
T_VARIABLE  (variable)
T_RECORD(record)
T_ROW   (row)
   
   identifier.identifier  plpgsql_parse_dblword
T_LABEL
T_VARIABLE  (label.variable)
T_RECORD(label.record)
T_ROW   (label.row)
T_RECORD
T_VARIABLE  (record.variable)
T_ROW
T_VARIABLE  (row.variable)
   
   identifier.identifier.identifier  plpgsql_parse_tripword
T_LABEL
T_RECORD
T_VARIABLE  (label.record.variable)
T_ROW
T_VARIABLE  (label.row.variable)
   
   identifier%TYPE   plpgsql_parse_wordtype
T_VARIABLE
T_DTYPE (variable%TYPE)
T_DTYPE (typname%TYPE)
   
   identifier.identifier%TYPE plpgsql_parse_dblwordtype
T_LABEL
T_VARIABLE
T_DTYPE (label.variable%TYPE)
T_DTYPE (relname.attname%TYPE)
   
   new
   identifier.identifier.identifier%TYPE plpgsql_parse_tripwordtype
T_DTYPE (nspname.relname.attname%TYPE)
   
   identifier%ROWTYPE plpgsql_parse_wordrowtype
T_DTYPE (relname%ROWTYPE)
   
   new
   identifier.identifier%ROWTYPE   plpgsql_parse_dblwordrowtype
T_DTYPE (nspname.relname%ROWTYPE)
   
   
   Parameters - parallels the above
   
   $#plpgsql_parse_word
   $#.identifier  plpgsql_parse_dblword
   $#.identifier.identifier  plpgsql_parse_tripword
   $#%TYPE   plpgsql_parse_wordtype
   $#.identifier%TYPE plpgsql_parse_dblwordtype
   $#.identifier.identifier%TYPE plpgsql_parse_tripwordtype
   $#%ROWTYPE plpgsql_parse_wordrowtype
   $#.identifier%ROWTYPE   plpgsql_parse_dblwordrowtype
   
   Comments?
   
   Thanks,
   
   Joe
  
   Index: src/pl/plpgsql/src/pl_comp.c

Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....

2002-09-12 Thread Greg Copeland


Does anyone know if such effort is also required to pl/python to become
schema aware?

Regards,

Greg Copeland


On Wed, 2002-09-11 at 19:24, Bruce Momjian wrote:
 
 Patch applied.  Thanks.
 
 ---
 
 
 Joe Conway wrote:
  Tom Lane wrote:
   Sean Chittenden [EMAIL PROTECTED] writes:
   
  ::sigh:: Is it me or does it look like all
  of pl/pgsql is schema un-aware (ie, all of the declarations).  -sc
   
   
   Yeah.  The group of routines parse_word, parse_dblword, etc that are
   called by the lexer certainly all need work.  There are some
   definitional issues to think about, too --- plpgsql presently relies on
   the number of names to give it some idea of what to look for, and those
   rules are probably all toast now.  Please come up with a sketch of what
   you think the behavior should be before you start hacking code.
  
  Attached is a diff -c format proposal to fix this. I've also attached a short 
  test script. Seems to work OK and passes all regression tests.
  
  Here's a breakdown of how I understand plpgsql's Special word rules -- I 
  think it illustrates the behavior reasonably well. New functions added by this 
  patch are plpgsql_parse_tripwordtype and plpgsql_parse_dblwordrowtype:
  
  
  Identifiers (represents)parsing function
  
  identifierplpgsql_parse_word
   tg_argv
   T_LABEL (label)
   T_VARIABLE  (variable)
   T_RECORD(record)
   T_ROW   (row)
  
  identifier.identifier  plpgsql_parse_dblword
   T_LABEL
   T_VARIABLE  (label.variable)
   T_RECORD(label.record)
   T_ROW   (label.row)
   T_RECORD
   T_VARIABLE  (record.variable)
   T_ROW
   T_VARIABLE  (row.variable)
  
  identifier.identifier.identifier  plpgsql_parse_tripword
   T_LABEL
   T_RECORD
   T_VARIABLE  (label.record.variable)
   T_ROW
   T_VARIABLE  (label.row.variable)
  
  identifier%TYPE   plpgsql_parse_wordtype
   T_VARIABLE
   T_DTYPE (variable%TYPE)
   T_DTYPE (typname%TYPE)
  
  identifier.identifier%TYPE plpgsql_parse_dblwordtype
   T_LABEL
   T_VARIABLE
   T_DTYPE (label.variable%TYPE)
   T_DTYPE (relname.attname%TYPE)
  
  new
  identifier.identifier.identifier%TYPE plpgsql_parse_tripwordtype
   T_DTYPE (nspname.relname.attname%TYPE)
  
  identifier%ROWTYPE plpgsql_parse_wordrowtype
   T_DTYPE (relname%ROWTYPE)
  
  new
  identifier.identifier%ROWTYPE   plpgsql_parse_dblwordrowtype
   T_DTYPE (nspname.relname%ROWTYPE)
  
  
  Parameters - parallels the above
  
  $#plpgsql_parse_word
  $#.identifier  plpgsql_parse_dblword
  $#.identifier.identifier  plpgsql_parse_tripword
  $#%TYPE   plpgsql_parse_wordtype
  $#.identifier%TYPE plpgsql_parse_dblwordtype
  $#.identifier.identifier%TYPE plpgsql_parse_tripwordtype
  $#%ROWTYPE plpgsql_parse_wordrowtype
  $#.identifier%ROWTYPE   plpgsql_parse_dblwordrowtype
  
  Comments?
  
  Thanks,
  
  Joe
 
  Index: src/pl/plpgsql/src/pl_comp.c
  ===
  RCS file: /opt/src/cvs/pgsql-server/src/pl/plpgsql/src/pl_comp.c,v
  retrieving revision 1.51
  diff -c -r1.51 pl_comp.c
  *** src/pl/plpgsql/src/pl_comp.c4 Sep 2002 20:31:47 -   1.51
  --- src/pl/plpgsql/src/pl_comp.c9 Sep 2002 04:22:24 -
  ***
  *** 1092,1097 
  --- 1092,1217

Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....

2002-09-11 Thread Bruce Momjian



Patch applied.  Thanks.

---


Joe Conway wrote:
 Tom Lane wrote:
  Sean Chittenden [EMAIL PROTECTED] writes:
  
 ::sigh:: Is it me or does it look like all
 of pl/pgsql is schema un-aware (ie, all of the declarations).  -sc
  
  
  Yeah.  The group of routines parse_word, parse_dblword, etc that are
  called by the lexer certainly all need work.  There are some
  definitional issues to think about, too --- plpgsql presently relies on
  the number of names to give it some idea of what to look for, and those
  rules are probably all toast now.  Please come up with a sketch of what
  you think the behavior should be before you start hacking code.
 
 Attached is a diff -c format proposal to fix this. I've also attached a short 
 test script. Seems to work OK and passes all regression tests.
 
 Here's a breakdown of how I understand plpgsql's Special word rules -- I 
 think it illustrates the behavior reasonably well. New functions added by this 
 patch are plpgsql_parse_tripwordtype and plpgsql_parse_dblwordrowtype:
 
 
 Identifiers (represents)parsing function
 
 identifierplpgsql_parse_word
  tg_argv
  T_LABEL (label)
  T_VARIABLE  (variable)
  T_RECORD(record)
  T_ROW   (row)
 
 identifier.identifier  plpgsql_parse_dblword
  T_LABEL
  T_VARIABLE  (label.variable)
  T_RECORD(label.record)
  T_ROW   (label.row)
  T_RECORD
  T_VARIABLE  (record.variable)
  T_ROW
  T_VARIABLE  (row.variable)
 
 identifier.identifier.identifier  plpgsql_parse_tripword
  T_LABEL
  T_RECORD
  T_VARIABLE  (label.record.variable)
  T_ROW
  T_VARIABLE  (label.row.variable)
 
 identifier%TYPE   plpgsql_parse_wordtype
  T_VARIABLE
  T_DTYPE (variable%TYPE)
  T_DTYPE (typname%TYPE)
 
 identifier.identifier%TYPE plpgsql_parse_dblwordtype
  T_LABEL
  T_VARIABLE
  T_DTYPE (label.variable%TYPE)
  T_DTYPE (relname.attname%TYPE)
 
 new
 identifier.identifier.identifier%TYPE plpgsql_parse_tripwordtype
  T_DTYPE (nspname.relname.attname%TYPE)
 
 identifier%ROWTYPE plpgsql_parse_wordrowtype
  T_DTYPE (relname%ROWTYPE)
 
 new
 identifier.identifier%ROWTYPE   plpgsql_parse_dblwordrowtype
  T_DTYPE (nspname.relname%ROWTYPE)
 
 
 Parameters - parallels the above
 
 $#plpgsql_parse_word
 $#.identifier  plpgsql_parse_dblword
 $#.identifier.identifier  plpgsql_parse_tripword
 $#%TYPE   plpgsql_parse_wordtype
 $#.identifier%TYPE plpgsql_parse_dblwordtype
 $#.identifier.identifier%TYPE plpgsql_parse_tripwordtype
 $#%ROWTYPE plpgsql_parse_wordrowtype
 $#.identifier%ROWTYPE   plpgsql_parse_dblwordrowtype
 
 Comments?
 
 Thanks,
 
 Joe

 Index: src/pl/plpgsql/src/pl_comp.c
 ===
 RCS file: /opt/src/cvs/pgsql-server/src/pl/plpgsql/src/pl_comp.c,v
 retrieving revision 1.51
 diff -c -r1.51 pl_comp.c
 *** src/pl/plpgsql/src/pl_comp.c  4 Sep 2002 20:31:47 -   1.51
 --- src/pl/plpgsql/src/pl_comp.c  9 Sep 2002 04:22:24 -
 ***
 *** 1092,1097 
 --- 1092,1217 
   return T_DTYPE;
   }
   
 + /* --
 +  * plpgsql_parse_tripwordtype   Same lookup for word.word.word%TYPE
 +  * --
 +  */
 + #define TYPE_JUNK_LEN   5
 + 
 + int
 + plpgsql_parse_tripwordtype(char *word)
 + {
 + Oid

Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....

2002-09-10 Thread Bruce Momjian



Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---


Joe Conway wrote:
 Tom Lane wrote:
  Sean Chittenden [EMAIL PROTECTED] writes:
  
 ::sigh:: Is it me or does it look like all
 of pl/pgsql is schema un-aware (ie, all of the declarations).  -sc
  
  
  Yeah.  The group of routines parse_word, parse_dblword, etc that are
  called by the lexer certainly all need work.  There are some
  definitional issues to think about, too --- plpgsql presently relies on
  the number of names to give it some idea of what to look for, and those
  rules are probably all toast now.  Please come up with a sketch of what
  you think the behavior should be before you start hacking code.
 
 Attached is a diff -c format proposal to fix this. I've also attached a short 
 test script. Seems to work OK and passes all regression tests.
 
 Here's a breakdown of how I understand plpgsql's Special word rules -- I 
 think it illustrates the behavior reasonably well. New functions added by this 
 patch are plpgsql_parse_tripwordtype and plpgsql_parse_dblwordrowtype:
 
 
 Identifiers (represents)parsing function
 
 identifierplpgsql_parse_word
  tg_argv
  T_LABEL (label)
  T_VARIABLE  (variable)
  T_RECORD(record)
  T_ROW   (row)
 
 identifier.identifier  plpgsql_parse_dblword
  T_LABEL
  T_VARIABLE  (label.variable)
  T_RECORD(label.record)
  T_ROW   (label.row)
  T_RECORD
  T_VARIABLE  (record.variable)
  T_ROW
  T_VARIABLE  (row.variable)
 
 identifier.identifier.identifier  plpgsql_parse_tripword
  T_LABEL
  T_RECORD
  T_VARIABLE  (label.record.variable)
  T_ROW
  T_VARIABLE  (label.row.variable)
 
 identifier%TYPE   plpgsql_parse_wordtype
  T_VARIABLE
  T_DTYPE (variable%TYPE)
  T_DTYPE (typname%TYPE)
 
 identifier.identifier%TYPE plpgsql_parse_dblwordtype
  T_LABEL
  T_VARIABLE
  T_DTYPE (label.variable%TYPE)
  T_DTYPE (relname.attname%TYPE)
 
 new
 identifier.identifier.identifier%TYPE plpgsql_parse_tripwordtype
  T_DTYPE (nspname.relname.attname%TYPE)
 
 identifier%ROWTYPE plpgsql_parse_wordrowtype
  T_DTYPE (relname%ROWTYPE)
 
 new
 identifier.identifier%ROWTYPE   plpgsql_parse_dblwordrowtype
  T_DTYPE (nspname.relname%ROWTYPE)
 
 
 Parameters - parallels the above
 
 $#plpgsql_parse_word
 $#.identifier  plpgsql_parse_dblword
 $#.identifier.identifier  plpgsql_parse_tripword
 $#%TYPE   plpgsql_parse_wordtype
 $#.identifier%TYPE plpgsql_parse_dblwordtype
 $#.identifier.identifier%TYPE plpgsql_parse_tripwordtype
 $#%ROWTYPE plpgsql_parse_wordrowtype
 $#.identifier%ROWTYPE   plpgsql_parse_dblwordrowtype
 
 Comments?
 
 Thanks,
 
 Joe

 Index: src/pl/plpgsql/src/pl_comp.c
 ===
 RCS file: /opt/src/cvs/pgsql-server/src/pl/plpgsql/src/pl_comp.c,v
 retrieving revision 1.51
 diff -c -r1.51 pl_comp.c
 *** src/pl/plpgsql/src/pl_comp.c  4 Sep 2002 20:31:47 -   1.51
 --- src/pl/plpgsql/src/pl_comp.c  9 Sep 2002 04:22:24 -
 ***
 *** 1092,1097 
 --- 1092,1217 
   return T_DTYPE;
   }
   
 + /* --
 +  * plpgsql_parse_tripwordtype   Same lookup for

Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....

2002-09-08 Thread Joe Conway


Tom Lane wrote:
 Sean Chittenden [EMAIL PROTECTED] writes:
 
::sigh:: Is it me or does it look like all
of pl/pgsql is schema un-aware (ie, all of the declarations).  -sc
 
 
 Yeah.  The group of routines parse_word, parse_dblword, etc that are
 called by the lexer certainly all need work.  There are some
 definitional issues to think about, too --- plpgsql presently relies on
 the number of names to give it some idea of what to look for, and those
 rules are probably all toast now.  Please come up with a sketch of what
 you think the behavior should be before you start hacking code.

Attached is a diff -c format proposal to fix this. I've also attached a short 
test script. Seems to work OK and passes all regression tests.

Here's a breakdown of how I understand plpgsql's Special word rules -- I 
think it illustrates the behavior reasonably well. New functions added by this 
patch are plpgsql_parse_tripwordtype and plpgsql_parse_dblwordrowtype:


Identifiers (represents)parsing function

identifierplpgsql_parse_word
 tg_argv
 T_LABEL (label)
 T_VARIABLE  (variable)
 T_RECORD(record)
 T_ROW   (row)

identifier.identifier  plpgsql_parse_dblword
 T_LABEL
 T_VARIABLE  (label.variable)
 T_RECORD(label.record)
 T_ROW   (label.row)
 T_RECORD
 T_VARIABLE  (record.variable)
 T_ROW
 T_VARIABLE  (row.variable)

identifier.identifier.identifier  plpgsql_parse_tripword
 T_LABEL
 T_RECORD
 T_VARIABLE  (label.record.variable)
 T_ROW
 T_VARIABLE  (label.row.variable)

identifier%TYPE   plpgsql_parse_wordtype
 T_VARIABLE
 T_DTYPE (variable%TYPE)
 T_DTYPE (typname%TYPE)

identifier.identifier%TYPE plpgsql_parse_dblwordtype
 T_LABEL
 T_VARIABLE
 T_DTYPE (label.variable%TYPE)
 T_DTYPE (relname.attname%TYPE)

new
identifier.identifier.identifier%TYPE plpgsql_parse_tripwordtype
 T_DTYPE (nspname.relname.attname%TYPE)

identifier%ROWTYPE plpgsql_parse_wordrowtype
 T_DTYPE (relname%ROWTYPE)

new
identifier.identifier%ROWTYPE   plpgsql_parse_dblwordrowtype
 T_DTYPE (nspname.relname%ROWTYPE)


Parameters - parallels the above

$#plpgsql_parse_word
$#.identifier  plpgsql_parse_dblword
$#.identifier.identifier  plpgsql_parse_tripword
$#%TYPE   plpgsql_parse_wordtype
$#.identifier%TYPE plpgsql_parse_dblwordtype
$#.identifier.identifier%TYPE plpgsql_parse_tripwordtype
$#%ROWTYPE plpgsql_parse_wordrowtype
$#.identifier%ROWTYPE   plpgsql_parse_dblwordrowtype

Comments?

Thanks,

Joe


Index: src/pl/plpgsql/src/pl_comp.c
===
RCS file: /opt/src/cvs/pgsql-server/src/pl/plpgsql/src/pl_comp.c,v
retrieving revision 1.51
diff -c -r1.51 pl_comp.c
*** src/pl/plpgsql/src/pl_comp.c4 Sep 2002 20:31:47 -   1.51
--- src/pl/plpgsql/src/pl_comp.c9 Sep 2002 04:22:24 -
***
*** 1092,1097 
--- 1092,1217 
return T_DTYPE;
  }
  
+ /* --
+  * plpgsql_parse_tripwordtype Same lookup for word.word.word%TYPE
+  * --
+  */
+ #define TYPE_JUNK_LEN 5
+ 
+ int
+ plpgsql_parse_tripwordtype(char *word)
+ {
+   Oid classOid;
+   HeapTuple   classtup;
+   Form_pg_class classStruct;
+   HeapTuple   attrtup;
+   Form_pg_attribute attrStruct;
+   HeapTuple   typetup;
+   Form_pg_type typeStruct;
+

Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....

Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....

Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....

Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....

Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....

5 matches

Site Navigation

Mail list logo

Footer information