Correction, as Mr. Tober suggested.
On Thu, Aug 6, 2015 at 8:34 PM, Melvin Davidson
wrote:
> As Mr. Wilson suggested, you can use pg_dump to extract the views, but I
> also suggest downloading and installing pg_extractor, which uses pg_dump
> but allows more options to dump just the objects you
As Mr. Wilson suggested, you can use pg_dump to extract the views, but I
also suggest downloading and installing pg_extractor, which uses pg_dump
but allows more options to dump just the objects you need. IE: views,
functions, etc.
Here's the url to download.
https://github.com/omniti-labs/pg_extr
On Fri, Aug 7, 2015 at 2:46 AM, Adrian Klaver
wrote:
> I would also take a look at Alvaro's explanation. My understanding is that
> for locking purposes the UNIQUE index is considered sort of like a FK, as
> it could be used as a FK. This then leads to the FOR UPDATE lock, which
> from Table 13.3
The best solution, IMHO, is don't create views that depend on other views.
Although, it makes it easier in some cases, you pay the price in
maintenance, as you have already found out. In addition, there is also the
security problem that comes into play. EG: a user is allowed access to view
c, but s
On 08/06/2015 01:44 PM, W. Matthew Wilson wrote:
I have a bunch of views, and some views use data from other views.
For example, view A might get used by view B and view B gets used by view C.
Several times now, as I got further into the project, I've changed how
I make some views and I've had
I have a bunch of views, and some views use data from other views.
For example, view A might get used by view B and view B gets used by view C.
Several times now, as I got further into the project, I've changed how
I make some views and I've had to redefine not just that view, but all
the ones th
On 7/31/15 5:52 AM, Andrey Lizenko wrote:
If only simple telnet connection started:
[postgres@ubuntu12-vm][20150731 06:30:24]:/db2$ telnet 127.0.0.1 5551
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
new postgres process appeared as a child of the first o
On 08/06/2015 09:29 AM, Sophia Wright wrote:
On Fri, Aug 7, 2015 at 1:11 AM, Alvaro Herrera mailto:alvhe...@2ndquadrant.com>> wrote:
Sophia Wright wrote:
> I am seeing some odd locking behaviour when deleting a parent record
> (Postgres 9.4.4).
Somewhere in the triggers for FK c
On Thu, Aug 6, 2015 at 3:52 PM, Uriy Zhuravlev
wrote:
> Hello all.
> What do you think about adding functionality baseplan/outplan in Postgres? Who
> needs it in postgres?
I suspect they will not be introduced for the same reason of query hints.
I trust the optimizer to do the right choice, or at
On Fri, Aug 7, 2015 at 1:11 AM, Alvaro Herrera
wrote:
> Sophia Wright wrote:
> > I am seeing some odd locking behaviour when deleting a parent record
> > (Postgres 9.4.4).
>
> Somewhere in the triggers for FK checks we do "SELECT FOR KEY SHARE" of
> the PK tuples when the FK tuples are altered; a
On 08/06/2015 07:19 AM, Sophia Wright wrote:
I am seeing some odd locking behaviour when deleting a parent record
(Postgres 9.4.4).
Setup:
create table pk_rel (id int primary key);
create table fk_rel (pk_id int references pk_rel (id), x text unique);
insert into pk_rel values (1), (2);
insert i
Sophia Wright wrote:
> I am seeing some odd locking behaviour when deleting a parent record
> (Postgres 9.4.4).
Somewhere in the triggers for FK checks we do "SELECT FOR KEY SHARE" of
the PK tuples when the FK tuples are altered; and conversely when we
remove tuples from the PK side we need to ens
I am seeing some odd locking behaviour when deleting a parent record
(Postgres 9.4.4).
Setup:
create table pk_rel (id int primary key);
create table fk_rel (pk_id int references pk_rel (id), x text unique);
insert into pk_rel values (1), (2);
insert into fk_rel values (1, 'a');
This example work
Hello all.
What do you think about adding functionality baseplan/outplan in Postgres? Who
needs it in postgres?
Thanks!
--
Uriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To ma
Thanks Adrian and Tom.
Tom wrote:
>
> It's not entirely clear what your question is, but here are some possible
> answers:
>
> 1. For quite some time now, the "query" column in pg_stat_activity has
> been defined as "the query currently or most recently run by the session";
> it's intentional tha
15 matches
Mail list logo
