Hi,
Is there any reason why the grolist field in the table pg_group is
implemented as an array and not as a separate table?
According to the documentation:
quote source=Postgresql 7.2 User Manual, chapter 6 near the end
Arrays are not sets; using arrays in the manner described in the previous
Reinoud van Leeuwen [EMAIL PROTECTED] writes:
Is there any reason why the grolist field in the table pg_group is
implemented as an array and not as a separate table?
It's easier to cache a single entry per group in the GRONAME and GROSYSID
syscaches than a bunch of them. The design is
Hi!
I'm new on this list, my name is David Pradier, and i'm french.
I'm currently trying the new postgresql 7.3rc1, and i've noticed that if
i compared an integer to an empty string, i ran in an error.
Example :
=# select nom_comm from operation where id_operation = '';
ERROR: pg_atoi:
Louis-David Mitterrand [EMAIL PROTECTED] writes:
with 7.2:
template1=# select 1 = '';
?column?
--
f
(1 row)
with 7.3rc1:
template1=# select 1 = '';
ERROR: pg_atoi: zero-length string
Is this change of behavior intentional?
Are those two syntaxes eqivalent ?
select * from users where monitored;
select * from users where monitored=true;
If the answer is yes, the optimimer probably doesn't agree with you :)
Tested on RC1:
template1=# create table a (a boolean, b text);
CREATE TABLE
inserted ~18000 rows with
Louis-David Mitterrand [EMAIL PROTECTED] writes:
The point David was trying to make is:
with 7.2:
template1=# select 1 = '';
?column?
--
f
(1 row)
with 7.3rc1:
template1=# select 1 = '';
ERROR: pg_atoi: zero-length string
Is this
Hi Neil,
However, the FreeBSD box I'm playing with isn't mine, so I'm not too
keen to change sysctls (well, that and I don't have root :-) ). Would
a kind BSD user confirm that:
(a) the sysctls above *can* be used to change kernel shared
memory settings, and the default
Using the famous WAG tech, in your first query the optimizer has to
evaluate monitored for each record to determine its value.
Robert Treat
On Thu, 2002-11-21 at 13:39, Daniele Orlandi wrote:
Are those two syntaxes eqivalent ?
select * from users where monitored;
select * from users where
On Thu, 21 Nov 2002, Daniele Orlandi wrote:
Are those two syntaxes eqivalent ?
select * from users where monitored;
select * from users where monitored=true;
If the answer is yes, the optimimer probably doesn't agree with you :)
That depends on the definition of equivalent. They
Are those two syntaxes eqivalent ?
select * from users where monitored;
select * from users where monitored=true;
If the answer is yes, the optimimer probably doesn't agree with you :)
That depends on the definition of equivalent. They presumably give the
same answer (I'm assuming
On Thu, 21 Nov 2002, Christopher Kings-Lynne wrote:
Are those two syntaxes eqivalent ?
select * from users where monitored;
select * from users where monitored=true;
If the answer is yes, the optimimer probably doesn't agree with you :)
That depends on the definition of
I think his point is that they _should_ be equivalent. Surely there's
something in the optimiser that discards '=true' stuff, like 'a=a'
should be
discarded?
I figure that's what he meant, but it isn't what was said. ;)
col isn't of the general form indexkey op constant or constant op
On Thu, 21 Nov 2002, Christopher Kings-Lynne wrote:
I think his point is that they _should_ be equivalent. Surely there's
something in the optimiser that discards '=true' stuff, like 'a=a'
should be
discarded?
I figure that's what he meant, but it isn't what was said. ;)
col
On Thu, 21 Nov 2002, Christopher Kings-Lynne wrote:
I think his point is that they _should_ be equivalent. Surely there's
something in the optimiser that discards '=true' stuff, like 'a=a'
should be
discarded?
I figure that's what he meant, but it isn't what was said. ;)
col
Not that I see the point of indexing booleans, but hey :)
If one of the values is much more infrequent than the other, you can
probably get a substantial win using a partial index, can't you?
Yes, I thought of the partial index after I wrote that email :)
Chris
col isn't of the general form indexkey op constant or constant op
indexkey which I presume it's looking for given the comments in
indxpath.c. I'm not sure what the best way to make it work would be
given
that presumably we'd want to make col IS TRUE/FALSE use an index at
the
same
On Thu, 21 Nov 2002, Christopher Kings-Lynne wrote:
col isn't of the general form indexkey op constant or constant op
indexkey which I presume it's looking for given the comments in
indxpath.c. I'm not sure what the best way to make it work would be
given
that presumably we'd
Stephan Szabo wrote:
On Thu, 21 Nov 2002, Daniele Orlandi wrote:
Are those two syntaxes eqivalent ?
select * from users where monitored;
select * from users where monitored=true;
If the answer is yes, the optimimer probably doesn't agree with you :)
That depends on the definition of
Do this:
create database adsf asdf;
Then to a pg_dumpall and you get this:
\connect adsf asdf
pg_dump: too many command line options (first is 'asdf')
Try 'pg_dump --help' for more information.
pg_dumpall: pg_dump failed on adsf asdf, exiting
LOG: pq_recvbuf: unexpected EOF on client
Daniele Orlandi [EMAIL PROTECTED] writes:
The problem is the opposite... so, effectively, seems that the optimizer
considers monitored and monitored=true as two different expressions...
Check.
The viceversa is analog and we also can see that the syntax monitored
is true is considered
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Do this:
create database adsf asdf;
Then to a pg_dumpall and you get this:
\connect adsf asdf
pg_dump: too many command line options (first is 'asdf')
Good catch --- fixed.
regards, tom lane
Neil Conway wrote:
(c) the 'prevent shared memory paging' sysctl vaguely referred
to in the docs is 'kern.ipc.shm_use_phys', right?
I have added a mention of this to the 7.4 docs:
You might also want to use the applicationsysctl/ setting to
lock shared
Oliver Elphick wrote:
I deleted the first table. The sequence was deleted too, leaving the
default of the second table referring to a non-existent sequence.
Could this be a TODO item in 7.4, to add a dependency check when a
sequence is set as the default without being created at the same
Tom Lane wrote:
I have trouble implementing a way to easily check whether a user is part
of a group.
Perhaps you could create a table that has no purpose except to be a
permissions-check target, and set it up to have permissions granted only
to the group you care about. Then use
I am going to work on nested transactions for 7.4.
My goal is to first implement nested transactions:
BEGIN;
SELECT ...
BEGIN;
UPDATE;
COMMIT;
DELETE;
COMMIT;
and later savepoints (Oracle):
BEGIN;
SELECT ...
Does anyone want userid to be an OID? Peter? Anyone?
If not, I will add it to the TODO list or work on the patch myself.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd recommend not
Bruce Momjian [EMAIL PROTECTED] writes:
I am going to work on nested transactions for 7.4.
[some details]
This is, of course, barely scratching the surface of what will need to
be done.
I assume you've abandoned the notion of a fast release cycle for 7.4?
'Cause if you start on this, we ain't
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am going to work on nested transactions for 7.4.
[some details]
This is, of course, barely scratching the surface of what will need to
be done.
I assume you've abandoned the notion of a fast release cycle for 7.4?
'Cause if you
Of course, those would be SQL purists who _don't_ understand
concurrency issues. ;-)
---
Thomas O'Connell wrote:
It seems worth pointing out, too, that some SQL purists propose not
relying on product-specific methods of
On Thu, 2002-11-21 at 14:11, Bruce Momjian wrote:
Of course, those would be SQL purists who _don't_ understand
concurrency issues. ;-)
Or they're the kind that locks the entire table for any given insert.
--
Rod Taylor [EMAIL PROTECTED]
---(end of
Thomas O'Connell [EMAIL PROTECTED] writes:
It seems worth pointing out, too, that some SQL purists propose not
relying on product-specific methods of auto-incrementing.
I.e., it is possible to do something like:
insert into foo( col, ... )
values( coalesce( ( select max( col ) from foo ), 0
On 21 Nov 2002, Rod Taylor wrote:
On Thu, 2002-11-21 at 15:09, scott.marlowe wrote:
On 21 Nov 2002, Rod Taylor wrote:
On Thu, 2002-11-21 at 14:11, Bruce Momjian wrote:
Of course, those would be SQL purists who _don't_ understand
concurrency issues. ;-)
Or they're the kind
On 21 Nov 2002, Rod Taylor wrote:
On Thu, 2002-11-21 at 14:11, Bruce Momjian wrote:
Of course, those would be SQL purists who _don't_ understand
concurrency issues. ;-)
Or they're the kind that locks the entire table for any given insert.
Isn't that what Bruce just said? ;^)
On Thu, 2002-11-21 at 15:09, scott.marlowe wrote:
On 21 Nov 2002, Rod Taylor wrote:
On Thu, 2002-11-21 at 14:11, Bruce Momjian wrote:
Of course, those would be SQL purists who _don't_ understand
concurrency issues. ;-)
Or they're the kind that locks the entire table for any given
34 matches
Mail list logo
