2010/7/13 Pavel Stehule pavel.steh...@gmail.com:
so this is actualised patch:
* concat_sql removed
* left, right, reverse and concat are in core
* printf and concat_ws are in contrib
* format show NULL as NULL string
* removed an using of wide chars
I think function codes in the core
On Wed, Jul 7, 2010 at 7:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Rajanikant Chirmade rajanikant.chirm...@enterprisedb.com writes:
Every identifier is downcase truncated by function
downcase_truncate_identifier()
before using it.
But since the function downcase_truncate_identifier()
Tom Lane wrote:
The reason I'm on about this at the moment is that I think I see how to
get ruleutils to print PARAM_EXEC Params as the referenced expression
rather than $N ...
Wouldn't this obfuscate the plan more than printing subplan arguments at
the call site?
regards,
Yeb Havinga
--
* Tom Lane (t...@sss.pgh.pa.us) wrote:
A few experiments later: I can reproduce the failure shown on pangolin
exactly if I revert the latest changes in sql/dblink.sql and
expected/dblink.out, while keeping dblink.c up to date. So I guessed
wrong on which file was out of sync, but I say
Itagaki Takahiro wrote:
I think the patch is almost ready for committer except the following
three issues:
2010/7/13 Fujii Masao masao.fu...@gmail.com:
+ if (!*value || *endptr || file_mode 0 || file_mode 0777)
The sticky bit cannot be set via log_file_mode. Is this intentional?
Yes
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
A few experiments later: I can reproduce the failure shown on pangolin
exactly if I revert the latest changes in sql/dblink.sql and
expected/dblink.out, while keeping dblink.c up to date. So I guessed
wrong on which file was out
Yeb Havinga yebhavi...@gmail.com writes:
Tom Lane wrote:
The reason I'm on about this at the moment is that I think I see how to
get ruleutils to print PARAM_EXEC Params as the referenced expression
rather than $N ...
Wouldn't this obfuscate the plan more than printing subplan arguments at
The CF starts the day after tomorrow. If you've been working on a
patch and you want feedback, you must post it to the -hackers list
and create an entry in the CF application before the start of the
CommitFest, or you will likely need to wait until the September CF
for a review.
See this Wiki
Hi,
I've been working on modularizing Postgres-R to ease review and maybe
allow code reuse. As threatened at the Cluster Meeting in Tokyo and
again at CHAR(10), I'm now presenting more results of that effort: the
background workers infrastructure module.
Postgres-R so far used custom
This patch turns the existing autovacuum launcher into an always running
process, partly called the coordinator. If autovacuum is disabled, the
coordinator process still gets started and keeps around, but it doesn't
dispatch vacuum jobs. The coordinator process now uses imessages to
Itagaki Takahiro itagaki.takah...@gmail.com writes:
...
We should also check the value not to be something like 0699.
How about checking it with (file_mode ~0666) != 0 ?
...
I want show_log_file_mode to print the setting value in octal format.
It seems like a whole lot of lily-gilding is
This patch adds the capability for the coordinator to listen on sockets
while waiting for imessages to arrive. Before the coordinator just slept
until a signal arrives, notifying the coordinator about an internal message.
Major caveat here: I'm using pselect(), which might still not be
Finally, this patch adds the capability to cache out-of-order messages
for workers within the coordinator process. Unlike the cache of jobs,
which basically are messages as well, these messages don't trigger a
job, but might provide additional information or data payload to a
worker that's
Hi!
* levenshtein_internal() and levenshtein_less_equal_internal() are very
similar. Can you merge the code? We can always use less_equal_internal()
if the overhead is ignorable. Did you compare them?
With big value of max_d overhead is significant. Here is example on
american-english
Tom Lane wrote:
Yeb Havinga yebhavi...@gmail.com writes:
Tom Lane wrote:
The reason I'm on about this at the moment is that I think I see how to
get ruleutils to print PARAM_EXEC Params as the referenced expression
rather than $N ...
Wouldn't this obfuscate the plan more than
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
as a superuser:
SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
FROM pg_proc pr
LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid
On 13 July 2010 16:31, Dave Page dp...@pgadmin.org wrote:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
as a superuser:
SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
FROM pg_proc pr
On 13 July 2010 16:44, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 16:31, Dave Page dp...@pgadmin.org wrote:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
as a superuser:
SELECT
On Tue, Jul 13, 2010 at 4:48 PM, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 16:44, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 16:31, Dave Page dp...@pgadmin.org wrote:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly
On 13 July 2010 16:50, Dave Page dp...@pgadmin.org wrote:
On Tue, Jul 13, 2010 at 4:48 PM, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 16:44, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 16:31, Dave Page dp...@pgadmin.org wrote:
We had a report of the above error from a
On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown thombr...@gmail.com wrote:
I works if you use pr.proargdefaults so not unresolvable. Maybe it's
because it can't tell where the column's coming from at that point?
Hmm, so it does. It still seems like a bug though - why should it be
able to resolve
On 13 July 2010 17:00, Dave Page dp...@pgadmin.org wrote:
On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown thombr...@gmail.com wrote:
I works if you use pr.proargdefaults so not unresolvable. Maybe it's
because it can't tell where the column's coming from at that point?
Hmm, so it does. It still
On 13 July 2010 17:01, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 17:00, Dave Page dp...@pgadmin.org wrote:
On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown thombr...@gmail.com wrote:
I works if you use pr.proargdefaults so not unresolvable. Maybe it's
because it can't tell where the
Dave Page dp...@pgadmin.org writes:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
as a superuser:
SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
FROM pg_proc pr
LEFT OUTER JOIN
Markus Wanner mar...@bluegap.ch wrote:
(I don't dare to add these patches to the commit fest, as this
refactoring doesn't have any immediate benefit for Postgres
itself, at the moment.)
You could submit them as Work In Progress patches
-Kevin
--
Sent via pgsql-hackers mailing list
I'm testing beta 3 and ran across a PL/Python3u bug again.
This time it won't let me install it at all.
Kubuntu 10.04
./configure --with-pgport=5433 --with-python --with-ossp-uuid --with-libxml
--with-libxslt --with-perl --prefix=/usr/local/pgsqlb3
make
make check
sudo make install
All work fine.
On tis, 2010-07-13 at 15:38 -0500, Chris wrote:
I'm testing beta 3 and ran across a PL/Python3u bug again.
This time it won't let me install it at all.
Kubuntu 10.04
./configure --with-pgport=5433 --with-python --with-ossp-uuid
--with-libxml
--with-libxslt --with-perl
If we are going to hit mid-August for Postgres 9.0 final, we will
probably need a final beta in the next two weeks, or go right to 9.0 RC
in early August. Should we schedule 9.0 beta4 now in case we need it?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
On Tue, 13 Jul 2010, Bruce Momjian wrote:
If we are going to hit mid-August for Postgres 9.0 final, we will
probably need a final beta in the next two weeks, or go right to 9.0 RC
in early August. Should we schedule 9.0 beta4 now in case we need it?
Go with 2 weeks-ish ... if there is no
Marc G. Fournier wrote:
On Tue, 13 Jul 2010, Bruce Momjian wrote:
If we are going to hit mid-August for Postgres 9.0 final, we will
probably need a final beta in the next two weeks, or go right to 9.0 RC
in early August. Should we schedule 9.0 beta4 now in case we need it?
Go with 2
So if I have to explicitly set the python interpretor, how would you ever
have a plpython2u and plpython3u function in the same DB (regardless of the
fact that they can't run in the same session)? The manual implies you could
have them both installed since it says that there's a per session
Chris rfu...@gmail.com writes:
So if I have to explicitly set the python interpretor, how would you ever
have a plpython2u and plpython3u function in the same DB (regardless of the
fact that they can't run in the same session)?
You'd have to build the two plpython.so's in separate compile
Hi all,
I took a stab at changing this up a little bit. I pushed the logic
that David introduced down into process_file(). In doing so I changed
up the declaration of process_file() to accept an additional parameter
specifying how many files are being passed to the function. Doing it
this way
The attached patch is a part of efforts to support security label
on database objects.
It adds a new system catalog named pg_seclabel, that has similar
structure with pg_description.
#define SecLabelRelationId3037
CATALOG(pg_seclabel,3037) BKI_WITHOUT_OIDS
{
Oid
The attached patch is a part of efforts to support security label
on database objects.
It adds statement support to manage security label of relations.
Right now, object labeling except for relations/columns are not
supported, because the DML permission hook is the only chance to
apply access
35 matches
Mail list logo
