Re: [HACKERS] pseudo-type record arguments for PL-functions
David Fetter wrote: On Thu, May 04, 2006 at 09:02:02PM +0200, Thomas Hallgren wrote: Tom Lane wrote: Why can PLs not handle pseudo-types? No one's done the work to figure out which ones are sensible to support and then add the logic needed to support them. PL/Java will handle the RECORD type correctly. I'm just finalizing a new, more flexible, type mapping implementation for PL/Java and it would be easy to add support for more pseudo types too. But what others would make sense? Ideally, some way to get all kinds of user-defined types. DOMAINs, too. :) OK, got them covered as well. Only thing that remain now is arrays. I have a hard time figuring out how to manage them. I'm looking at the arrayutils.c. The thing that makes me a bit confused is the ArrayMetaState. The functions obtain it using: my_extra = (ArrayMetaState *) fcinfo-flinfo-fn_extra; which is fine if there's only one array parameter. What happens if I have two? And how do I declare a function that takes, say, an array of int's as a parameter (in SQL that is)? I find very little information about how to write functions that deals with arrays. My only source of information right now is the arrayutils.c. Other pointers to docs and code are greatly appreciated. Kind Regards, Thomas Hallgren ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pseudo-type record arguments for PL-functions
On Sat, May 06, 2006 at 05:26:31PM +0200, Thomas Hallgren wrote: I find very little information about how to write functions that deals with arrays. My only source of information right now is the arrayutils.c. Other pointers to docs and code are greatly appreciated. Looking at contrib/intarray/_int_op.c might help. It does something like this: ArrayType *a = (ArrayType *) DatumGetPointer(PG_DETOAST_DATUM_COPY(PG_GETARG_DATUM(0))); The file src/include/utils/array.h also seems to have many useful functions. Hope this helps, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] pseudo-type record arguments for PL-functions
Thomas Hallgren [EMAIL PROTECTED] writes: The thing that makes me a bit confused is the ArrayMetaState. The functions obtain it using: my_extra = (ArrayMetaState *) fcinfo-flinfo-fn_extra; which is fine if there's only one array parameter. What happens if I have two? Make a struct that can hold two ArrayMetaStates. Or whatever else you need. What a C function keeps in fn_extra is its own affair. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pseudo-type record arguments for PL-functions
Tom Lane wrote: Make a struct that can hold two ArrayMetaStates. Or whatever else you need. What a C function keeps in fn_extra is its own affair. Yes, of course. I see that now. I was unaware that a function had an associated user data. What's the semantics associated with the fn_extra? Does it retain its setting throughout a session (i.e. the lifetime of the backend process)? PL/Java associates a structure with a function using a hash map lookup on the function Oid. Seems I could use the fn_extra and remove that map altogether. Then again, there are times when I need to invalidate the associated structure of all java functions due to reload of jar files. Is there any way that I can list all functions for a specific language and get hold of their current setting of the fn_extra? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pseudo-type record arguments for PL-functions
Martijn van Oosterhout wrote: Looking at contrib/intarray/_int_op.c might help. It does something like this: ArrayType *a = (ArrayType *) DatumGetPointer(PG_DETOAST_DATUM_COPY(PG_GETARG_DATUM(0))); The file src/include/utils/array.h also seems to have many useful functions. Hope this helps, Yes, the intarray stuff was very helpful but also somewhat confusing. Why are there two ways of representing some of the array types? I mean, why is there an _int4 when you could just as well write int4[]? I'm probably missing the point altogether. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pseudo-type record arguments for PL-functions
Thomas Hallgren [EMAIL PROTECTED] writes: Yes, of course. I see that now. I was unaware that a function had an associated user data. What's the semantics associated with the fn_extra? Does it retain its setting throughout a session (i.e. the lifetime of the backend process)? No, just for the query. I'd advise using it only as a cache, although set-returning functions sometimes use it to hold state associated with successive rows of their result. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pseudo-type record arguments for PL-functions
On Sun, May 07, 2006 at 12:16:16AM +0200, Thomas Hallgren wrote: Yes, the intarray stuff was very helpful but also somewhat confusing. Why are there two ways of representing some of the array types? I mean, why is there an _int4 when you could just as well write int4[]? I'm probably missing the point altogether. FWICT, Prefixing a '_' is the convention used to make the array type's typname unique. Being able to reference array types as _type is a side effect. (array types being actual rows in pg_type) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pseudo-type record arguments for PL-functions
James William Pye [EMAIL PROTECTED] writes: On Sun, May 07, 2006 at 12:16:16AM +0200, Thomas Hallgren wrote: Why are there two ways of representing some of the array types? I mean, why is there an _int4 when you could just as well write int4[]? I'm probably missing the point altogether. FWICT, Prefixing a '_' is the convention used to make the array type's typname unique. Being able to reference array types as _type is a side effect. (array types being actual rows in pg_type) There used to be some contexts where you *had* to write _foo instead of foo[] because the grammar only allowed simple names and not the full TypeName production. I think we've fixed them all, but very likely there are places in contrib still following the old convention. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] pseudo-type record arguments for PL-functions
Hi, I'm trying to write a PL/Python function which is to be called from a rule. I'd need pass the OLD and NEW tuple records to the function. Unfortunately that does not work: 'pl/python functions cannot take type record'. What I have figured out by reading the source code: OLD and NEW are pseudo types (otherwise, pl/python would not have thrown that error) (plpython.c:1088). During parsing of SQL function definitions the arguments for the function are checked. In a comment I've read: Disallow pseudotypes in arguments (pg_proc:546). I checked the other PLs and found out, that no one can handle pseudo-arguments. What exactly are pseudo types? Why are the OLD and NEW records of a rule pseudo-types? Why can PLs not handle pseudo-types? Or is it possible to write a C-function which takes the OLD and NEW records of a rule as arguments? Is there an example of such a thing? Regards Markus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pseudo-type record arguments for PL-functions
Markus Schiltknecht [EMAIL PROTECTED] writes: What exactly are pseudo types? See http://developer.postgresql.org/docs/postgres/extend-type-system.html Why can PLs not handle pseudo-types? No one's done the work to figure out which ones are sensible to support and then add the logic needed to support them. In your particular case, the problem is that plpython isn't prepared to handle rowtypes determined at runtime. I'm not sure if the recently submitted plpython patch fixes that or not. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pseudo-type record arguments for PL-functions
Tom Lane wrote: Why can PLs not handle pseudo-types? No one's done the work to figure out which ones are sensible to support and then add the logic needed to support them. PL/Java will handle the RECORD type correctly. I'm just finalizing a new, more flexible, type mapping implementation for PL/Java and it would be easy to add support for more pseudo types too. But what others would make sense? Kind Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pseudo-type record arguments for PL-functions
Thomas Hallgren [EMAIL PROTECTED] writes: PL/Java will handle the RECORD type correctly. I'm just finalizing a new, more flexible, type mapping implementation for PL/Java and it would be easy to add support for more pseudo types too. But what others would make sense? If you've got record/anyelement/anyarray support, you've probably pretty much covered the bases. Looking at the list (table 8-20), it strikes me that there's nothing very pseudo about cstring anymore --- it could certainly be treated as an ordinary datatype. Not sure if there's any point in changing though. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pseudo-type record arguments for PL-functions
On Thu, May 04, 2006 at 09:02:02PM +0200, Thomas Hallgren wrote: Tom Lane wrote: Why can PLs not handle pseudo-types? No one's done the work to figure out which ones are sensible to support and then add the logic needed to support them. PL/Java will handle the RECORD type correctly. I'm just finalizing a new, more flexible, type mapping implementation for PL/Java and it would be easy to add support for more pseudo types too. But what others would make sense? Ideally, some way to get all kinds of user-defined types. DOMAINs, too. :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
