Hi Magnus,
Magnus Wrote:
I'dbeinterestedinseeingtheoutputfromthecommand: Subinacl/serviceNULL Onasystemwherethisdoesnotwork.
Here is the output for "Subinacl/serviceNULL"
Both, for the Administrator user and for the Postgres user:
Postgres user:
Subinacl /service NULLSeSecurityPrivilege :
OTRS was recommended to me as a bug tracker. Has anyone used that?
Nope, but looking at their demo i tseems they're actually *using* the
blink HTML tag. Which probably should disqualify it out of hand ;-)
That's just evil...
//Magnus
---(end of
Tom Lane wrote:
Almost everything I just said is already how it works today; the
difference is that today you do not have the option to drop t1 without
dropping the sequence, because there's no (non-hack) way to remove the
dependency.
As far as I understand your proposal I like it, but
Andreas Pflug wrote:
Tom Lane wrote:
Almost everything I just said is already how it works today; the
difference is that today you do not have the option to drop t1 without
dropping the sequence, because there's no (non-hack) way to remove the
dependency.
As far as I understand your
I thought I'd like to report that right now the Coverity reports are
looking good. There are no issues detected in either the backend code
or the ECPG library. For the latter I'd like the thank Joachim Wieland
and Michael Meskes for getting ECPG into shape.
Whats basically left is a large number
Andreas Pflug [EMAIL PROTECTED] writes:
As far as I understand your proposal I like it, but I'd like to insure
that the situation where a sequence is used by multiple tables is
handled correctly. There _are_ databases that reuse a sequence for
multiple serial-like columns, and pgadmin supports
Andrew Dunstan [EMAIL PROTECTED] writes:
If we were implementing serial from scratch, I would be arguing that the
underlying sequence should be merely an implementation detail that should
be totally hidden, and sequences used explicitly should be kept as a
separate concept. Then many of these
On Sun, Aug 20, 2006 at 03:49:24PM +0200, Martijn van Oosterhout wrote:
Whats basically left is a large number of memory leaks in frontend
applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever
really been a priority (buildACLCommands is really bad in this
respect).
...
If
Martijn van Oosterhout kleptog@svana.org writes:
Whats basically left is a large number of memory leaks in frontend
applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever
really been a priority (buildACLCommands is really bad in this
respect).
Well, if Coverity's idea of good
Martijn van Oosterhout wrote:
I thought I'd like to report that right now the Coverity reports are
looking good. There are no issues detected in either the backend code
or the ECPG library. For the latter I'd like the thank Joachim Wieland
and Michael Meskes for getting ECPG into shape.
Whats
I'm using partitioned tables a lot and loving it. I have a suggestion
that I believe would make it easier to bring the performance and
maintenance advantages of partitions to more applications and users:
As I understand it, at present I can select records from sales_master
and get data returned
April Lorenzen [EMAIL PROTECTED] writes:
My suggestion is to allow specifying a default destination table in
the master partition table definition. This default destination table
could be changed with ALTER TABLE.
The recommended way to do this is with an ON INSERT DO INSTEAD rule
on the
Keep in mind if you have multiple rules for a master table, it won't return the number of affected rows as you might expect. This screws up Hibernate which I'm using for my application. It checks the return value to make sure it was inserted properly. Luckily I only need one rule which puts it
Tom Lane wrote:
If you insist on initially creating the sequence by saying SERIAL for
the first of the tables, and then saying DEFAULT nextval('foo_seq')
for the rest, then under both 8.1 and my proposal you'd not be able to
drop the first table without dropping the sequence (thus requiring
On Sun, Aug 20, 2006 at 11:52:53AM -0400, Tom Lane wrote:
Well, if Coverity's idea of good programming practice is that every
program must explicitly free everything it ever malloced before it
terminates, then I'm afraid we'll have to agree to disagree. The
I don't think Coverity even knows
Andreas Pflug [EMAIL PROTECTED] writes:
I basically doubt the concept of a single owner. I'd expect a sequence
to be dropped from cascaded table dropping, if that was the last usage
and dependencies existed. This would probably mean multiple owners.
That's not going to happen without extensive
Bruce Momjian [EMAIL PROTECTED] writes:
What method will people use to see if a sequence used as a default is
one that was created by SERIAL, and will be dropped by drop table, or
manually created? How does that distinction show up in pg_dump?
Hm. It will show in pg_dump because there will
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
I basically doubt the concept of a single owner. I'd expect a sequence
to be dropped from cascaded table dropping, if that was the last usage
and dependencies existed. This would probably mean multiple owners.
That's not going to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
What method will people use to see if a sequence used as a default is
one that was created by SERIAL, and will be dropped by drop table, or
manually created? How does that distinction show up in pg_dump?
Hm. It will show in
On Sun, Aug 20, 2006 at 11:52:53AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Whats basically left is a large number of memory leaks in frontend
applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever
really been a priority (buildACLCommands is
(btw, clinically insane without patching it.. And obviously
you didn't
patch yours? :-P)
Yeah, well it's behind all manner of firewalls, doing nothing
but buildfarm runs of which I ran the first before WSUS had
installed all the pending updates :-p
Excuses, excuses... ;)
//Magnus
Bruce Momjian [EMAIL PROTECTED] writes:
Also, if someone restores one table, does the sequence come with it like
it does now with SERIAL?
Hm, probably not. I do have pg_dump set to force dumping of the
sequence if you try to dump just its table, but it'd be possible to tell
pg_restore (via -l)
Bruce Momjian [EMAIL PROTECTED] writes:
What method will people use to see if a sequence used as a default is
one that was created by SERIAL, and will be dropped by drop table, or
manually created? How does that distinction show up in pg_dump?
BTW, it's easy to see if a column has an
I have a PostgreSQL installation on a Debian box that had the 64bit SMP
kernel installed before PostgreSQL was compiled and installed on it.
Does PostgreSQL take any advantage of the 64 bit environment or have we
not done anything to move into the 64 bit world yet?
Regards,
- Naz
Naz Gassiep [EMAIL PROTECTED] writes:
I have a PostgreSQL installation on a Debian box that had the 64bit
SMP kernel installed before PostgreSQL was compiled and installed on
it. Does PostgreSQL take any advantage of the 64 bit environment or
have we not done anything to move into the 64 bit
Douglas McNaught wrote:
Naz Gassiep [EMAIL PROTECTED] writes:
I have a PostgreSQL installation on a Debian box that had the 64bit
SMP kernel installed before PostgreSQL was compiled and installed on
it. Does PostgreSQL take any advantage of the 64 bit environment or
have we not
Naz Gassiep [EMAIL PROTECTED] writes:
I just compiled as the manual says. I guess I must have compiled it
in 32. I'll recompile in 64 when I upgrade to 8.2 when it's out.
The 'file' command will tell you whether a binary is 32- or 64-bit.
If you have a full 64-bit install, you'll get a 64-bit
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The part of this that would actually be useful to put in core is
maintaining a 64-bit XID counter, ie, keep an additional counter that
bumps every time XID wraps around. This cannot be done very well from
outside core but it would be
All,
We use OTRS for customer issue tracking, but we use Jira from Atlassian
for our internal bug tracking. We also use Confluence and Fisheye from
Atlassian, and they are all excellent tools IMO.
OTRS has been OK and fairly malleable.
Actually, having done a fairly significant amount of
I found one other problem in this area, which was that REASSIGN OWNED
didn't work real well either after I changed serial sequences'
dependency type to AUTO. What I did about it was to make
shdepReassignOwned call ATExecChangeOwner with recursing = true,
which suppresses all those tedious error
On Sun, Aug 20, 2006 at 04:46:30PM -0400, Douglas McNaught wrote:
Naz Gassiep [EMAIL PROTECTED] writes:
I have a PostgreSQL installation on a Debian box that had the 64bit
SMP kernel installed before PostgreSQL was compiled and installed on
it. Does PostgreSQL take any advantage of the 64
On 8/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Is there an interest, or any active project to examine PostgreSQL in
the area of 64-bit processors? Has it already been done? I don't recall
seeing a reference to it in my travels. I'm also not sure on what to
expect for results, as the
[EMAIL PROTECTED] writes:
Is there an interest, or any active project to examine PostgreSQL in
the area of 64-bit processors? Has it already been done? I don't recall
seeing a reference to it in my travels. I'm also not sure on what to
expect for results, as the territory is still new. 64-bit
Naz,
On 8/20/06 12:59 PM, Naz Gassiep [EMAIL PROTECTED] wrote:
I have a PostgreSQL installation on a Debian box that had the 64bit SMP
kernel installed before PostgreSQL was compiled and installed on it.
Does PostgreSQL take any advantage of the 64 bit environment or have we
not done
WRT 64-bit and Postgres, it depends on the CPU as to whether you see a
simple performance benefit. On the Opteron you will see a benefit when
doing CPU bound work. When doing the CPU portion, the additional registers
of the Opteron running in 64-bit mode are used by the compiler to produce a
One person who commented on the The business of Postbrsql made this comment:
Posted Aug 3, 2006 8:45 UTC (Thu) by subscriber *jgarzik* [Link
http://lwn.net/Articles/193946/]Cluster immaturity. MySQL has been
shipping a workable single-master replication+failover for quite a while
now in most
In contrast, the PostgreSQL team has chosen to provide hooks for
replication and failover. This has led to a situation where there are
multiple projects supporting replications/failover, none of which are
production-ready nor shipped in a modern Linux distro.
And no, we don't really provide
Josh,
On 8/20/06 8:52 PM, Joshua D. Drake [EMAIL PROTECTED] wrote:
Is that true of even Woodcrest?
Joshua D. Drake
Not sure - haven't read anything about the register set on the Core 2 to
make me think it benefits from 64 bit.
The point may be academic from now on though - the comparisons
As my last mail did not seem to go through here one more try ...
When looking at some fairly complex SQL stuff I came across some
interesting issue which is a bit surprising to me:
CREATE OR REPLACE FUNCTION xy() RETURNS SETOF record AS $$
SELECT relname::text, relpages::int4
On Mon, 2006-08-21 at 07:31 +0200, Hans-Juergen Schoenig wrote:
CREATE OR REPLACE FUNCTION xy() RETURNS SETOF record AS $$
SELECT relname::text, relpages::int4
FROM pg_class;
$$ LANGUAGE SQL IMMUTABLE;
As far as i remember inlined SQL code has been implemented into the
40 matches
Mail list logo