> On Thu, 2002-03-21 at 23:41, Christopher Kings-Lynne wrote:
> > > > Exactly what semantics do you have in mind?
> > >
> > > The current syntax I'm using is:
> > >
> > > NOTIFY condition_name [ [WITH MESSAGE] 'my message' ];
> > >
> > > But I'm open to suggestions for improvement.
> >
> > Have
On Thu, 2002-03-21 at 23:41, Christopher Kings-Lynne wrote:
> > > Exactly what semantics do you have in mind?
> >
> > The current syntax I'm using is:
> >
> > NOTIFY condition_name [ [WITH MESSAGE] 'my message' ];
> >
> > But I'm open to suggestions for improvement.
>
> Have you considered v
On Fri, Mar 22, 2002 at 02:34:57PM +0800, Christopher Kings-Lynne wrote:
> > > Do we want the above syntax, or this syntax:
> > >
> > > ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> > > ALTER TABLE blah ALTER COLUMN col SET NULL;
> >
> > My only objection to the second command is that it's pl
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Unfortunately, that would give us two places to specify
> > the connecting users, pg_hba.conf and GRANT CONNECT. Is that a problem?
>
> Yes. What if they conflict?
>
> I don't think GRANT CONNECT fits into our setup at all. I als
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Unfortunately, that would give us two places to specify
> the connecting users, pg_hba.conf and GRANT CONNECT. Is that a problem?
Yes. What if they conflict?
I don't think GRANT CONNECT fits into our setup at all. I also doubt
that it will be needed
> > Do we want the above syntax, or this syntax:
> >
> > ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> > ALTER TABLE blah ALTER COLUMN col SET NULL;
>
> My only objection to the second command is that it's plain wrong. You
> don't set anything to NULL, so don't make the command look like it.
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I have another idea. What if we had a default group for each database,
> > like pg_connect_{dbname}, and you can add/remove users from that group
> > to grant/remove connection privileges?
>
> That strikes me as a very ugly abuse of the priv
Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > Say in the future we want to support changing column type as well. How
> > would we work that in?
>
> > ALTER TABLE blah ALTER COLUMN col SET int4; ??
>
> Seems one keyword shy of a load; I'd prefer
>
> ALTER TABL
Christopher Kings-Lynne writes:
> Do we want the above syntax, or this syntax:
>
> ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> ALTER TABLE blah ALTER COLUMN col SET NULL;
My only objection to the second command is that it's plain wrong. You
don't set anything to NULL, so don't make the co
Bruce Momjian writes:
> I have another idea. What if we had a default group for each database,
> like pg_connect_{dbname}, and you can add/remove users from that group
> to grant/remove connection privileges?
That strikes me as a very ugly abuse of the privilege system. If you want
to grant a
> Seems one keyword shy of a load; I'd prefer
>
> ALTER TABLE blah ALTER COLUMN col SET TYPE int4;
>
> Otherwise, every keyword that might appear after SET will have to be
> fully reserved (else it couldn't be distinguished from a type name).
I like that...
So would you then envisage something l
> Does it mean that we are not 100% sure they are open documents?
Hmm. Yeah, though afaics there is no copyright inside the docs.
- Thomas
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.post
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Say in the future we want to support changing column type as well. How
> would we work that in?
> ALTER TABLE blah ALTER COLUMN col SET int4; ??
Seems one keyword shy of a load; I'd prefer
ALTER TABLE blah ALTER COLUMN col SET TYPE i
Hi,
I'm halfway thru implementing setting a column's nullness (I've done
changing to null,
but not changing to not null)
Peter E. said:
> Using the standard precedent above, how about
>
> ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> ALTER TABLE blah ALTER COLUMN col DROP NOT NULL;
Do we w
Does it mean that we are not 100% sure they are open documents?
- Original Message -
From: "Thomas Lockhart" <[EMAIL PROTECTED]>
To: "Nicolas Bazin" <[EMAIL PROTECTED]>
Cc: "Christopher Kings-Lynne" <[EMAIL PROTECTED]>; "Tom Lane"
<[EMAIL PROTECTED]>; "Rod Taylor" <[EMAIL PROTECTED]>; "Hac
pgman wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > I am adding users and groups to pg_hba.conf.
> >
> > You know what would be cool?
> >
> > GRANT CONNECT ON mydb TO GROUP myfriends;
> >
> > and it rewrites pg_hba.conf accordingly.
> >
> > Just a thought...
>
> We are
Thomas Lockhart wrote:
> > It would be nice to add it to the docs of the project.
>
> If anyone wants a copy, just holler. A bunch of us have exchanged those
> drafts over the years so speak up and someone will forward you a copy...
>
> I'm sure we stumbled on them via google or somesuch so a qu
Neil,
Following is an email I sent the other day detailing how this works.
The entry point to the underlying invalidation system is the heap
manipulation functions: heap_delete(), heap_update(). (I've just had a
quick look at heap_insert() and cannot find where the cache modification
takes place
> > Exactly what semantics do you have in mind?
>
> The current syntax I'm using is:
>
> NOTIFY condition_name [ [WITH MESSAGE] 'my message' ];
>
> But I'm open to suggestions for improvement.
Have you considered visiting the oracle site and finding their documentation
for their NOTIFY sta
Neil Conway <[EMAIL PROTECTED]> writes:
>> BTW, I would like to see a spec for this "notify with parameter" feature
>> before it's implemented, not after.
> The current syntax I'm using is:
> NOTIFY condition_name [ [WITH MESSAGE] 'my message' ];
Hm. How are you going to transmit that to
> It would be nice to add it to the docs of the project.
If anyone wants a copy, just holler. A bunch of us have exchanged those
drafts over the years so speak up and someone will forward you a copy...
I'm sure we stumbled on them via google or somesuch so a quick search
would get you an indepen
On Thu, 2002-03-21 at 22:41, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Solution: Create a new system catalog, pg_notify.
>
> It's not apparent to me why that helps much.
Well, it solves the functional problem at hand -- this feature can now
be implemented. However, I agree wi
It would be nice to add it to the docs of the project.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Christopher Kings-Lynne" <[EMAIL PROTECTED]>
Cc: "Rod Taylor" <[EMAIL PROTECTED]>; "Hackers List"
<[EMAIL PROTECTED]>
Sent: Friday, March 22, 2002 1:29 PM
Subject: Re: [HAC
Neil Conway <[EMAIL PROTECTED]> writes:
> Solution: Create a new system catalog, pg_notify.
It's not apparent to me why that helps much.
There is a very significant performance problem with LISTEN/NOTIFY
via pg_listener: in any application that generates notifications at
a significant rate, pg_l
Bruce Momjian wrote:
>
> Now, as far as rewriting pg_hba.conf, that goes into an area where we
> are not sure if the master connection information is in the file or in
> the database. We also get into a chicken and egg case where we have to
> have the database loaded to connect to it. I am inte
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I am adding users and groups to pg_hba.conf.
>
> You know what would be cool?
>
> GRANT CONNECT ON mydb TO GROUP myfriends;
>
> and it rewrites pg_hba.conf accordingly.
>
> Just a thought...
We are actually not that far away. If you crea
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I seem to have parts 1-5 .txt of sql99 on my computer here. I ftp'd them
> off some ftp site yonks ago. Anyone want them? Is it legal for me to have
> them or distribute them?
My understanding of the legal situation is that what's circula
Bruce Momjian writes:
> I am adding users and groups to pg_hba.conf.
You know what would be cool?
GRANT CONNECT ON mydb TO GROUP myfriends;
and it rewrites pg_hba.conf accordingly.
Just a thought...
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)-
Jeff Davis asked on -general why NOTIFY doesn't take an optional
argument, specifying a message that is passed to the listening backend.
This feature is supported by Oracle and other databases and I think it's
quite useful, so I've started to implement it. Most of the modifications
have been prett
Christopher Kings-Lynne wrote:
> > "Rod Taylor" <[EMAIL PROTECTED]> writes:
> > > I've not found a cheap resource for the real one. Ie. priced suitably
> > > to fit a hobby project :)
>
> I seem to have parts 1-5 .txt of sql99 on my computer here. I ftp'd them
> off some ftp site yonks ago. An
Just remember that patches for 7.3 are being accepted at this very moment...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Igor Kovalenko
> Sent: Friday, 22 March 2002 1:31 AM
> To: Luis Alberto Amigo Navarro
> Cc: [EMAIL PROTECTED]; [EMAI
> "Rod Taylor" <[EMAIL PROTECTED]> writes:
> > I've not found a cheap resource for the real one. Ie. priced suitably
> > to fit a hobby project :)
I seem to have parts 1-5 .txt of sql99 on my computer here. I ftp'd them
off some ftp site yonks ago. Anyone want them? Is it legal for me to have
I've been able to compile previous versions of PostgreSQL on my SGI
machines, but am having trouble this time. I have an SGI O2 with IRIX
6.5.15f, gmake 3.79.1, and MIPSPro C 7.3.1.3 compiler. I can get
through the 'configure' step fine. I've copied the Makefile.irix5 up
to the src directory. I've
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> It would be fairly straight forward to simply copy the domain base
> type into the atttypid, then create an atttypdomain (normally 0,
> except in the case of a domain). Everything would use the attypid,
> except for \d and pg_dump which could use the do
> If we take the hard SQL99 line that domains *are* the base type plus
> constraints, then we could reduce domains to base types before we
start
> the entire matching process, and this issue would go away. This
would
> prevent declaring any specialized operators or functions for a
domain.
> (In f
Tom Lane wrote:
>
> If we take the hard SQL99 line that domains *are* the base type plus
> constraints, then we could reduce domains to base types before we start
> the entire matching process, and this issue would go away. This would
> prevent declaring any specialized operators or functions fo
Igor Kovalenko wrote:
> No, I've been told it is not gonna be considered for 7.2x and I shall
> wait till 7.3.
>
> Luis Alberto Amigo Navarro wrote:
> >
> > > Makes me wonder... perhaps now someone will be convinced to take a look
> > > at the POSIX IPC patch. On some platforms (not on Linux I am
No, I've been told it is not gonna be considered for 7.2x and I shall
wait till 7.3.
Luis Alberto Amigo Navarro wrote:
>
> > Makes me wonder... perhaps now someone will be convinced to take a look
> > at the POSIX IPC patch. On some platforms (not on Linux I am afraid)
> > POSIX mutexes might be
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> We could treat exact and binary-compatible matches alike (doesn't seem
>> good), or put a special case into the operator selection rules to reduce
>> domains to their basetypes before making the "exact match" test.
> There could also be an explicit h
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> I've not found a cheap resource for the real one. Ie. priced suitably
> to fit a hobby project :)
Try ANSI's electronic standards store: they'll sell you PDFs of ANSI's
printing of the spec at a reasonable price.
http://webstore.ansi.org/ansidocstore/d
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The problem is when to retokenize pg_hba.conf after a new pg_group is
> > made. Seems I can either force administrators to 'pg_ctl reload' to
> > update for group changes, or automatically retokenize pg_hba.conf every
> > time I upda
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, that was the issue. We tell people pg_hba.conf only gets reloaded
> > when they tell the postmaster to do it. We can't have it happening at
> > random times, e.g. password change.
>
> I agree on that: the signal should cause t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, that was the issue. We tell people pg_hba.conf only gets reloaded
> when they tell the postmaster to do it. We can't have it happening at
> random times, e.g. password change.
I agree on that: the signal should cause the postmaster to reload
pg_p
Ross J. Reedstrom wrote:
> On Thu, Mar 21, 2002 at 11:38:05AM -0500, Bruce Momjian wrote:
> >
> > I am handling it like pg_shadow. The problem is that because I expand
> > pg_group inside the pg_hba tokens, I have to retokenize pg_hba.conf too
> > after pg_group changes. I assumed we didn't want
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> regression=# SELECT update_pg_pwd();
>> ERROR: getTypeOutputInfo: Cache lookup of type 0 failed
> Wouldn't it be nice to make this a feature that allows
> stored procedures (void update_pg_pwd ()) ? Correctly register
> this function to
> > Not entirely sure, except the book I had (SQL99 Complete, Really)
> > specifically forbids it.
> >
>
> Yes, but this is their interpretation of the standard. There is an
Understood. It's the best that I had on me.
I've not found a cheap resource for the real one. Ie. priced suitably
to fit
Oliver Elphick writes:
> > > Upstream automatically passes -mips2 to gcc on mips platforms. In the case
> > > of Linux, this should not be done, as the main reason to use it (ll/sc) is
> > > handled by glibc and emulated by the kernel. It also makes all of postgresql
> > > unusable on DECstatio
...
> The problem seems to be that when parse_func looks for "exact match"
> operators, it doesn't consider numeric to be an exact match for mydom.
> So that heuristic fails and we're left with no unique best choice for
> the operator.
Sure. At the moment there is no reason for parse_func to thin
> Removing the special-case logic in ExecTypeFromTL yields
>
> regression=# SELECT update_pg_pwd();
> ERROR: getTypeOutputInfo: Cache lookup of type 0 failed
Wouldn't it be nice to make this a feature that allows
stored procedures (void update_pg_pwd ()) ? Correctly register
this function to n
I sent a message about this yesterday, but it does not appear to have
got to the list.
According to the attached message, mips builds for Linux should not use
-mips2 in the compilation or linking. It appears that this can be
prevented by removing the mips special case from src/template/linux.
-
I will be on vacation from tomorrow up to April 6th. So don't expect any
answer prior early April from me.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)---
TIP 1
I've done some meditions with timex, it uses sar(System activity register)
to take workloads, it's not very relliable, but it allow us to see how it is
been doing, it has been taken during an execution of a like tpc-h
benchmark, it performs inserts, deletes(about 5% of the time of the
execution)
I think I have figured out a way to do this efficiently. Instead of
making pg_group with groupname/username on each line, I will do
groupname/username,username, ... so I can spin through the group token
file much quicker; that way, I can read just retokenize pg_group and
spin through it for eac
> Makes me wonder... perhaps now someone will be convinced to take a look
> at the POSIX IPC patch. On some platforms (not on Linux I am afraid)
> POSIX mutexes might be quite a bit faster than SYSV semaphores.
>
Is there any current patch?
Regards
---(end of broadcast
54 matches
Mail list logo
