Am Montag, 1. August 2005 16:08 schrieb Bruce Momjian:
Would this not work in the context of the general user-specific ALTER
USER ... SET something = something?
No because it isn't a GUC variable, it is per-user/db value.
GUC supports per-user/per-db values.
--
Peter Eisentraut
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 1. August 2005 16:08 schrieb Bruce Momjian:
Would this not work in the context of the general user-specific ALTER
USER ... SET something = something?
No because it isn't a GUC variable, it is per-user/db value.
GUC supports
Peter Eisentraut wrote:
GUC supports per-user/per-db values.
We already had discussion here about GUC for this and we agreed that
catalog change is better than new GUC variable in this case.
--
Regards
Petr Jelinek (PJMODOS)
---(end of
Am Montag, 25. Juli 2005 18:31 schrieb Tom Lane:
Bruce Momjian pgman@candle.pha.pa.us writes:
The new syntax for this command is CREATE/ALTER DATABASE/USER:
| MAX CONNECTIONS Iconst
This adds 'max' as a keyword, though at a fairly unreserved level, I
think. Should we
Peter Eisentraut wrote:
Am Montag, 25. Juli 2005 18:31 schrieb Tom Lane:
Bruce Momjian pgman@candle.pha.pa.us writes:
The new syntax for this command is CREATE/ALTER DATABASE/USER:
| MAX CONNECTIONS Iconst
This adds 'max' as a keyword, though at a fairly unreserved
An updated version of your patch has been applied and will be in 8.1. Thanks.
---
pgman wrote:
I have worked over your patch and I think it is ready for application.
I changed the syntax to CONNECTION LIMIT, which
Bruce Momjian pgman@candle.pha.pa.us writes:
Peter Eisentraut wrote:
Would this not work in the context of the general user-specific ALTER USER
...
SET something = something?
No because it isn't a GUC variable, it is per-user/db value. We could
have used that syntax, but it might confuse
Here is promised documentation.
Be warned that both my writing skills and my english are far from good :)
--
Regards
Petr Jelinek (PJMODOS)
Index: doc/src/sgml/catalogs.sgml
===
RCS file:
Bruce Momjian pgman@candle.pha.pa.us writes:
I have worked over your patch and I think it is ready for application.
I've made another pass over this and should be able to commit tomorrow
(I'm about to knock off for today, and ran out of time to test
pg_dumpall). One thing I changed was that it
Bruce Momjian wrote:
I removed your use of the pg_auth flat file. By the time you have the
PROC entry to do your lookups, you might as well just use the system
cache.
There is a race condition in the code because we set our PROC entry
before we check for other entries. If there is one
Petr Jelinek wrote:
Bruce Momjian wrote:
I removed your use of the pg_auth flat file. By the time you have the
PROC entry to do your lookups, you might as well just use the system
cache.
There is a race condition in the code because we set our PROC entry
before we check for other
The new syntax for this command is CREATE/ALTER DATABASE/USER:
| MAX CONNECTIONS Iconst
This adds 'max' as a keyword, though at a fairly unreserved level, I
think. Should we use the syntax LIMIT CONNECTIONS so we don't have to
add MAX as a keyword at all?
Bruce Momjian pgman@candle.pha.pa.us writes:
The new syntax for this command is CREATE/ALTER DATABASE/USER:
| MAX CONNECTIONS Iconst
This adds 'max' as a keyword, though at a fairly unreserved level, I
think. Should we use the syntax LIMIT CONNECTIONS so we don't have to
add
Bruce Momjian wrote:
The new syntax for this command is CREATE/ALTER DATABASE/USER:
| MAX CONNECTIONS Iconst
This adds 'max' as a keyword, though at a fairly unreserved level, I
think. Should we use the syntax LIMIT CONNECTIONS so we don't have to
add MAX as a keyword at all?
Petr Jelinek wrote:
Bruce Momjian wrote:
The new syntax for this command is CREATE/ALTER DATABASE/USER:
| MAX CONNECTIONS Iconst
This adds 'max' as a keyword, though at a fairly unreserved level, I
think. Should we use the syntax LIMIT CONNECTIONS so we don't have to
Bruce Momjian napsal(a):
I am ready to apply this patch. Would you make the additional changes
you suggested? Is there any way to see the limits except to query
pg_authid?
Yes I will - pg_dump is already done (I attached it because it should be
aplied with orginal patch), documentation
Alvaro Herrera wrote:
I was wondering if there was some way to defer the user check till a
later time, when the pg_authid relation could be checked? Not sure if
that's a good idea, but it may help reduce the impact of the change, and
thus chances that it'd be rejected.
Well It can, but it
Stephen Frost wrote:
This should almost certainly be a pg_database_ownercheck() call instead.
Right there wasn't pg_database_ownercheck at the time I was writing it,
fixed
The rest needs to be updated for roles, but looks like it should be
pretty easy to do. Much of it just needs to be
On Mon, Jul 04, 2005 at 01:08:05AM +0200, Petr Jelinek wrote:
Stephen Frost wrote:
New version which works with roles is attached (diffed against cvs),
everything else is mostly same.
I also had to readd roleid to flatfiles because I need it in
InitProcess() function.
I was wondering if
We will need these:
Patch includes only changes to backend, I will make pg_dump, ecpg and
documentation patches once this is completed and accepted by team.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will
On Sat, Jul 02, 2005 at 04:28:48PM -0400, Bruce Momjian wrote:
We will need these:
Patch includes only changes to backend, I will make pg_dump, ecpg and
documentation patches once this is completed and accepted by team.
Your patch has been added to the PostgreSQL unapplied patches list
Alvaro Herrera wrote:
On Sat, Jul 02, 2005 at 04:28:48PM -0400, Bruce Momjian wrote:
We will need these:
Patch includes only changes to backend, I will make pg_dump, ecpg and
documentation patches once this is completed and accepted by team.
Your patch has been added to the
* Petr Jelinek ([EMAIL PROTECTED]) wrote:
+ if (!(superuser()
+ || ((Form_pg_database) GETSTRUCT(tuple))-datdba ==
GetUserId()))
+ aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_DATABASE,
+stmt-dbname);
This should almost
23 matches
Mail list logo
