d another which would
indicate that there's postmaster's parent process running? - Using flock
and fcntl semantics respectively (or flock semantics with children
immediately closing their fds).
And of course locking is file system dependant, just think NFS on linux
where virtually no loc
en fcntl and flock in
Linux: although fork(2) states that file locks are not inherited, locks
made by flock are inherited to children and they keep the lock even when
the parent process is killed with SIGKILL. Tested this.
Just see man syscall, there exists both
flock(2)
and
fcntl(2
ildren still running?
--
Antti Haapala
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
On Mon, 27 Jan 2003, Antti Haapala wrote:
> I need this feature also. The problem with set session authorization is
> that you can always change back so it's not that secure. Actually I wanted
> to have a function that could augment the privileges of user if supplied
> the righ
a function in C.
But it could be better and easier to have pl/pgsql function that could set
the session authorization.
So, could it be made possible that pl/pgsql functions created by superuser
could "set session authorization" even when not called by superuser (or
user log
row if rows is 1,
otherwise oid is 0.
Wouldn't it be nice to add here
If table doesn't contain row oids, in place of oid
is the primary key of the newly inserted record (if any)
as column = 'value' [ and column = 'value [ and ... ]]
fresh brand new primary key from it? No thanks...
Anyways, I've got an idea: what about having option that INSERTs return
"oid_status" in form
major = '224' and minor = '10'
or
state = 'ca'
?
Then you could just
applications against newer DBMS) by having different information schemas
for different client versions... don't know, how it should be actually
done. Maybe there would be schemas "info_compat_74", "info_compat_75"
and "information_schema_80" in PostgreSQL 8.0 :P a
Ups... i sent an early draft of my post by accident, sorry...
--
Antti Haapala
+358 50 369 3535
ICQ: #177673735
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL
SHOW
I think 7.4 could and really should implement SHOW command similar to
MySQL. Listing tables/foreign keys/views and so isn't just psql problem,
but common to many interface implementations and maintenance tools. I
think it's wrong to rely on pg_* system tables on these.
If you think o
> I cannot think of any reason why changing column order should be
> implemented in Postgres. Seems like a waste of time/more code bloat for
> something which is strictly asthetic.
What about copy? AFAIK, copy doesn't allow column names being specified,
so it's not purely aesthetic...
-
ap.
They could be provided one... ;-)
> Upgrading MySQL Server is painless. When you are upgrading MySQL Server,
> you don't need to dump/restore your data, as you have to do with most
> PostgreSQL upgrades.
Ok... this is true, but not so hard - yesterday I installed 7.3b2
On 6 Oct 2002, Greg Copeland wrote:
> On Sat, 2002-10-05 at 14:46, Curtis Faith wrote:
> >
> > 2) aio_write vs. normal write.
> >
> > Since as you and others have pointed out aio_write and write are both
> > asynchronous, the issue becomes one of whether or not the copies to the
> > file system
1248
Actually nothing changes. The unique constraint doesn't add anything new -
it allows NULLs in column b and requires that combination (a, b) is
unique... and it definitely is because column 'a' is unique (primary key).
It just creates a multicol index and add
esponding newly inserted tuple in b?
Or should I just write my own triggers for checking the integrity of
"b"/"bref" column pair to avoid needless index creation?
--
Antti Haapala
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
15 matches
Mail list logo
