On 2012-05-25, Marc Munro m...@bloodnok.com wrote:
$ /usr/lib/postgresql/9.2/bin/psql: symbol lookup
error: /usr/lib/postgresql/9.2/bin/psql: undefined symbol:
PQconnectdbParams
At times like that I run /sbin/ldconfig
Sometimes it helps.
--
⚂⚃ 100% natural
--
Sent via pgsql-general
On Tue, 2012-05-15 at 12:52 +0300, Catalin(ux) M. BOIE wrote:
The old_stats is so big that I cannot afford to add a check constraint.
But, I know that all values of the itime field are before 2012_04, so,
would be great if I could run something like:
ALTER TABLE old_stats ADD CONSTRAINT xxx
There is behavior in the following code that has me confused, and I'd like to
understand it, as it goes against how I thought that MVCC worked in psql:
create table t1 (a integer primary key, b integer default 0);
insert into t1 (a) values (1);
create function f1() returns int
On Sun, May 27, 2012 at 8:17 AM, Brian Palmer br...@codekitchen.net wrote:
There is behavior in the following code that has me confused, and I'd like to
understand it, as it goes against how I thought that MVCC worked in psql:
...
select a from t1 into ret where b 1 for update;
On May 26, 2012, at 5:22 PM, Chris Angelico wrote:
The function is actually immaterial to this; the same thing occurs
with this single statement:
with t1upd as (update t1 set b = b + 1 where b 1 returning a) select
* from t1 join t1upd using (a);
Poking around with the latter form of
On Sun, May 27, 2012 at 11:36 AM, Brian Palmer br...@codekitchen.net wrote:
That's a good link, thanks Chris. I'm not sure it entirely answers what I'm
seeing though. It does explain why the outer select doesn't see the updated
values, but the other thing that I'm seeing is that sometimes the
On May 26, 2012, at 7:45 PM, Chris Angelico wrote:
I'd be inclined to treat it like C and avoid referencing and
altering a variable in one expression (eg arr[i++]=i; is a bad idea).
I agree, we're already working on changing it to a two-step process where we
select f1(), and then select *
Brian Palmer br...@codekitchen.net writes:
The final line, the select, will return the row as it was before the
function ran, (1,0) instead of (1,1). It's as if the outer select
locked its view of the table in place before the inner select ran.
Yes, that's exactly correct. A plain SELECT
Thanks so much tom! I feel a lot better going with this fix now that I know for
sure what was going wrong.
-- Brian
On May 26, 2012, at 8:08 PM, Tom Lane wrote:
Brian Palmer br...@codekitchen.net writes:
The final line, the select, will return the row as it was before the
function ran,
