"David Johnston" writes:
> The expression:
> (some_composite).calculated_field
> resolves to the function call:
> calculated_field(some_composite)
> I know I've seen it before, though whether in the docs or in e-mail I am
> unsure, but for the life of me browsing for it for about 10 minutes got m
On Mon, Aug 27, 2012 at 3:46 PM, David Johnston wrote:
> With Chris Travers recently going O-R gung-ho on us I decided I wanted to
> find out where in the documentation the following behavior is specified:
>
> The expression:
>
> (some_composite).calculated_field
>
> resolves to the function call:
With Chris Travers recently going O-R gung-ho on us I decided I wanted to
find out where in the documentation the following behavior is specified:
The expression:
(some_composite).calculated_field
resolves to the function call:
calculated_field(some_composite)
I know I've seen i
Bruce Momjian writes:
> On Wed, Jan 25, 2012 at 11:30:49AM -0500, Tom Lane wrote:
>> hubert depesz lubaczewski writes:
> anyway - the point is that in \df date_part(, timestamp) says it's
> immutable, while it is not.
>>
>> Hmm, you're right. I thought we'd fixed that way back when, but
>> obvi
2012/8/27 Stephen Crawford :
> I see that works for 9, but I'm still in 8.4. But another person just sent
> me a bit of code to do it:
>
just don't use "format" function
execure 'grant select on ' || tn || 'to ';
>
> do $$
> declare tn text;
> begin
> for tn in select c.oid::regclass::text
I see that works for 9, but I'm still in 8.4. But another person just
sent me a bit of code to do it:
do $$
declare tn text;
begin
for tn in select c.oid::regclass::text
from pg_class c join pg_namespace n on n.oid = c.relnamespace
where n.nspname not in ('pg_catalog',
*GRANT *{ { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES |
TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] table_name [, ...]
| *ALL TABLES IN SCHEMA schema_name *[, ...] }
TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
See more on http
Is there a simple way to grant SELECT privileges to a user for all the
tables in a database, without having to do it for each table?
Thanks,
Steve
--
Stephen Crawford
Center for Environmental Informatics
The Pennsylvania State University
--
Sent via pgsql-general mailing list (pgsql-general
I thought that this was going to be tricky.
Perhaps I could use rules to populate a shadow table that is like a INNER JOIN
of the two tables. This would consolidate the Boolean on the separate table
into the same table that holds the time ranges. In version 8.4 I would still
need to use explic
Am 27.08.2012 um 16:18 schrieb Tom Lane :
> Maximilian Tyrtania writes:
>
>> Sorry, should have mentioned that…Dropping and recreating it fixed it.
>
> Hm, had you changed the behavior of that function since creating the
> index?
To be honest - I don't know for sure. I might well have.
Maximi
On Wed, Jan 25, 2012 at 11:30:49AM -0500, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > anyway - the point is that in \df date_part(, timestamp) says it's
> > immutable, while it is not.
>
> Hmm, you're right. I thought we'd fixed that way back when, but
> obviously not. Or maybe the
On 08/27/2012 05:17 AM, Viacheslav N Tararin wrote:
Good day.
I have got next log file after restart a standby server. The master
server all of the time was up and properly works.
It the message "unexpected pageaddr" and non exists log files indicates
about standby databases corrupted.
LOG: dat
Maximilian Tyrtania writes:
>> It might be a broken index issue. Please show the EXPLAIN for these queries.
> It was. I had an index like this:
> CREATE INDEX idx_firmen_iskunde_index
> ON firmen
> USING btree
> (f_firmen_iskunde(firmen.*));
> Sorry, should have mentioned thatÂ…Dropping and r
Good day.
I have got next log file after restart a standby server. The master
server all of the time was up and properly works.
It the message "unexpected pageaddr" and non exists log files indicates
about standby databases corrupted.
LOG: database system was interrupted while in recovery at
> On Mon, Aug 27, 2012 at 12:55 PM, Maximilian Tyrtania
> wrote:
>> What might be up there?
>
> It might be a broken index issue. Please show the EXPLAIN for these queries.
It was. I had an index like this:
CREATE INDEX idx_firmen_iskunde_index
ON firmen
USING btree
(f_firmen_iskunde(firm
On 08/27/2012 12:47 PM, Sergey Konoplev wrote:
On Mon, Aug 27, 2012 at 2:37 PM, Georges Racinet wrote:
I guess one must also reindex in case some record changes as well, right ?
Through a trigger maybe ?
You do not need to reindex it in case of record changes. The index
values will be recalcu
On Mon, Aug 27, 2012 at 2:37 PM, Georges Racinet wrote:
> I guess one must also reindex in case some record changes as well, right ?
> Through a trigger maybe ?
You do not need to reindex it in case of record changes. The index
values will be recalculated automatically after committing the
change
On 08/27/2012 12:14 PM, Sergey Konoplev wrote:
On Mon, Aug 27, 2012 at 1:56 PM, Maximilian Tyrtania
wrote:
It might be a broken index issue. Please show the EXPLAIN for these queries.
It was. I had an index like this:
CREATE INDEX idx_firmen_iskunde_index
ON firmen
USING btree
(f_firm
On Mon, Aug 27, 2012 at 1:56 PM, Maximilian Tyrtania
wrote:
>> It might be a broken index issue. Please show the EXPLAIN for these queries.
>
> It was. I had an index like this:
>
> CREATE INDEX idx_firmen_iskunde_index
> ON firmen
> USING btree
> (f_firmen_iskunde(firmen.*));
>
> Dropping and
> On Mon, Aug 27, 2012 at 12:55 PM, Maximilian Tyrtania
> wrote:
>> What might be up there?
>
> It might be a broken index issue. Please show the EXPLAIN for these queries.
It was. I had an index like this:
CREATE INDEX idx_firmen_iskunde_index
ON firmen
USING btree
(f_firmen_iskunde(firmen.
On Mon, Aug 27, 2012 at 12:55 PM, Maximilian Tyrtania
wrote:
> What might be up there?
It might be a broken index issue. Please show the EXPLAIN for these queries.
>
> Maximilian Tyrtania
> http://www.contactking.de
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
On Mon, 27 Aug 2012 10:55:43 +0200
Maximilian Tyrtania wrote:
> Hello from Berlin,
>
> I can't quite make sense of this (running PG 9.0.3):
>
> psql (9.0.3)
> Type "help" for help.
>
> FAKDB=# Select _rowid,f_firmen_isKunde(firmen),bezeichnung::text from
> firmen
> where
> (firmen.bezeichnung=
Prashant --
I haven't tried this -- we don't use DBI currently -- but wouldn't it get
treated as any other connection if you point the DBI connection to the
pgbouncer host / port / database ? pgbouncer should redirect the query
according the rules in its .ini file.
HTH,
Greg Williamson
>_
Hello from Berlin,
I can't quite make sense of this (running PG 9.0.3):
psql (9.0.3)
Type "help" for help.
FAKDB=# Select _rowid,f_firmen_isKunde(firmen),bezeichnung::text from firmen
where
(firmen.bezeichnung='Microsoft Deutsc
24 matches
Mail list logo
