Hello
please, can you refresh patch, please?
[pa...@nemesis pgsql]$ patch -p1 < backend.patch
patching file src/backend/access/common/reloptions.c
patching file src/backend/catalog/Makefile
patching file src/backend/catalog/aclchk.c
patching file src/backend/catalog/dependency.c
patching file src
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 cont
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 reloi
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 a
Chris 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 operations.
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
limita
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
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 reas
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 http://momjian.us
EnterpriseDB
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 --prefix=/usr/l
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.
Markus Wanner 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 (pgsql-hackers@
Dave Page 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 pg_descriptio
On 13 July 2010 17:01, Thom Brown wrote:
> On 13 July 2010 17:00, Dave Page wrote:
>> On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown 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,
On 13 July 2010 17:00, Dave Page wrote:
> On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown 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 - wh
On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown 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 the column based o
On 13 July 2010 16:50, Dave Page wrote:
> On Tue, Jul 13, 2010 at 4:48 PM, Thom Brown wrote:
>> On 13 July 2010 16:44, Thom Brown wrote:
>>> On 13 July 2010 16:31, Dave Page wrote:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simpl
On Tue, Jul 13, 2010 at 4:48 PM, Thom Brown wrote:
> On 13 July 2010 16:44, Thom Brown wrote:
>> On 13 July 2010 16:31, Dave Page 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 superuse
On 13 July 2010 16:44, Thom Brown wrote:
> On 13 July 2010 16:31, Dave Page 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
On 13 July 2010 16:31, Dave Page 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
> LEFT OUT
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
Run
Tom Lane wrote:
Yeb Havinga 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 argume
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 dict
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 alre
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
portabl
Itagaki Takahiro 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 going on here. Just ma
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
communicate
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 backend
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 pa
Yeb Havinga 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 call si
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 o
Itagaki Takahiro wrote:
> I think the patch is almost ready for committer except the following
> three issues:
>
> 2010/7/13 Fujii Masao :
>>> + if (!*value || *endptr || file_mode < 0 || file_mode > 0777)
>> The sticky bit cannot be set via log_file_mode. Is this intentional?
Yes -- I don't
* 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 con
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
--
Sen
On Wed, Jul 7, 2010 at 7:37 PM, Tom Lane wrote:
> Rajanikant Chirmade writes:
> > Every identifier is downcase & truncated by function
> > "downcase_truncate_identifier()"
> > before using it.
>
> > But since the function "downcase_truncate_identifier()" is not
> > multibyte-charecter aware,
> >
35 matches
Mail list logo
