Re: [PATCHES] plpgsql: check domain constraints

2006-01-09 Thread Neil Conway
On Sun, 2006-01-08 at 23:56 -0500, Tom Lane wrote: We have gone out of our way to make sure that domain constraint checking responds promptly (ie, within one query) to updates of the domain definition. Caching at the session level in plpgsql would be a significant regression from that, and I

[PATCHES] CREATEUSER == SUPERUSER?

2006-01-09 Thread Yoshiyuki Asaba
Hi, The following command makes a superuser. Is this correct? template1=# CREATE USER xyz CREATEUSER; CREATE ROLE template1=# select rolname,rolsuper from pg_roles where rolname = 'xyz'; rolname | rolsuper -+-- xyz | t (1 row) I think CREATEUSER keyword is equal to

[PATCHES] pl/python refcount bug

2006-01-09 Thread Neil Conway
In PLy_function_build_args(), the code loops repeatedly, constructing one argument at a time and then inserting the argument into a Python list via PyList_SetItem(). This steals the reference to the argument: that is, the reference to the new list member is now held by the Python list itself. This

Re: [PATCHES] plpgsql: check domain constraints

2006-01-09 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: GetDomainConstraints() looks fairly expensive, so it would be nice to do some caching. What would the best way to implement this be? I had thought that perhaps the typcache would work, but there seems to be no method to flush stale typcache data. Perhaps

Re: [PATCHES] CREATEUSER == SUPERUSER?

2006-01-09 Thread Tom Lane
Yoshiyuki Asaba [EMAIL PROTECTED] writes: The following command makes a superuser. Is this correct? template1=# CREATE USER xyz CREATEUSER; Yes, read the CREATE ROLE documentation: CREATEUSER NOCREATEUSER These clauses are an obsolete, but still accepted, spelling of SUPERUSER and

[PATCHES] Proposed patch to change missing FROM messages

2006-01-09 Thread Tom Lane
Attached is a proposed change to create hopefully-more-useful error messages in the cases where we currently say missing FROM-clause entry. Some examples of what it does: Patch: regression=# select * from a,b join c on (a.aa = c.cc); ERROR: invalid reference to FROM-clause entry for table a

Re: [PATCHES] Proposed patch to change missing FROM messages

2006-01-09 Thread Michael Glaesemann
On Jan 10, 2006, at 8:32 , Tom Lane wrote: Attached is a proposed change to create hopefully-more-useful error messages in the cases where we currently say missing FROM-clause entry. It's good to have these hints for users. Thanks, Tom. Patch: regression=# select * from a,b join c on

Re: [PATCHES] pl/python refcount bug

2006-01-09 Thread Neil Conway
On Mon, 2006-01-09 at 13:07 -0500, Neil Conway wrote: The fix is simple: set the local pointer to the current argument to NULL immediately after adding it to the argument list. This ensures that the Py_XDECREF() in the PG_CATCH() block doesn't double-decrement. I'd like to apply this to HEAD

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-09 Thread Bruce Momjian
Bruce Momjian wrote: Tom Lane wrote: I wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Does the standard require USAGE to support currval? currval isn't in the standard (unless I missed something), so it has nothing to say one way or the other on the point. Wait, I take

Re: [PATCHES] Proposed patch to change missing FROM messages

2006-01-09 Thread Tom Lane
Michael Glaesemann [EMAIL PROTECTED] writes: For clarity, I'd rewrite this hint as There is an entry for table a, ... Done. Anyone have any other suggestions for wording improvements? regards, tom lane ---(end of

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-09 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: At first I was just going to continue allowing table-like permissions for sequences if a GRANT [TABLE] was used, and add the new USAGE/SELECT/UPDATE capability only for GRANT SEQUENCE. The problem was that you could create a non-dumpable permission

Re: [PATCHES] TODO-item: Add sleep() function, remove from regress.c

2006-01-09 Thread Tom Lane
Joachim Wieland [EMAIL PROTECTED] writes: I'd personally prefer to call the function pg_sleep(), but since it is called sleep() on the TODO list and in previous discussions, I kept the name. The internal function is called pg_sleep() however. pg_sleep seems like a better idea to me too. Why

Re: [PATCHES] TODO-item: Add sleep() function, remove from regress.c

2006-01-09 Thread Tom Lane
BTW, a serious problem with just passing it off to pg_usleep like that is that the sleep can't be aborted by a cancel request; doesn't seem like a good idea to me. I'd suggest writing a loop that sleeps for at most a second at a time, with a CHECK_FOR_INTERRUPTS() before each sleep. This would

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-09 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: At first I was just going to continue allowing table-like permissions for sequences if a GRANT [TABLE] was used, and add the new USAGE/SELECT/UPDATE capability only for GRANT SEQUENCE. The problem was that you could create a

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-09 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: Just ignore the inapplicable permissions during pg_dump. I think you're making this harder than it needs to be... I don't think we should allow GRANT DELETE ON seq in 8.2 for invalid permission. That's fine, but pg_dump has to