any interaction with user.
It does not create any backward compatibility issues.
Not does it have any performance impact.
regards
bogdan
From 450c339b4284887782b30e154766a0ee90d6f7ee Mon Sep 17 00:00:00 2001
From: Bogdan Pilch bogdan.pi...@opensynergy.com
Date: Sat, 16 Aug 2014 19:42:29 +0200
Subject
a good idea.
So what you're sayig is that if I come up with some nice way of
setting customized time output format, keeping the default the way it
is now, then it would be worth considering?
Now I understand why it says that a discussion is recommended before
implementing and posting. ;-)
bogdan
How about, the format of psql duration can be set via some ...
backslash command or commdn line switch? And the default of course
remains the current behavior?
bogdan
Andres Freund and...@2ndquadrant.com writes:
On 2014-09-28 20:32:30 -0400, Gregory Smith wrote:
On 9/28/14, 7:49 AM, Bogdan
issues if some SQL developers
assumed that the format is always milis.micros.
regards
bogdan
From 25b2e3f9d888ecf0cc6fe0fbb569004cf9ce315b Mon Sep 17 00:00:00 2001
From: Bogdan Pilch bogdan.pi...@opensynergy.com
Date: Sat, 16 Aug 2014 23:20:18 +0200
Subject: [PATCH] BPI: Implemented enhancement f
not create any backward compatibility issues as the default
behavior remains unchanged.
regards
bogdan
From e3ba6cda83b64246c2b4d3df01f62444f4b37c9d Mon Sep 17 00:00:00 2001
From: Bogdan Pilch bogdan.pi...@opensynergy.com
Date: Sun, 7 Sep 2014 18:59:12 +0200
Subject: [PATCH] Implemented support
();
}
select myfunc(mytable) from mytable;
arg_type 65754
select 'mytable'::regclass::oid
65752
I expected them to be equal.
What gives?
For other table the results are 65783 vs 65785.
I'm running v 8.4.3
Thanks,
Bogdan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
risk us being forced to reject it entirely.
I absolutely agree. It nonsense open again and again closed question.
I also agree. What we should do now is to make progress the proposed
feature for v8.4, not a upcoming feature.
BogDan,
As I noted before, I can understand your requirement
On Fri, Feb 13, 2009 at 02:29:39PM +0200, BogDan Vatra wrote:
[..]
A message for postgresql decision board:
Dear postgresql hackers, if I can do something to push row level
acl for 8.4 please tell me, I do anything to have this feature,
it will help me, and I hope many others
here:
http://wiki.postgresql.org/wiki/CommitFestInProgress).
Thanks,
BogDan,
[..]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
}, but it is not a hard enhancement. If such an ACL
is assigned, the tuple is not visible from other users without any
triggers.
For example, please consider when a user kaigai insert a tuple into
customer_products, the {rwd=kaigai} is assigned to the tuple, but
the {rwd=bogdan} is assigned when a user
or the
possibility to CHECK a cell of a row with a subquery in our example
something like this:CHECK (id_customer IN (select id from view_customers)).
If I'll have this feature I don't have to create that triggers anymore. I
hope this is more simple for you to create.
Yours,
BogDan Vatra,
--
Sent via pgsql
From: [EMAIL PROTECTED] (Bogdan)
Newsgroups: comp.databases.postgresql.questions
Subject: help with I/O statistics in 7.3.1
NNTP-Posting-Host: 12.98.224.90
Message-ID: [EMAIL PROTECTED]
I can't make configuration to get filesystem blocks in/out
to show valid data.
Im only getting 0/0 all
Tom Lane wrote:
Bogdan [EMAIL PROTECTED] writes:
I can't make configuration to get filesystem blocks in/out
to show valid data.
Im only getting 0/0 all the time.
Is that functionality available in postgres 7.3.1 ???
That is just printing what getrusage() tells it. Complain to your
13 matches
Mail list logo
