This wasn't encountered in my original patch because
pg_tablespace_aclmask() had this test reasonably early on:
+ if(tbloid == DEFAULTTBLSPC)
+ return (mask);
I guess that might have been a bit presumptuous but a similar thing
happens if you don't specify a tablespace:
tablespaceId
Gaetano Mendola wrote:
Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
I think a warning is missing if I create a table without OIDS that
inherits from a table with oids:
don't you think a warning shall to be raised here ?
Nope ... this is not different from the behavior for merging
On Mon, 28 Jun 2004, Satoshi Nagayasu wrote:
> If I set statement_timeout to 1000 to detect a lock timeout,
> I can't run a query which takes over 1 sec.
>
> If a lock wait is occured, I want to detect it immediately,
> but I still want to run a long-running query.
Why is it important what it is
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Chris KL just raised an issue on IRC:
> test=> create table test (a int4) tablespace pg_default;
> ERROR: permission denied for tablespace pg_default
This is not a bug. If you don't have tablespace permissions, you don't
get to specify where your table
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> That way, an admin can force users to NOT use the default tablespace if
> they wish, even though the users have CREATE table rights on the schema.
I think the above statement is nonsensical. Perhaps you are confusing
the notions of "default t
BTW, it occurs to me that there's a bug in the current implementation of
CREATE DATABASE when you change the database's default tablespace.
The CREATE DATABASE code assumes that it can physically copy all content
of the old-database's-default-tablespace into the
new-database's-default-tablespace, r
Dear Tom,
> BTW, it occurs to me that there's a bug in the current implementation of
> CREATE DATABASE when you change the database's default tablespace.
> [...]
> Now, when looking at the new database's reltablespace column, it will
> appear that that table is in the old database's default table
Fabien COELHO <[EMAIL PROTECTED]> writes:
> It's more a "fix-me later" approach, but it does not look that bad, IMHO.
It seems a bit risky to me. The worst possible consequence of the
ownership stuff not happening is that objects have wrong ownership
(and even there it's not so much "wrong" as "w
On Mon, 28 Jun 2004, Tom Lane wrote:
> I don't see any reasonable way for CREATE DATABASE to avoid this
> problem, since it can't necessarily look inside the source database.
> My thought is that the cleanest fix is to never allow reltablespace
> (or nsptablespace) to explicitly specify the databa
I have set returning function written in 'c', declared as:
CREATE OR REPLACE FUNCTION check_view (text,text) RETURNS setof pg_attribute
AS '/usr/local/pgsql/lib/libplpq.so','check_view' LANGUAGE 'c'
WITH (isstrict);
When I call this function from psql :
SELECT attrelid,attnum FROM che
On Mon, 2004-06-28 at 02:16, Satoshi Nagayasu wrote:
> Tom Lane wrote:
> > I'd accept a mechanism to enforce a timeout at the lock level if you
> > could show me a convincing use-case for lock timeouts instead of
> > statement timeouts, but I don't believe there is one. I think this
> > proposal i
Darko Prenosil <[EMAIL PROTECTED]> writes:
> Anyone knows what I'm doing wrong ?
Well, when you didn't show us the text of the function, no.
However, a reasonable bet would be that you used SPI inside the function
and did not use it correctly, leaving the SPI state corrupted when
control got back
Here is the source, but now when You mentioned SPI state, I see that I put
SPI_finish stupidly after SRF_RETURN_NEXT(funcctx, result);
Could that be my problem ?
Regards !
PG_FUNCTION_INFO_V1(check_view);
Datum
check_view(PG_FUNCTION_ARGS)
{
FuncCallContext *funcctx;
MemoryContext oldcontext;
Robert Treat wrote:
>>I think statement_timeout and lock_timeout are different.
>>
>>If I set statement_timeout to 1000 to detect a lock timeout,
>>I can't run a query which takes over 1 sec.
>>
>>If a lock wait is occured, I want to detect it immediately,
>>but I still want to run a long-running q
Dennis Bjorklund wrote:
>>If I set statement_timeout to 1000 to detect a lock timeout,
>>I can't run a query which takes over 1 sec.
>>
>>If a lock wait is occured, I want to detect it immediately,
>>but I still want to run a long-running query.
>
>
> Why is it important what it is that makes you
Would anyone else think that dumping:
SET client_min_messages TO warning;
In pg_dumps would be cool?
It would mean that while restoring a dump you can actually see the wood
for the trees when trying to see ERRORs and WARNINGs the the massive
spam of messages you get while restoring.
Chris
--
As part of my testing, I noticed this bug. My database has a
search_path set in the database vars. It dumps lik ethis:
DROP DATABASE usa;
CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING =
'LATIN1';
ALTER DATABASE usa SET search_path TO 'public, contrib';
Notice the sing
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is a fix for this required for only search_path, or is it a more general
> problem?
I think this has to be driven off the GUC_LIST_INPUT and/or
GUC_LIST_QUOTE flag bits (too late at night to remember just what those
two flags do, but one or bo
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Would anyone else think that dumping:
> SET client_min_messages TO warning;
> In pg_dumps would be cool?
> It would mean that while restoring a dump you can actually see the wood
> for the trees when trying to see ERRORs and WARNINGs the the
19 matches
Mail list logo
