You can try this too:...WHERE
EXTRACT(YEAR FROM dxdate::Date) > 2000
Mauricio Fernández A.Ingeniero de
SistemasUniversidad Autónoma de Manizales (Colombia)
-Mensaje
original-De: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]]En
nombre de Bungsuputra LinanEnviado el: lunes, 27 febrero, 2
Your
table has a primary key yet, so you can´t add a second primary key. You
only can define one pk, however it can be composed as your table has (it now has
2 columns), so I think you need to drop the current pk and add again the new pk
with your 3 columns (probeid, tissueid, expid).
Rev
* Alvaro Herrera:
>> > Florian Weimer <[EMAIL PROTECTED]> writes:
>> >> Is it possible to create an index to support queries of the form
>> >> "column LIKE '%suffix'" (similar to an ordinary index for LIKE
>> >> 'prefix%', which I also need)?
>
> It is possible to create a functional index on the
am 01.03.2006, um 8:19:40 +0100 mailte Florian Weimer folgendes:
> * Alvaro Herrera:
>
> >> > Florian Weimer <[EMAIL PROTECTED]> writes:
> >> >> Is it possible to create an index to support queries of the form
> >> >> "column LIKE '%suffix'" (similar to an ordinary index for LIKE
> >> >> 'prefix
Hi all,
I have a situation where a DELETE operation may (correctly) fail due to a
RESTRICT FK constraint. If so, I need to set a flag in the row indicating
that it has been marked for deletion so that I can disregarded in subsequent
queries.
I'm trying to achieve this with a BEFORE DELETE trigger
AKHILESH GUPTA wrote:
> here i have to grant permissions to that user individually for each and
> every table by using:
> :->> grant ALL ON to ;
> GRANT
> and all the permissions are granted to that user for that particular table.
Yes. If you are annoyed by having to type too many commands, you
Hello Achilleus
Thanks for your feedback. On changing the return to NULL:
According to the docs, if I return NULL in the BEFORE trigger itself, all
subsequent triggers and the row-level op itself (the actual delete) will be
skipped completely, which is no good. I will confirm this to make sure
tho
On Wed, 1 Mar 2006, Simon Kinsella wrote:
> Hi all,
>
> I have a situation where a DELETE operation may (correctly) fail due to a
> RESTRICT FK constraint. If so, I need to set a flag in the row indicating
> that it has been marked for deletion so that I can disregarded in subsequent
> queries.
>
thank you very much sir for your valuable suggestion,but i am talking about direct database query...!On 3/1/06, Alvaro Herrera <
[EMAIL PROTECTED]> wrote:AKHILESH GUPTA wrote:> here i have to grant permissions to that user individually for each and
> every table by using:> :->> grant ALL ON
Yes I originally started working on a function based approach like you
suggest, but realised it wouldn't cover the situation where the delete
operation is fired as a result of a CASCADE ON DELETE constraint from a
parent table, rather than as a manual query. I suppose I could ditch that
particular
AKHILESH GUPTA wrote:
> thank you very much sir for your valuable suggestion,
> but i am talking about direct database query...!
There is none that can help you here, short of making a function in
PL/pgSQL or other language ...
> On 3/1/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >
>
On Tue, Feb 28, 2006 at 09:43:58 -0700,
Michael James <[EMAIL PROTECTED]> wrote:
> GRANT ALL PRIVILEGES ON databaseName To username;
This won't do what he wants. This will not grant access to objects contained
in the database, only a few specific privileges.
There is no single command that does
I'm interested in creating a mirror database, for use in case one our
primary machine goes down. Can people here help sort out which of the
several replication projects is most viable?
As far as I can tell, the winner is slony1 at
http://gborg.postgresql.org/project/slony1/projdisplay.php , but t
On Wed, Mar 01, 2006 at 01:30:23PM -, Simon Kinsella wrote:
> I'm trying to achieve this with a BEFORE DELETE trigger, which would set the
> 'marked_for_deletion' field to TRUE before attempting the delete proper.
> Then if the DELETE fails the row would still be tagged and I'd be happy.
> Prob
On Wed, Mar 01, 2006 at 09:51:46AM -0800, Bryce Nesbitt wrote:
> switch over and rebuild the DB. "No-lost transaction" is far more
> important than switch time.
You can't guarantee that without two phase commit, no matter what you
do. Log shipping doesn't require you to have an active database
r
I want to get Pg (v7.4.7) to output a date field in a different format
than -mm-dd through the use of an environmental variable (because I
have no access the SQL). Is this possible? I know about the DATESTYLE
variable, but that seems to work only within a query transaction, and
has no eff
On Wed, Mar 01, 2006 at 12:32:26PM -0500, Mark Fenbers wrote:
> have no access the SQL). Is this possible? I know about the DATESTYLE
> variable, but that seems to work only within a query transaction, and
> has no effect if trying to set it as an envvar.
No, it won't work as an environment va
I found PGDATESTYLE that solves my problem, but ever since, I've been
looking for a comprehensive list of environmental variables that Pg
recognizes, but haven't been able to find such a list in any of the
books I looked in or the man pages. Anyone know where I can find such a
list?
Mark
Mar
On Wed, Mar 01, 2006 at 02:20:57PM -0500, Mark Fenbers wrote:
> I found PGDATESTYLE that solves my problem, but ever since, I've been
> looking for a comprehensive list of environmental variables that Pg
> recognizes, but haven't been able to find such a list in any of the
> books I looked in or
Andrew Sullivan wrote:
> On Wed, Mar 01, 2006 at 09:51:46AM -0800, Bryce Nesbitt wrote:
>
>> switch over and rebuild the DB. "No-lost transaction" is far more
>> important than switch time.
>>
>
> You can't guarantee that without two phase commit, no matter what you
> do. Log shipping doe
On Wed, Mar 01, 2006 at 02:20:57PM -0500, Mark Fenbers wrote:
> I found PGDATESTYLE that solves my problem, but ever since, I've been
> looking for a comprehensive list of environmental variables that Pg
> recognizes, but haven't been able to find such a list in any of the
> books I looked in or
On Wed, Mar 01, 2006 at 11:28:06AM -0800, Bryce Nesbitt wrote:
> Actually let me loosen that a bit: we don't need two phase commit. We
> can loose the most recent transaction, or even the last few seconds of
> transactions. What we can't survive is -- on the day of the emergency
> -- a long and
On Wed, 2006-03-01 at 11:51, Bryce Nesbitt wrote:
> I'm interested in creating a mirror database, for use in case one our
> primary machine goes down. Can people here help sort out which of the
> several replication projects is most viable?
>
> As far as I can tell, the winner is slony1 at
> http
Stephan Szabo wrote:
> > justify_days doesn't currently do anything with this result --- it
> > thinks its charter is only to reduce day components that are >= 30 days.
> > However, I think a good case could be made that it should normalize
> > negative days too; that is, the invariant on its resul
On Wed, 2006-03-01 at 14:18, Bruce Momjian wrote:
> Stephan Szabo wrote:
> > > justify_days doesn't currently do anything with this result --- it
> > > thinks its charter is only to reduce day components that are >= 30 days.
> > > However, I think a good case could be made that it should normalize
Scott Marlowe wrote:
> On Wed, 2006-03-01 at 14:18, Bruce Momjian wrote:
> > Stephan Szabo wrote:
> > > > justify_days doesn't currently do anything with this result --- it
> > > > thinks its charter is only to reduce day components that are >= 30 days.
> > > > However, I think a good case could be
On Wed, 1 Mar 2006, Hannu Krosing wrote:
> Ühel kenal päeval, K, 2006-03-01 kell 15:18, kirjutas Bruce Momjian:
> > Stephan Szabo wrote:
> > > > justify_days doesn't currently do anything with this result --- it
> > > > thinks its charter is only to reduce day components that are >= 30 days.
> > >
Hannu Krosing wrote:
> ?hel kenal p?eval, K, 2006-03-01 kell 15:18, kirjutas Bruce Momjian:
> > Stephan Szabo wrote:
> > > > justify_days doesn't currently do anything with this result --- it
> > > > thinks its charter is only to reduce day components that are >= 30 days.
> > > > However, I think a
Hannu Krosing <[EMAIL PROTECTED]> writes:
> But unfortunately '2 mons -1 days' <> '1 mons 29 days'
> If I want something to happen 1 day less than two months from dome date,
> then the only way to say that consistently *is* '2 mons -1 days'.
Sure, but if you want to represent that then you don't p
Ok thanks, will check this out. Is that the same as savepoints, or something
different? (am using 8.1.2)
At the moment I'm investigating using a rule (rewrite the DELETE as an
UPDATE to set the flag, then use an AFTER UPDATE trigger to attempt to
delete the row if the flag was set). Not sure if it
On Wed, 2006-03-01 at 14:27, Bruce Momjian wrote:
> Scott Marlowe wrote:
> > On Wed, 2006-03-01 at 14:18, Bruce Momjian wrote:
> > > Stephan Szabo wrote:
> > > > > justify_days doesn't currently do anything with this result --- it
> > > > > thinks its charter is only to reduce day components that a
Though, it is pretty easy to do something like:
select 'GRANT ALL ON ' || table_name || ' TO public;' from
information_schema.tables where table_schema='blah';
You can feed the output of that to psql, ei:
psql -qc "select 'GRANT ALL ON ' || table_name || ' TO public;' from
information_schema.tab
You could also use WAL shipping and some PITR trickery to keep a 'warm
standby' database up to date. How far behind it falls is up to you,
since you'll be periodically syncing the current WAL file to the backup
machine. Do the sync once a minute, and at most you lose 60 seconds of
data.
On Wed, Ma
Probably the easiest way is to switch to using table partitioning and
switch to using start_timestamp and end_timestamp, so that when you
modify a row you update the old one setting end_timestamp to now() and
insert the new row (all within one transaction).
There are other ways to do it, but they'
On Wed, Mar 01, 2006 at 04:15:18PM -0600, Jim C. Nasby wrote:
> You could also use WAL shipping and some PITR trickery to keep a 'warm
> standby' database up to date. How far behind it falls is up to you,
> since you'll be periodically syncing the current WAL file to the backup
> machine. Do the sy
On Wednesday 01 March 2006 23:19, Jim C. Nasby wrote:
> Probably the easiest way is to switch to using table partitioning and
> switch to using start_timestamp and end_timestamp, so that when you
> modify a row you update the old one setting end_timestamp to now() and
> insert the new row (all with
Michael Fuhr <[EMAIL PROTECTED]> writes:
> The libpq documentation has a list of environment variables, although
> it's not complete:
> http://www.postgresql.org/docs/8.1/interactive/libpq-envars.html
Er, what's not complete about it? Feel free to send a doc patch ...
reg
On Thu, Mar 02, 2006 at 01:16:47AM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > The libpq documentation has a list of environment variables, although
> > it's not complete:
> > http://www.postgresql.org/docs/8.1/interactive/libpq-envars.html
>
> Er, what's not complete abo
On Thu, Mar 02, 2006 at 12:33:31AM -0700, Michael Fuhr wrote:
> On Thu, Mar 02, 2006 at 01:16:47AM -0500, Tom Lane wrote:
> > Michael Fuhr <[EMAIL PROTECTED]> writes:
> > > The libpq documentation has a list of environment variables, although
> > > it's not complete:
> > > http://www.postgresql.org
39 matches
Mail list logo
