[SQL] ERROR: Procedures cannot take more than 16 arguments
Hello all, Using PostgreSQL 7.1.2 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66, I attempted to create a plpgsql function that takes 17 arguments and I received the error: ERROR: Procedures cannot take more than 16 arguments Can this limit be increased by manipulating some variable in the postgres source code? If so, how would I go about finding which file + variable I need to alter? If not, are there any plans for increasing that limit in future 7.1.x or 7.x releases? Thanks for any help, -Kristis ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[SQL] Re: [BUGS] ERROR: deferredTriggerGetPreviousEvent: event for tuple(0,9) not found
On 11 Jul 2001 13:56:58 -0400, Tom Lane wrote: > > but if I want to clear the valuntil completely, how should I issue the > > ALTER USER statement? > > Offhand I don't believe ALTER USER can do that. Feel free to submit > a patch ;-). This seems to have a similar effect: ALTER USER test VALID UNTIL 'infinity'; I could stick to this for now. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[SQL] Re: [BUGS] ERROR: deferredTriggerGetPreviousEvent: event for tuple(0,9) not found
> So that raises this from an unimplemented feature to a real bug, or at > least higher priority in my eyes. You can't do a CREATE/ALTER USER > followed by an UPDATE on pg_shadow in a single transaction: I'm glad I could be of some help. I don't know if the following means anything to you (or the pgsql-odbc folks), but in the past (I don't recall if that was postgres 7.0.3, 7.1.1 or 7.1.2) I used to get the following error message while issuing a "BEGIN, ALTER USER ..., COMMIT" block, coming in through an ODBC connection using VC++ 6 with the 7.01.00.05 driver: ERROR: ALTER USER: may not be called in a transaction block Doing a BEGIN, ALTER USER.., COMMIT (not through ODBC, through the psql client) now on 7.1.2 *seems* to work fine though. Should I take it that ALTER USER may indeed be used in a transaction block? I don't know if this was actually fixed or bugfixes to this might have something to do with the system trigger on pg_shadow, but I just thought I'll mention it in case it rings any more bells. I'm sure you know best. > The workaround I'd recommend to you for now is to use ALTER USER, not > UPDATE, to perform the second step in your function. So, how would I go about using the ALTER USER statement to clear out the valuntil value from the pg_shadow table? If I want to set an expiration date for the user, I can use a statement such as: ALTER USER test VALID UNTIL '2001-07-11 10:23:23-07' but if I want to clear the valuntil completely, how should I issue the ALTER USER statement? I have tried (with no success) the following so far: ALTER USER test VALID UNTIL NULL; ALTER USER test VALID UNTIL 'NULL'; ALTER USER test VALID UNTIL ''; Me failing to use the "ALTER USER" command successfully caused be to use the "UPDATE pg_shadow" instead. Thanks, -Kristis ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] trigger on DELETE
> Ok, the function works only with a trigger that is defined as ON INSERT > OR UPDATE. If I try to define a trigger for ON DELETE and then delete a > row from the table, there is nothing in the 'NEW' variable to return. I > get an error message. If I define the function to return NULL, 0, or > nothing, then it comes up with a type mis-match error. Is there anyone > who can help? Thanks. Try using the OLD variable instead. ---(end of broadcast)--- TIP 3: 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
