Re: [HACKERS] Function parameter names
On Sun, 23 Nov 2003, Tom Lane wrote: Actually I'd suggest text[], as there is no good reason to pad the array entries to a fixed length. I've implemented this part now and it stores the paremeter names in the pg_proc table as a text[] field. However, in the parser I use IDENT to get the parameter names and already in the lexer the IDENT tokens are truncated to length NAMEDATALEN. So I've got 3 options: 1) Leave it as is now where the system table allows any length but the parser only lets you insert short identifiers. 2) Change the type to name[] 3) Change the parser to accept identifiers of any length and add the length check in a later phase for the identifiers that need to be shorter. Any opinions or should I just make a choice myself? -- /Dennis ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Function parameter names
Dennis Bjorklund [EMAIL PROTECTED] writes: However, in the parser I use IDENT to get the parameter names and already in the lexer the IDENT tokens are truncated to length NAMEDATALEN. Right. What's the problem? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Function parameter names
On Tue, 25 Nov 2003, Tom Lane wrote: Dennis Bjorklund [EMAIL PROTECTED] writes: However, in the parser I use IDENT to get the parameter names and already in the lexer the IDENT tokens are truncated to length NAMEDATALEN. Right. What's the problem? It's strange to allow identifiers to be of any length in the system table when there is no way to create it using normal syntax. The parser accepts this kind of input: CREATE FUNCTION foo (x int) RETURNS int AS ... and the identifier x (as all identifiers) can not be too long. Still, one can create the function and update the system table by hand to change x to a longer name. Doesn't that sound ugly to you? It's not a technical problem, but a matter of style. Everything works as it is now, but works is not always enough. -- /Dennis ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Function parameter names
Dennis Bjorklund [EMAIL PROTECTED] writes: and the identifier x (as all identifiers) can not be too long. Still, one can create the function and update the system table by hand to change x to a longer name. Doesn't that sound ugly to you? It has always been, and likely always will be, possible to use manual updating of the system catalogs to arrive at states that you could not get into otherwise, and which might or might not work correctly, for whatever value of correctly you think is correct. This doesn't particularly bother me, since we have always told people that manual updates are unsupported and are strictly for people who know exactly what they're doing. If it really bugs you, possibly the column could be declared as varchar(NAMEDATALEN-1)[] rather than text[], but I think the amount of effort needed to make that happen within the .bki file would be well out of proportion to the usefulness. (Actually, it'd still not be 100% right, since varchar(N) counts characters not bytes ...) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Function parameter names
Dennis Bjorklund [EMAIL PROTECTED] writes: It's strange to allow identifiers to be of any length in the system table when there is no way to create it using normal syntax. I agree with Tom -- that doesn't seem strange to me at all. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Function parameter names
Dennis Bjorklund writes: I'm in the middle of implementing function parameter names. How will that work in arbitrary procedural languages? Would it be a good idea to create a namevector in the same way as oidvector? Would a normal array like name[] be better? What is the reason for the oidvector to be it's own type instead of a oid[]? An oidvector is fixed length, so you can access it via a C struct, like pgprocval-proargtypes[2]. With a normal array, things get much more complicated, and that cost would be fairly large if you want to resolve the argument types of function calls. (This is the reason that the maximum number of function parameters is limited to some arbitrary number.) So these two reasons make a namevector impractical: First, it would probably not be in the performance critical path. Second, it would use up a fixed length of NAMEDATALEN * FUNC_MAX_ARGS (currently 1024 bytes) in every pg_proc row. In this case, a regular name[] would be more suitable. Just be sure to put it after all the fixed-length fields. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Function parameter names
Peter Eisentraut [EMAIL PROTECTED] writes: Dennis Bjorklund writes: I'm in the middle of implementing function parameter names. So these two reasons make a namevector impractical: First, it would probably not be in the performance critical path. Second, it would use up a fixed length of NAMEDATALEN * FUNC_MAX_ARGS (currently 1024 bytes) in every pg_proc row. In this case, a regular name[] would be more suitable. Just be sure to put it after all the fixed-length fields. Actually I'd suggest text[], as there is no good reason to pad the array entries to a fixed length. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Function parameter names
On Sun, 23 Nov 2003, Peter Eisentraut wrote: How will that work in arbitrary procedural languages? It is passed along to the handler of the language, and if the language wants, it can insert these into its environment before execution. I plan to look at the languages pgsql and sql, but any other language can of course use it once it's implemented. It will still work if you do not give argument names of course. What is the reason for the oidvector to be it's own type instead of a oid[]? An oidvector is fixed length, so you can access it via a C struct, like pgprocval-proargtypes[2]. With a normal array, things get much more complicated, and that cost would be fairly large if you want to resolve the argument types of function calls. And the cost will be fairly large for named parameters as well then. On the other hand, if one omits the parameter names one would get almost the same speed as before (an extra test is needed to see if we have any parameter names that needs to be setup before the language handler is called). Second, it would use up a fixed length of NAMEDATALEN * FUNC_MAX_ARGS (currently 1024 bytes) in every pg_proc row. Yea, this I of course knew and was not happy about. In this case, a regular name[] would be more suitable. Just be sure to put it after all the fixed-length fields. I'll take a look at name[] then as the first try. -- /Dennis ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Function parameter names
On Sun, 23 Nov 2003, Tom Lane wrote: Actually I'd suggest text[], as there is no good reason to pad the array entries to a fixed length. The only reason against is that all other identifiers have this arbitrary limit. But sure, text[] would work just as well and without any restriction. Is the reason to use name at all in pg just about speed, or is there some other reason? -- /Dennis ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Function parameter names
Dennis Bjorklund [EMAIL PROTECTED] writes: Is the reason to use name at all in pg just about speed, or is there some other reason? Peter already explained it: we like fixed-width fields in system catalogs so that we can overlay C struct definitions onto the tuples. This is a fairly significant notational advantage in the backend code, whether or not you care about speed. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Function parameter names
Dennis Bjorklund [EMAIL PROTECTED] writes: And the cost will be fairly large for named parameters as well then. On the other hand, if one omits the parameter names one would get almost the same speed as before (an extra test is needed to see if we have any parameter names that needs to be setup before the language handler is called). I see absolutely no need for the call path to do anything with this stuff before it reaches the language handler. All the handlers fetch the pg_proc tuple anyway, and are perfectly capable of extracting the parameter names for themselves if they want to. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
