On 16 November 2015 at 15:48, David G. Johnston
wrote:
> You don't need WITH to accomplish this...
>
> INSERT INTO test (c1, c2, c3)
> SELECT c1, c2, c1 * c2
> FROM ( VALUES (3, 7) ) vals (c1, c2);
>
> David J.
>
>
Oh I see, so it's the ability to use VALUES in place of a SELECT, really.
I supp
zh1029 wrote:
> While start PostgreSQL(9.3.6) and execute pg_restore soon after PostgreSQL
> bringing up. I encounter pg_restore failure because of deadlock detected.
pg_restore will not deadlock with itself or system startup.
Set log_connections to "on", then you will see who connected and
cause
I agree with Adrian. If this is on a Linux system, I'd suggest setting up
"icrond" to monitor that file and at least record who is accessing it. In
addition, I would suggest that said Linux system run with SELinux in
"enforcing" mode. That can stop even "root" from updating something, if it
doesn't
More importantly, what version of PostgreSQL and what O/S are you working
with.
If this is Ubuntu, you could simply be looking at the wrong postgresql.conf
file.
On Tue, Nov 17, 2015 at 7:33 AM, John McKown
wrote:
> I agree with Adrian. If this is on a Linux system, I'd suggest setting up
> "icr
On 11/17/2015 01:14 AM, Geoff Winkless wrote:
On 16 November 2015 at 15:48, David G. Johnston
mailto:david.g.johns...@gmail.com>>wrote:
You don't need WITH to accomplish this...
INSERT INTO test (c1, c2, c3)
SELECT c1, c2, c1 * c2
FROM ( VALUES (3, 7) ) vals (c1, c2);
Davi
On 11/17/2015 01:14 AM, Geoff Winkless wrote:
On 16 November 2015 at 15:48, David G. Johnston
mailto:david.g.johns...@gmail.com>>wrote:
You don't need WITH to accomplish this...
INSERT INTO test (c1, c2, c3)
SELECT c1, c2, c1 * c2
FROM ( VALUES (3, 7) ) vals (c1, c2);
Davi
zh1029 writes:
> Unfortunately what's the process 2720 is unknown as no any else log to
> indicate it. It might because the debug level of PostgreSQL had been set too
> lower to show more.
The query you quoted for 2720 looks exactly like one that pg_dump will
issue, cf dumpSequence(). What I thi
On 17 November 2015 at 14:31, Adrian Klaver
wrote:
> On 11/17/2015 01:14 AM, Geoff Winkless wrote:
>
>> INSERT INTO test (c1, c2) VALUES (3, 7); UPDATE test SET c4=c1*c2 WHERE
>> c1=3; UPDATE test SET c5=c4*c3 WHERE c1=3;
>>
>
> Could the above not be shortened to?:
>
> INSERT INTO test (c1, c2)
I have a view with 15 columns and want to create another view based on a
join with another table with 15 columns that includes three columns that
reference one lookup table.
If I use the the below sql I get the error "column "macro_lookup_id"
specified more than once". I have read that I can renam
On 17 November 2015 at 16:10, Killian Driscoll
wrote:
> I have a view with 15 columns and want to create another view based on a
> join with another table with 15 columns that includes three columns that
> reference one lookup table.
>
> If I use the the below sql I get the error "column "macro_l
Your problem is the use of SELECT *
You need to be specific about which columns you are selecting from
macro_lookup
and what names you want to give them. Since you have not provided us with
the full structure, I can only suggest something like
CREATE OR REPLACE VIEW sample_macro AS
SELECT sample.
On 17/11/2015 15:10, Killian Driscoll wrote:
> I have a view with 15 columns and want to create another view based on a
> join with another table with 15 columns that includes three columns that
> reference one lookup table.
>
> If I use the the below sql I get the error "column "macro_lookup_id"
On 17/11/2015 15:33, Killian Driscoll wrote:
>
> In terms of database structure and typing efficiency, it might be better
> to restructure the lookup tables and create a new lookup table for each
> of the three columns instead of one combined one?
[Please keep you replies on-list - thanks!]
You'
> >
> > In terms of database structure and typing efficiency, it might be better
> > to restructure the lookup tables and create a new lookup table for each
> > of the three columns instead of one combined one?
>
> [Please keep you replies on-list - thanks!]
>
Sorry! Didn't mean that
>
> You'
On 17/11/2015 16:07, Killian Driscoll wrote:
>
> >
> > In terms of database structure and typing efficiency, it might be better
> > to restructure the lookup tables and create a new lookup table for each
> > of the three columns instead of one combined one?
>
> [Please keep yo
On 11/17/15 9:21 AM, Melvin Davidson wrote:
Your problem is the use of SELECT *
I've often wished for a way to do *, but make changes to the results
that a normal * would give you. The two operations I've wished for are
to either remove some fields from the list, or to rename some fields.
I
On 11/17/15 8:53 AM, Geoff Winkless wrote:
It takes the column's default value, since it's not explicit in the
first INSERT.
Not sure if it would help or not, but you can use pg_get_expr(adbin,
adrelid) against pg_attrdef to get the default for a column. That would
let you dynamically insert
Thank you Tom Lane
18 matches
Mail list logo
