Обсуждение: Patch for user-defined C-language functions
Hi all, I have been working with user defined types and user defined c 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 CREATE FUNCTION mytype3 ( mytype2 ) RETURNS mytype3 AS 'mytypes.so' LANGUAGE 'C' CREATE FUNCTION mytype3 ( mytype1 ) RETURNS mytype3 AS 'mytypes.so' LANGUAGE 'C' 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 CREATE FUNCTION mytype3 ( mytype2 ) RETURNS mytype3 AS 'mytypes.so', 'mytype2_to_mytype3' LANGUAGE 'C' The syntax for the AS clause, which was 'AS <link-file>' becomes AS <link_file>[, <link_name>] Specification of the link_name is optional, and not needed if the link name is the same as the Postgresql function name. 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
Вложения
Bernard Frankpitt <frankpit@pop.dn.net> writes: > 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 > CREATE FUNCTION mytype3 ( mytype2 ) > RETURNS mytype3 > AS 'mytypes.so', 'mytype2_to_mytype3' > LANGUAGE 'C' > The syntax for the AS clause, which was 'AS <link-file>' becomes > AS <link_file>[, <link_name>] > Specification of the link_name is optional, and not needed if the link > name is the same as the Postgresql function name. > 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. Sounds like a good plan to me. I'll be glad to check this over and commit it into 6.6 (unless there are objections?) ... but could I trouble you for documentation diffs as well? At the very least, the text discussion of CREATE FUNCTION, the reference page entry, and the online help in psql need to reflect this addition. regards, tom lane
Tom, where are we on this? > Bernard Frankpitt <frankpit@pop.dn.net> writes: > > 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 > > CREATE FUNCTION mytype3 ( mytype2 ) > > RETURNS mytype3 > > AS 'mytypes.so', 'mytype2_to_mytype3' > > LANGUAGE 'C' > > The syntax for the AS clause, which was 'AS <link-file>' becomes > > AS <link_file>[, <link_name>] > > Specification of the link_name is optional, and not needed if the link > > name is the same as the Postgresql function name. > > > 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. > > Sounds like a good plan to me. I'll be glad to check this over and > commit it into 6.6 (unless there are objections?) ... but could I > trouble you for documentation diffs as well? At the very least, > the text discussion of CREATE FUNCTION, the reference page entry, > and the online help in psql need to reflect this addition. > > regards, tom lane > > ************ > > -- 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, Pennsylvania19026
Applied. > Hi all, > > I have been working with user defined types and user defined c > 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 > > CREATE FUNCTION mytype3 ( mytype2 ) > RETURNS mytype3 > AS 'mytypes.so' > LANGUAGE 'C' > > CREATE FUNCTION mytype3 ( mytype1 ) > RETURNS mytype3 > AS 'mytypes.so' > LANGUAGE 'C' > > 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 > > CREATE FUNCTION mytype3 ( mytype2 ) > RETURNS mytype3 > AS 'mytypes.so', 'mytype2_to_mytype3' > LANGUAGE 'C' > > The syntax for the AS clause, which was 'AS <link-file>' becomes > > AS <link_file>[, <link_name>] > > Specification of the link_name is optional, and not needed if the link > name is the same as the Postgresql function name. > > 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 [Attachment, skipping...] -- 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, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes: > Tom, where are we on this? It's in my to-do queue. I have to touch the same files anyway in order to make the world safe for constant-folding, because right now CREATE FUNCTION only lets you specify the ISCACHABLE flag for a C-language routine. Need to open that up for all languages, and document it. I was waiting for Thomas, because I had understood some of his remarks to mean that he was busy doing a major rearrangement of code in the parser, but he told me last night to go ahead and commit these changes. So it should get done shortly. regards, tom lane >> Bernard Frankpitt <frankpit@pop.dn.net> writes: >>>> The solution that I propose, and have implemented in the attatched >>>> patch extends the CREATE FUNCTION syntax as follows.