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
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 CREATER
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. Thi
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. Perh
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 a
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"
H
I propose the appended patch for the todo item:
* Add sleep() function, remove from regress.c
The patch also removes do_sleep() from the regression and substitues this
with the call to the new function.
I'd personally prefer to call the function pg_sleep(), but since it is
called sleep() on the
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 (a
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 HEA
Bruce Momjian wrote:
> Tom Lane wrote:
> > I wrote:
> > > Bruce Momjian 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 t
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 broadcast)
Bruce Momjian 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 setup if you added
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.
W
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 al
Tom Lane wrote:
> Bruce Momjian 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 per
Bruce Momjian 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 continue to work a
16 matches
Mail list logo
