omar [EMAIL PROTECTED] writes:
I'm curious what people think about the following statement considering the
database typing talk being brought up here. My experience is that more times
than not I have to put data validation in my client code even when it's
available on the server, if for no
I defined a function, count_nonnull, to return 1 if not null, 0 otherwise.
Then I defined a corresponding unary operator ~~. I wanted it for
expressions like ~~ item_1 + ~~ item_2. But because precedence of
user-defined ops is pretty low, I had to rewrite this as ~~(item_1) +
~~(item_2), which
At 1:01 AM -0500 3/10/07, Tom Lane wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
I assume I'll have to do a 64 bit build to use more than a few gig of
shared buffers. If I do that, though, am I going to have to do a
database dump and reload,
Yes, most likely, because you'll have changed
Tom Lane wrote:
Kenneth Downs [EMAIL PROTECTED] writes:
The biggest security limitation we have is actually a weakness in
Postgres - the inability to restrict the abilities of a user with
CREATUSER rights, they can make somebody who can do anything. For
higher security this requires no
On 3/10/07, Don Lavelle [EMAIL PROTECTED] wrote:
Hi, all,
Thank you all for your help! From what I've gathered, similarly
sized projects run on 100 MB of disk space and a 450 MHz processor.
My GUI and application logic aren't going to need much more than
that, so I should be good to go!
On Fri, 9 Mar 2007, lneves wrote:
I hope that someone has cracked this one because I have run into a brick
wall the entire week and after 3 all-nighters with bad installations, I
would appreciate hearing from others!
You could checkout Adempiere wich is a fork of Compiere:
woger151 [EMAIL PROTECTED] writes:
Why wouldn't ~~(item_1) + ~~(item_2) be parsed as (~~(item_1)) +
(~~(item_2))?
Because it's parsed as
~~ ( (item_1) + ( ~~ (item_2) ) )
+ binds more tightly than any non-built-in operator, per the
precedence chart in the manual:
Kenneth Downs [EMAIL PROTECTED] writes:
Perhaps a lesser form of CREATEROLE, CREATEROLE_LIMITED, who can create
roles and only grant to the roles he himself is a member of.
You can make that out of spare parts today, by granting non-superusers
execute rights on functions that create users.
Awesome! That never occurred to me. This is really cool.
Tom Lane wrote:
Kenneth Downs [EMAIL PROTECTED] writes:
Perhaps a lesser form of CREATEROLE, CREATEROLE_LIMITED, who can create
roles and only grant to the roles he himself is a member of.
You can make that out of spare parts
Hi list!
Consider the following table definition:
Column | Type | Modifiers
+--+---
id | integer | not null
date | date |
value | double precision |
The id and date field together are some sort of
On Sat, Mar 10, 2007 at 08:30:20AM -0500, Dan Sugalski wrote:
Possibly it won't. The machine the DB is on sees heavy access to
large files, to the point where parts of the database may get flushed
out of the OS buffer cache. I was working on the (possibly deeply
flawed assumption) that I'd
That's basically what I've done with my past questions on the ROLE system in
place. Since roles are global, I wanted it fine grained to the DB level so I
had to append DB_ in front of each role name and by using current_database()
inside my functions, I could hide that from the exterior.
Now I
Hello,
How can I return the contents of the row object without knowing the names of
the parameters in it ? I'd like to do something like row[1] or something
similar. Or is there a way to actually get the values knowing the return
type but not the name?
FOR row IN SELECT * FROM getgroups(usr)
Hello,
For some reason, my first attempt to send this email to the list didn't get
through
We have several independent database servers with ~50GB+ databases running
postgres 8.0.x. We are planning to upgrade these databases to postgres
8.2.xover the weekend
We plan to use the following
David Legault escribió:
That's basically what I've done with my past questions on the ROLE system in
place. Since roles are global, I wanted it fine grained to the DB level so I
had to append DB_ in front of each role name and by using current_database()
inside my functions, I could hide that
Alvaro Herrera wrote:
David Legault escribió:
That's basically what I've done with my past questions on the ROLE system in
place. Since roles are global, I wanted it fine grained to the DB level so I
had to append DB_ in front of each role name and by using current_database()
inside my
Christian Schröder wrote:
How can I enforce these constraints?
I submit that you should rethink your database schema and properly
normalize it. You are attempting to retool the algebra that underlies
the SQL functionalities into doing something they are not designed to
do, and you will, even
At 7:47 PM +0100 3/10/07, Martijn van Oosterhout wrote:
On Sat, Mar 10, 2007 at 08:30:20AM -0500, Dan Sugalski wrote:
Possibly it won't. The machine the DB is on sees heavy access to
large files, to the point where parts of the database may get flushed
out of the OS buffer cache. I was
On 3/10/07, Kenneth Downs [EMAIL PROTECTED] wrote:
Alvaro Herrera wrote:
David Legault escribió:
That's basically what I've done with my past questions on the ROLE system in
place. Since roles are global, I wanted it fine grained to the DB level so I
had to append DB_ in front of each role
On Fri, Mar 09, 2007 at 10:29:46AM -0800, D Unit wrote:
I can't get the .pgpass file working. I think the problem may have to do with
the fact that the user's home directory is '/'. Is there a way to specify a
different location for .pgpass other than '~/.pgpass'?
Set the PGPASSFILE
Peter Eisentraut wrote:
I submit that you should rethink your database schema and properly
normalize it. You are attempting to retool the algebra that underlies
I don't quite understand why this is a question of normalization. As far
as I can see, my table seems to be normalized as far as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/07 18:22, Christian Schröder wrote:
Peter Eisentraut wrote:
[snip]
I know that it's always dangerous to quote the Wikipedia. Let me do it
anyway: Attributes in tables in SQL database management systems can
optionally be designated as
Christian Schröder wrote:
Peter Eisentraut wrote:
A first step in that direction would be to rethink the apparently
troublesome use of null values.
Some of the limits are
only valid after a given date, whereas other limits are valid all the
time. How would you put this
Suppose I have a view:
create view v1 as select * from t1;
and another view as:
create view v2 as select * from v1;
Now is there any query or any catalog table available by which I can get to
know the dependency (names of views on which v2 depends) for view v2?
I did check the pg_views but
Shoaib Mir [EMAIL PROTECTED] writes:
Now is there any query or any catalog table available by which I can get to
know the dependency (names of views on which v2 depends) for view v2?
If you get up-close-n-personal with pg_depend you can determine that.
regards, tom lane
Shoaib Mir escribió:
Suppose I have a view:
create view v1 as select * from t1;
and another view as:
create view v2 as select * from v1;
Now is there any query or any catalog table available by which I can get to
know the dependency (names of views on which v2 depends) for view v2?
I can see the following in pg_depend:
For view v1:
classid | objid | objsubid | refclassid | refobjid | refobjsubid | deptype
-++--++--+-+-
2618 | 153523 |0 | 1259 | 153521 | 0 | n
2618 | 153523 |
27 matches
Mail list logo
