Heikki Linnakangas wrote:
> Hmm, seems that dblink should call truncate_identifier() for the
> truncation, to be consistent with truncation of table names etc.
Hmmm, we need the same routine with truncate_identifier(), but we hard
to use the function because it modifies the input buffer direct
On Mon, May 31, 2010 at 7:17 PM, Fujii Masao wrote:
> 4) Change it so that checkpoint_segments takes effect in standby mode,
> but not during recovery otherwise
I revised the patch to achieve 4). This will enable checkpoint_segments
to trigger a restartpoint like checkpoint_timeout already does,
(2010/06/02 10:52), Robert Haas wrote:
> 2010/6/1 KaiGai Kohei:
>>> Eh, if that's the consensus, it doesn't bother me that much, but it
>>> doesn't really answer the question, either: supposing we add an
>>> explicit concept of a security view, what should its semantics be?
>>
>> How about a GUC op
2010/6/1 KaiGai Kohei :
>> Eh, if that's the consensus, it doesn't bother me that much, but it
>> doesn't really answer the question, either: supposing we add an
>> explicit concept of a security view, what should its semantics be?
>
> How about a GUC option to provide the default, like default_wit
(2010/06/02 2:28), Robert Haas wrote:
> On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane wrote:
CREATE SECURITY VIEW, anyone?
>>
>>> That may be the best approach, but I think it needs more than one line
>>> of exposition.
(2010/06/01 22:09), Robert Haas wrote:
> 2010/6/1 KaiGai Kohei:
>> I have an idea that we add FuncExpr a new field (e.g nestlevel) to remember
>> where is originally put in the query, and prevent reordering over the nest
>> level of subqueries.
>> In above example, f_malicious() has nestlevel=0 bec
(2010/06/01 22:16), Robert Haas wrote:
> 2010/6/1 Heikki Linnakangas:
>> The general problem is that it seems like a nightmare to maintain this
>> throughout the planner. Who knows what optimizations this affects, and
>> do we need to hide things like row-counts in EXPLAIN output? If we try
>> to b
On Wed, Mar 31, 2010 at 9:47 AM, Mike Lewis wrote:
> Thanks. Added it.
>
> https://commitfest.postgresql.org/action/patch_view?id=292
I have reviewed this patch; this is my review:
Regression tests pass with assertions enabled.
Performance gains reported by author confirmed.
The existence and
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Hm. Neither of these obviously exclude the case of an absolute path
> >> that happens to lead to cwd. I'm not sure how important that is,
> >> but still ...
>
> > We currently do that with path_is_prefix_of_path(). Maybe that nee
Bruce Momjian writes:
> Tom Lane wrote:
>> Hm. Neither of these obviously exclude the case of an absolute path
>> that happens to lead to cwd. I'm not sure how important that is,
>> but still ...
> We currently do that with path_is_prefix_of_path(). Maybe that needs to
> be called as well.
I
Tom Lane wrote:
> Bruce Momjian writes:
> > Robert Haas wrote:
> >> Maybe something like is_under_cwd()?
>
> > Yeah, is_below_cwd?
>
> Hm. Neither of these obviously exclude the case of an absolute path
> that happens to lead to cwd. I'm not sure how important that is,
> but still ...
We curr
Bruce Momjian writes:
> Robert Haas wrote:
>> Maybe something like is_under_cwd()?
> Yeah, is_below_cwd?
Hm. Neither of these obviously exclude the case of an absolute path
that happens to lead to cwd. I'm not sure how important that is,
but still ...
regards, tom lane
Robert Haas wrote:
> On Tue, Jun 1, 2010 at 3:20 PM, Giles Lean wrote:
> > 1. is_relative_to_cwd() I continue to think is a bad name for something
> > ? concerned about ".." (plus on Windows not having a drive letter other
> > ? than the current one); the "normal" meaning of "relative path" is
> >
井上です。
ご苦労様です。
このスレッド気になっていたのですが、ようやく少し
余裕ができたのでテストなどしてみました。
Takahiro Itagaki wrote:
> Log Message:
> ---
> PGDLLEXPORT is __declspec (dllexport) only on MSVC,
> but is __declspec (dllimport) on other compilers
私が知る限りdlimportがexportの引きがねになることは
ないのでこの部分にはかなり違和感を感じていました。
実際__declspec(..)をすっ
On Tue, Jun 1, 2010 at 4:57 PM, Robert Haas wrote:
> On Tue, Jun 1, 2010 at 4:10 PM, Merlin Moncure wrote:
>> have you ruled out: 'create function'? :-)
>
> You lost me...
Well, as noted by the OP, using views for security in postgres is
simply wishful thinking. This is part of a family of issu
On Tue, Jun 1, 2010 at 4:10 PM, Merlin Moncure wrote:
> On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas wrote:
>> On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane wrote:
>>> Robert Haas writes:
On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane wrote:
> CREATE SECURITY VIEW, anyone?
>>>
That may be t
On lör, 2010-05-29 at 00:18 +0300, Heikki Linnakangas wrote:
> What does the spec have to say about the ctype used for upper() et al
> BTW?
It doesn't make any provisions for locale dependencies for that.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas wrote:
> On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane wrote:
CREATE SECURITY VIEW, anyone?
>>
>>> That may be the best approach, but I think it needs more than one line
>>> o
On Tue, Jun 1, 2010 at 3:20 PM, Giles Lean wrote:
> 1. is_relative_to_cwd() I continue to think is a bad name for something
> concerned about ".." (plus on Windows not having a drive letter other
> than the current one); the "normal" meaning of "relative path" is
> merely "not absolute"
May
Tom Lane wrote:
> Yeah. If we were to go with Greg's suggestion of inventing a separate
> is_relative_to_cwd test function, I'd expect that to insist on no ".."
> while it was at it.
So it's now two problems, and I think this is my final comment:
1. is_relative_to_cwd() I continue to think is
[moving to -www list with bc to -hackers]
Alvaro Herrera wrote:
> BTW maybe the developer faq could use all the info gathered in
> this thread.
I wound up putting a few sentences from this thread into the
CommitFest Wiki page, and linking to that from the "Submitting a
Patch" and "Developer F
On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane wrote:
>>> CREATE SECURITY VIEW, anyone?
>
>> That may be the best approach, but I think it needs more than one line
>> of exposition. The approach I proposed was to test whether t
Robert Haas writes:
> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane wrote:
>> CREATE SECURITY VIEW, anyone?
> That may be the best approach, but I think it needs more than one line
> of exposition. The approach I proposed was to test whether the user
> has privileges to execute the underlying query
On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane wrote:
> CREATE SECURITY VIEW, anyone?
That may be the best approach, but I think it needs more than one line
of exposition. The approach I proposed was to test whether the user
has privileges to execute the underlying query directly without going
throug
* Greg Stark (gsst...@mit.edu) wrote:
> Also incidentally I'm having trouble imagining a scenario where this
> really matters. For it to be an issue you would have to simultaneously
> have a user which can't access all the data and must go through views
> which limit the data he can access -- and h
On 5/26/2010 10:16 PM, Tatsuo Ishii wrote:
As was already discussed, I don't believe that premise. None of the
applications you cite would be able to make use of the raw parser
output, because it doesn't contain the semantic information they need.
If what you actually meant was the analyzed pars
On 6/1/2010 11:09 AM, Bruce Momjian wrote:
Jan Wieck wrote:
>> > I see no problem with integrating that into core, technically or
>> > philosophically.
>> >
>>
>> Which means that if I want to allow a consumer of that commit order data
>> to go offline for three days or so to replicate the 5
Quoting Peter Eisentraut :
It would be nice to make XMLEXISTS work as in the standard, seeing how
many others are providing the same interface.
...
I think providing XPath is enough, at least for now.
Hi Peter,
From piecing together sections 8.4 () and 6.18
(), I believe the full call
Thom Brown writes:
> Yes, I can see that now. I'd looked up other messages which appear in
> the log and noticed they were terminated with newlines in the
> back-end, but I guess those were of a different type and happen to
> share the same output.
Hm, sure you're not thinking of frontend code?
Excerpts from Thom Brown's message of mar jun 01 11:34:38 -0400 2010:
> On 1 June 2010 16:28, Alvaro Herrera wrote:
> > The message pieces are sent separately. They are only crammed in a
> > single line if the interface is using the old mechanism to extract error
> > message info; anything built
On 1 June 2010 16:50, Tom Lane wrote:
> Thom Brown writes:
>> I see what you mean. I'm seeing this in the latest version of pgAdmin
>> III (1.10.3) so looks like it's not up-to-date in that respect.
>> Should report it as a pgAdmin problem then?
>
> Yes. The message texts in ereport() calls are
Thom Brown writes:
> I see what you mean. I'm seeing this in the latest version of pgAdmin
> III (1.10.3) so looks like it's not up-to-date in that respect.
> Should report it as a pgAdmin problem then?
Yes. The message texts in ereport() calls are *not* supposed to have
trailing newlines. If
Alvaro Herrera wrote:
> Hmm, cvs diff -Ncp does show method names too, so this is probably
> filterdiff removing them.
My bad; I apparently got confused somehow when looking at a context
diff -- the function names are indeed there after the filterdiff
conversion. Sorry for the noise on that.
Also incidentally I'm having trouble imagining a scenario where this
really matters. For it to be an issue you would have to simultaneously
have a user which can't access all the data and must go through views
which limit the data he can access -- and has privileges to issue DDL
to create functions
On 1 June 2010 16:28, Alvaro Herrera wrote:
> Excerpts from Thom Brown's message of mar jun 01 11:16:33 -0400 2010:
>> This has annoyed me for some time, but it appears that in the VACUUM
>> log, the line which says...
>>
>> INFO: analyzing "%s.%s"
>>
>> ...( and appears in pgsql/src/backend/comma
Excerpts from Kevin Grittner's message of mar jun 01 11:09:38 -0400 2010:
> I agree about the git diff being easier; however, those files are in
> unified format and some committers prefer to read the context
> format, so I'd recommend piping it through filterdiff
> --format=context. Personally,
Excerpts from Thom Brown's message of mar jun 01 11:16:33 -0400 2010:
> This has annoyed me for some time, but it appears that in the VACUUM
> log, the line which says...
>
> INFO: analyzing "%s.%s"
>
> ...( and appears in pgsql/src/backend/commands/analyze.c lines 282 and
> 287 ) doesn't termin
This has annoyed me for some time, but it appears that in the VACUUM
log, the line which says...
INFO: analyzing "%s.%s"
...( and appears in pgsql/src/backend/commands/analyze.c lines 282 and
287 ) doesn't terminate with a newline, meaning the next message
appears immediately after it. Either t
Andy Balholm wrote:
> I made my diff with src/tools/make_diff, as suggested in the
> Developer FAQ. But using git diff would be less hassle. Do the
> diffs from git diff work just as well?
I agree about the git diff being easier; however, those files are in
unified format and some committers p
Jan Wieck wrote:
> >> > I see no problem with integrating that into core, technically or
> >> > philosophically.
> >> >
> >>
> >> Which means that if I want to allow a consumer of that commit order data
> >> to go offline for three days or so to replicate the 5 requested, low
> >> volume tables
On 5/28/2010 7:19 PM, Bruce Momjian wrote:
Jan Wieck wrote:
>> Reading the entire WAL just to find all COMMIT records, then go back to
>> the origin database to get the actual replication log you're looking for
>> is simpler and more efficient? I don't think so.
>
> Agreed, but I think I've no
Andy Balholm wrote:
Thanks for the explanation of CommitFests.
On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
You would then generate a diff in context format and post to the
-hackers list with that file as an attachment.
I made my diff with src/tools/make_diff, as suggested in the Dev
Andy Balholm wrote:
> Thanks for the explanation of CommitFests.
>
> >> On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
> >>> You would then generate a diff in context format and post to the
> >>> -hackers list with that file as an attachment.
>
> I made my diff with src/tools/make_diff, as su
Greg Stark writes:
> Heikki's point is still valid though. Consider if it's not a matter of
> filter ordering but rather that a filter is being pushed down inside a
> join. If the join is from the view then it would be unsafe to filter
> the rows before seeing which rows match the join... unless w
Thanks for the explanation of CommitFests.
>> On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
>>> You would then generate a diff in context format and post to the
>>> -hackers list with that file as an attachment.
I made my diff with src/tools/make_diff, as suggested in the Developer FAQ. Bu
Andy Balholm wrote:
> On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
>> You would then generate a diff in context format and post to the
>> -hackers list with that file as an attachment.
>
> Here it is:
>
> [context diff attachment]
>
> I can't add it to the CommitFest page, since I don't
Bruce Momjian writes:
> Giles Lean wrote:
>> Names are hard, but if I understood the original post, the
>> revised function is intended to check that the directory is
>> below the current working directory.
> We check for things like ".." other places, though we could roll that
> into the macro i
On Tue, Jun 1, 2010 at 7:10 AM, Hardik Belani wrote:
> If we introduce postgres triggers (trigger functions) on some of the tables
> to track insert/update/delete operations, (This is done by keeping and
> updating a counter field for every insert, update and delete operation
> performed on a set
Giles Lean wrote:
>
> Bruce Momjian wrote:
>
> > is_relative_to_cwd()?
>
> ../../../../some/other/place/not/under/cwd
>
> Names are hard, but if I understood the original post, the
> revised function is intended to check that the directory is
> below the current working directory.
We check fo
2010/6/1 Heikki Linnakangas :
> The general problem is that it seems like a nightmare to maintain this
> throughout the planner. Who knows what optimizations this affects, and
> do we need to hide things like row-counts in EXPLAIN output? If we try
> to be very strict, we can expect a stream of CVE
2010/6/1 Heikki Linnakangas :
> On 01/06/10 11:39, KaiGai Kohei wrote:
>> Any operators eventually invokes a function
>> being correctly installed, but an assumption is that we can trust operators,
>> index access method, type input/output methods, conversions and so on,
>> because
>> these featur
2010/6/1 KaiGai Kohei :
> I have an idea that we add FuncExpr a new field (e.g nestlevel) to remember
> where is originally put in the query, and prevent reordering over the nest
> level of subqueries.
> In above example, f_malicious() has nestlevel=0 because it is put on the top
> level.
> But f_p
On Jun 1, 2010, at 10:39 , KaiGai Kohei wrote:
> I have an idea that we add FuncExpr a new field (e.g nestlevel) to remember
> where is originally put in the query, and prevent reordering over the nest
> level of subqueries.
> In above example, f_malicious() has nestlevel=0 because it is put on the
On tis, 2010-06-01 at 16:40 +0530, Hardik Belani wrote:
> If we introduce postgres triggers (trigger functions) on some of the
> tables to track insert/update/delete operations, (This is done by
> keeping and updating a counter field for every insert, update and
> delete operation performed on a s
We have a multi-threaded environment in linux where multiple threads are
performing database operations(insert, update, select and at times delete as
well) in transaction mode (which may span across stored
procedures) using unixodbc. Now this as is, works fine.
If we introduce postgres triggers
Thanks for the review.
On Tue, 2010-06-01 at 13:36 +0300, Heikki Linnakangas wrote:
> If we really want to try to salvage max_standby_delay with a meaning
> similar to what it has now, I think we should go with the idea some
> people bashed around earlier and define the grace period as the
> d
On 01/06/10 13:04, KaiGai Kohei wrote:
> Oops, I missed it. Indeed, operator function is not limited to C-language
> functions, so regular users can create it.
>
> Apart from the topic, does it seem to you reasonable direction to tackle to
> the leaky VIEWs problem?
Yeah, I guess it is.
The gene
(2010/06/01 18:08), Heikki Linnakangas wrote:
> On 01/06/10 11:39, KaiGai Kohei wrote:
>> Any operators eventually invokes a function
>> being correctly installed, but an assumption is that we can trust operators,
>> index access method, type input/output methods, conversions and so on,
>> because
On 27/05/10 20:26, Simon Riggs wrote:
On Wed, 2010-05-26 at 16:22 -0700, Josh Berkus wrote:
Just this second posted about that, as it turns out.
I have a v3 *almost* ready of the keepalive patch. It still makes sense
to me after a few days reflection, so is worth discussion and review. In
or ou
On mån, 2010-05-31 at 18:23 -0400, Tom Lane wrote:
> My feeling is that (a) there is no hurry to do anything about an
> unreleased draft of the standard, and (b) perhaps Peter could lobby
> the committee to change the standard before it does get published.
Given that Oracle and DB2 already suppor
On 01/06/10 11:39, KaiGai Kohei wrote:
> Any operators eventually invokes a function
> being correctly installed, but an assumption is that we can trust operators,
> index access method, type input/output methods, conversions and so on, because
> these features have to be installed by DBA (or initd
On 01/06/10 05:55, Takahiro Itagaki wrote:
"Takahiro Itagaki" wrote:
Contib/dblink module seems to have a bug in handling
connection names in NAMEDATALEN-1 bytes.
Here is a patch to fix the bug. I think it comes from wrong usage
of snprintf(NAMEDATALEN - 1). It just copies 62 bytes + \0.
In
As it was reported before, we have an open item about leaky VIEWs for RLS.
On the talk at Ottawa, Robert suggested me to post my idea prior to submit
a patch. So, I'd like to explain my idea at first.
Actually I'm not familiar to optimizar details, so it needs any helps from
experts of optimizar.
Using this code below (particularly heap_open) somehow i can fetch all
table column name, and put in on list of string. Before raw_parsetree is
processed by analyze part.
--start code
-
RangeVar *relation = makeNode(RangeVar);
On 31/05/10 18:09, Shrish Purohit wrote:
Sometime back you have started with "Separate Heap Fetch from Index Scan" which
was planned to support partial index only scans. Are you still working on it or do you
know someone still working on it?
I'm not working on it right now, but hopefully I'll
On 31/05/10 18:14, Tom Lane wrote:
Heikki Linnakangas writes:
The central question is whether checkpoint_segments should trigger
restartpoints or not. When PITR and restartpoints were introduced, the
answer was "no", on the grounds that when you're doing recovery you're
presumably replaying the
66 matches
Mail list logo
