1. 22 Jan, 2001 1 commit
  2. 20 Jan, 2001 1 commit
  3. 13 Jan, 2001 1 commit
  4. 12 Jan, 2001 1 commit
  5. 26 Dec, 2000 1 commit
  6. 22 Dec, 2000 1 commit
  7. 21 Dec, 2000 1 commit
  8. 20 Nov, 2000 1 commit
    • Tom Lane's avatar
      Revise handling of oldstyle/newstyle functions per recent discussions · 5bb2300b
      Tom Lane authored
      in pghackers list.  Support for oldstyle internal functions is gone
      (no longer needed, since conversion is complete) and pg_language entry
      'internal' now implies newstyle call convention.  pg_language entry
      'newC' is gone; both old and newstyle dynamically loaded C functions
      are now called language 'C'.  A newstyle function must be identified
      by an associated info routine.  See src/backend/utils/fmgr/README.
      5bb2300b
  9. 23 Oct, 2000 1 commit
  10. 29 Sep, 2000 1 commit
  11. 25 Aug, 2000 1 commit
  12. 24 Aug, 2000 1 commit
  13. 21 Aug, 2000 1 commit
    • Tom Lane's avatar
      fmgr interface mopup work. Use new DatumGetBool and BoolGetDatum · e67ff6b6
      Tom Lane authored
      macros where appropriate (the code used to have several different ways
      of doing that, including Int32, Int8, UInt8, ...).  Remove last few
      references to float32 and float64 typedefs --- it's all float4/float8
      now.  The typedefs themselves should probably stay in c.h for a release
      or two, though, to avoid breaking user-written C functions.
      e67ff6b6
  14. 27 May, 2000 1 commit
  15. 20 May, 2000 1 commit
  16. 18 May, 2000 1 commit
  17. 02 May, 2000 1 commit
  18. 31 Mar, 2000 1 commit
  19. 30 Mar, 2000 1 commit
  20. 11 Jan, 2000 1 commit
  21. 04 Oct, 1999 1 commit
  22. 02 Oct, 1999 1 commit
  23. 01 Oct, 1999 1 commit
  24. 28 Sep, 1999 1 commit
    • Bruce Momjian's avatar
      I have been working with user defined types and user defined c · 9394d62c
      Bruce Momjian authored
      functions.  One problem that I have encountered with the function
      manager is that it does not allow the user to define type conversion
      functions that convert between user types. For instance if mytype1,
      mytype2, and mytype3 are three Postgresql user types, and if I wish to
      define Postgresql conversion functions like
      
      I run into problems, because the Postgresql dynamic loader would look
      for a single link symbol, mytype3, for both pieces of object code.  If
      I just change the name of one of the Postgresql functions (to make the
      symbols distinct), the automatic type conversion that Postgresql uses,
      for example, when matching operators to arguments no longer finds the
      type conversion function.
      
      The solution that I propose, and have implemented in the attatched
      patch extends the CREATE FUNCTION syntax as follows. In the first case
      above I use the link symbol mytype2_to_mytype3 for the link object
      that implements the first conversion function, and define the
      Postgresql operator with the following syntax
      
      The patch includes changes to the parser to include the altered
      syntax, changes to the ProcedureStmt node in nodes/parsenodes.h,
      changes to commands/define.c to handle the extra information in the AS
      clause, and changes to utils/fmgr/dfmgr.c that alter the way that the
      dynamic loader figures out what link symbol to use.  I store the
      string for the link symbol in the prosrc text attribute of the pg_proc
      table which is currently unused in rows that reference dynamically
      loaded
      functions.
      
      
      Bernie Frankpitt
      9394d62c
  25. 22 Jul, 1999 1 commit
  26. 14 Mar, 1999 1 commit
  27. 29 Dec, 1998 1 commit
  28. 29 Jul, 1998 1 commit
  29. 26 Apr, 1998 1 commit
  30. 01 Mar, 1998 1 commit
  31. 15 Jan, 1997 1 commit