On Fri, Aug 17, 2001 at 02:41:47PM -0400, Neal Lindsay wrote:
> I think that the subject line explains what I am trying to do. How can I
> create a stored function (in SQL, if that matters) that a user can call to
> update data in a table to which they normally only have read access?
By using
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> The web site lists a lot of the limitations for postgresql, but not the
>> max number of tables that are allowed in a given db. Anyone care to come
>> up with a number?
> It is limited by your filesystem's ability to handle large directories.
> I h
Suppose we have table A and table B. When action is performed on table A
(for example INSERT), some action (for example UPDATE) through the trigger
is done on table B.
If user had permission on both tables (GRANT INSERT on table A and GRANT
UPDATE on table B)- everything is good. But in that way
Title: RE: Roll Back dont roll back counters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yes, of course. But you have to have pretty stringent performance
requirements to justify changing to technical IDs as a matter of
rule. Reading an ER model is pretty important too, from a
maintenanc
Roman Havrylyak wrote:
>
> Suppose we have table with indexes, attached triggers, and finnaly alot of
> records (more then 100,000). Records are adding continuously.
>
> Once a month you have to do archiving of records. Simple INSERT INTO ARCHIV
> followed by DELETE and then VACUUM take alot of
On Thu, Aug 16, 2001 at 03:28:47PM -0700,
Andrew Gould <[EMAIL PROTECTED]> wrote:
> Hh. I see what you mean. Perhaps an office
> policy regarding password protected screen savers or
> screen locks would meet the regulation's intent. (It
> would also be simple and cheap.)
This is a much b
On Fri, Aug 17, 2001 at 11:37:33AM +0100,
"Michael Ansley (UK)" <[EMAIL PROTECTED]> wrote:
>
> Um, no, primary keys should not always be opaque. Technical primary
> keys should always be opaque. Relational modelling has been built to
I think it has more to do with efficiency and whether or n
On Fri, Aug 17, 2001 at 02:29:47PM +0200, Roman Havrylyak wrote:
> Suppose we have table with indexes, attached triggers, and finnaly alot of
> records (more then 100,000). Records are adding continuously.
>
> Once a month you have to do archiving of records. Simple INSERT INTO ARCHIV
> followed
Suppose we have table with indexes, attached triggers, and finnaly alot of
records (more then 100,000). Records are adding continuously.
Once a month you have to do archiving of records. Simple INSERT INTO ARCHIV
followed by DELETE and then VACUUM take alot of time, offen even hang up
sessions. D
Suppose we have table A and table B. When action is performed on table A
(for example INSERT), some action (for example UPDATE) through the trigger
is done on table B.
If user had GRANT permission on both tables - everything is good. But in
that way user can get access to table B directly.
If I
Martijn van Oosterhout wrote:
> On Fri, Aug 17, 2001 at 01:40:32PM +0200, Feite Brekeveld wrote:
> > > Well, an index speeds it up, but that times 80,000 will still take a while.
> > > Is there any trickery or will this work?
> > >
> > > update accounting set status = 'C';
> > >
> > > If so, that
Title: RE: [GENERAL] Roll Back dont roll back counters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Um, no, primary keys should not always be opaque. Technical primary
keys should always be opaque. Relational modelling has been built to
exploit primary keys actually being the business key
On Fri, Aug 17, 2001 at 01:40:32PM +0200, Feite Brekeveld wrote:
> > Well, an index speeds it up, but that times 80,000 will still take a while.
> > Is there any trickery or will this work?
> >
> > update accounting set status = 'C';
> >
> > If so, that will be much faster.
>
> No that will not w
Martijn van Oosterhout wrote:
> On Fri, Aug 17, 2001 at 01:08:29PM +0200, Feite Brekeveld wrote:
> > Now this table has about 80,000 records. I need to update 74,000 status
> > fields. So I made a dump, and hacked the dump into SQL statements like:
> >
> > update accounting set status = 'C' where
On Fri, Aug 17, 2001 at 01:08:29PM +0200, Feite Brekeveld wrote:
> Now this table has about 80,000 records. I need to update 74,000 status
> fields. So I made a dump, and hacked the dump into SQL statements like:
>
> update accounting set status = 'C' where seqno = 1566385;
>
> and the other
Hi,
I have a table with no relations to other tables. It has a sequence
number field (integer) and a status field being a char.
There is a unique index on the seqno field.
Now this table has about 80,000 records. I need to update 74,000 status
fields. So I made a dump, and hacked the dump into
On Fri, Aug 17, 2001 at 03:29:36AM -0400, Morgan Curley wrote:
> Hey everyone,
> On average, are multiple simple queries better performance-wise than joins?
> i.e.
> select A.col1 from table1 A
> select B.col2 from table2 B where B.col1 = A.col1
> etc
>
> vs
>
> select A.col1, B.col2 from table1
Hey everyone,
On average, are multiple simple queries better performance-wise than joins?
i.e.
select A.col1 from table1 A
select B.col2 from table2 B where B.col1 = A.col1
etc
vs
select A.col1, B.col2 from table1 A, table2 B where B.col1 = A.col1
Are joins better for small/large numbers of tab
18 matches
Mail list logo
