On Mon, Nov 14, 2011 at 6:09 AM, Kerem Kat wrote:
> On Mon, Nov 14, 2011 at 15:32, Tom Lane wrote:
>> Kerem Kat writes:
>>> Corresponding is currently implemented in the parse/analyze phase. If
>>> it were to be implemented in the planning phase, explain output would
>>> likely be as you expect
On 15.11.2011 19:16, Shigeru Hanada wrote:
This is the second effort for $SUBJECT. Attached patch requires
pgsql_fdw patches[1] to be applied previously. This patch provides:
* Changes for backend
* Add new planner node ForeignJoinPath and related routines. In
current design, planner
I wrote:
> Here it is. I'll add it to the November commitfest.
Here is the second version.
I realized that it is better to set the option on the SSL object
and not on the SSL context so that it is possible to change it
per connection.
I also improved the documentation.
Yours,
Laurenz Albe
ssl
While looking at Shigeru Hanada's foreign join pushdown patch, I noticed
a command line option that I didn't know to exist:
$ postgres --help
...
Developer options:
-f s|i|n|m|hforbid use of some plan types
That doesn't include all the options we support, the documentation
lists: s|i|o|b
Tom Lane writes:
> What you've got here could be useful
> to people who use emacs and understand they've got to hand-check the
> results. I'm not sure how much further it'd be useful to go.
Agreed. That's the reason why I'm proposing src/tools/editors in the
first place. I find that it's enough
On Thu, Nov 17, 2011 at 4:19 AM, Heikki Linnakangas
wrote:
> While looking at Shigeru Hanada's foreign join pushdown patch, I noticed a
> command line option that I didn't know to exist:
>
> $ postgres --help
> ...
> Developer options:
> -f s|i|n|m|h forbid use of some plan types
>
> That does
Excerpts from Robert Haas's message of jue nov 17 10:14:21 -0300 2011:
> On Thu, Nov 17, 2011 at 4:19 AM, Heikki Linnakangas
> wrote:
> > While looking at Shigeru Hanada's foreign join pushdown patch, I noticed a
> > command line option that I didn't know to exist:
> >
> > $ postgres --help
> > .
Excerpts from Tom Lane's message of mié nov 16 22:52:35 -0300 2011:
> (Do we guard against recursive inclusion via plain old include? If
> not, maybe this isn't worth worrying about.)
Yes, we do
FATAL: could not open configuration file "foo.conf": maximum nesting depth
exceeded
--
Álvaro H
On Mon, Nov 14, 2011 at 09:06:30AM +0100, Boszormenyi Zoltan wrote:
> Yes, you are right. For timestamp and interval, the safe alignment is int64.
> Patch is attached.
Applied, thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at Borus
Heikki,
On 17.11.2011 10:19, Heikki Linnakangas wrote:
$ postgres --help
...
Developer options:
-f s|i|n|m|hforbid use of some plan types
That doesn't include all the options we support, the documentation
lists: s|i|o|b|t|n|m|h. These are aliases for enable_* planner
options, e.g -fs is
Heikki Linnakangas writes:
> When the FDW recognizes it's being asked to join a ForeignJoinPath and a
> ForeignPath, or two ForeignJoinPaths, it throws away the old SQL it
> constructed to do the two-way join, and builds a new one to join all
> three tables.
It should certainly not "throw away
On 17 November 2011 03:54, Tom Lane wrote:
> It's not reasonable to suppose
> that nobody is using it today.
I didn't suppose that no one is using it, but that those that are
using it are unaware of the risks with prefix validation, and that
there will be a rude awakening for them.
> Ergo, we ca
Heikki Linnakangas writes:
> While looking at Shigeru Hanada's foreign join pushdown patch, I noticed
> a command line option that I didn't know to exist:
> $ postgres --help
> ...
> Developer options:
>-f s|i|n|m|hforbid use of some plan types
Hmm, I thought I'd fixed that help message
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié nov 16 22:52:35 -0300 2011:
>> (Do we guard against recursive inclusion via plain old include? If
>> not, maybe this isn't worth worrying about.)
> Yes, we do
> FATAL: could not open configuration file "foo.conf": maximum nestin
On Tue, Nov 15, 2011 at 4:43 AM, Kohei KaiGai wrote:
> Part-1) DROP statement refactoring
> It is a remaining portion of what I submitted in the last commit fest.
> It allows object types that didn't used DropStmt in gram.y to go
> through RemoveObjects(), instead of individual Remove().
Revi
On Wed, Nov 16, 2011 at 4:09 PM, Scott Mead wrote:
>
>
> On Tue, Nov 15, 2011 at 1:18 PM, Robert Treat wrote:
>
>> On Tue, Nov 15, 2011 at 12:00 PM, Greg Smith
>> wrote:
>> > On 11/15/2011 09:44 AM, Scott Mead wrote:
>> >>
>> >> Fell off the map last week, here's v2 that:
>> >> * RUNNING => ac
On Thu, Nov 17, 2011 at 10:44 AM, Peter Geoghegan wrote:
> I think that's it's rather unlikely that removing hyphenation and
> prefix validation would adversely affect anyone, provided that it was
> well documented and wasn't applied to stable branches. If it were up
> to me, I might remove valida
Robert Haas writes:
> At the same time, I still think we should push this out to PGXN or
> pgfoundry or something. The fact that it's useful to some people does
> not mean that it's a good example for other people to follow, or that
> we want the core distribution to be in the process of tracking
Robert Haas writes:
> It also eliminates the NOTICE when removing a built-in
> function, which I think is OK because you don't actually get that far:
There are paths that can reach that notice --- I think what you have to
do is create a new function that references a built-in one. But why
we bot
.
And to your original question, it seems that << and >> should be
commutators. Perhaps I had a reason earlier, but it is escaping me now.
What edge cases did you have in mind?
Regards,
Jeff Davis
cmp-bounds-2017.gz
Description: GNU Zip compressed data
--
Sent vi
On Wed, 2011-11-16 at 16:41 -0500, Tom Lane wrote:
> But what surprises me about this example is that I'd have expected the
> heuristic "assume the unknown is of the same type as the other input"
> to resolve it. Looking more closely, I see that we apply that heuristic
> in such a way that it work
On Thu, Nov 17, 2011 at 1:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> It also eliminates the NOTICE when removing a built-in
>> function, which I think is OK because you don't actually get that far:
>
> There are paths that can reach that notice --- I think what you have to
> do is create a n
On mån, 2011-11-14 at 20:44 -0500, Greg Smith wrote:
> The very specific problem I was most concerned about eliminating was
> people discovering they needed an extension to troubleshoot
> performance or corruption issues, only to discover it wasn't
> available--because they hadn't installed the pos
Jeff Davis writes:
> On Wed, 2011-11-16 at 16:41 -0500, Tom Lane wrote:
>> I propose adding a step to func_select_candidate
>> that tries to resolve things that way, ie, if all the known-type inputs
>> have the same type, then try assuming that the unknown-type ones are of
>> that type, and see if
In commit 4240e429d0c2d889d0cda23c618f94e12c13ade7, we modified
RangeVarGetRelid() so that it acquires a lock on the target relation
"atomically" with respect to the name lookup. Since we lock OIDs, not
names, that's not possible, strictly speaking, but the idea is that we
detect whether any inval
Excerpts from Robert Haas's message of jue nov 17 17:51:06 -0300 2011:
> The trouble is, I'm not quite sure how to do that. It seems like
> permissions checks and lock-the-heap-for-this-index should be done in
> RangeVarGetRelid() just after the block that says "if (retry)" and
> just before the
Excerpts from Robert Haas's message of jue nov 17 16:25:03 -0300 2011:
> On Thu, Nov 17, 2011 at 1:00 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> - For some reason, we have code that causes procedural language names
> >> to be downcased before use.
> >
> > I think this is a hangover from t
Jeff Davis writes:
> Yikes! While commenting the code, it turns out that I missed the case
> where the values match and they are both exclusive; but one is upper and
> the other lower. Worse than that, there were apparently some bogus test
> results that expected the wrong output. Mea culpa.
> Pa
On Thu, Nov 17, 2011 at 4:26 PM, Alvaro Herrera
wrote:
> So the buildfarm broke due to this change, because citext does
Thanks for fixing it. Should we revert the original change?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hac
On Wed, Nov 16, 2011 at 9:38 AM, Rudyar wrote:
> Hello,
>
> I'm new in postgreSQL programming. I try to print a tuple from
> tupleTableSlot structure..
> for example..
>
> outerTupleSlot = ExecHashJoinOuterGetTuple(outerNode,
> node,
> &has
On 17/11/11 19:16, Robert Haas wrote:
On Wed, Nov 16, 2011 at 9:38 AM, Rudyar wrote:
Hello,
I'm new in postgreSQL programming. I try to print a tuple from
tupleTableSlot structure..
for example..
outerTupleSlot = ExecHashJoinOuterGetTuple(outerNode,
Robert Haas writes:
> On Thu, Nov 17, 2011 at 4:26 PM, Alvaro Herrera
> wrote:
>> So the buildfarm broke due to this change, because citext does
> Thanks for fixing it. Should we revert the original change?
I still think it's reasonable to remove the extra downcasing step,
but we'll have to do
On Mon, Nov 14, 2011 at 7:04 PM, Josh Kupershmidt wrote:
> But it reminded me of another issue. With OS X 10.6.8, and otool -L
> reporting that psql depends on libedit version 2.11.0, the up-arrow
> recall of Tomas' query gets truncated around here:
> 5I0/NTm+fFkB0McY9E2fAA [rest of the line miss
On 17/11/2011, at 1:47 AM, Robert Haas wrote:
> On Wed, Nov 16, 2011 at 9:34 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Not sure about the log line, but allowing pgstattuple to distinguish
>>> between recently-dead and quite-thoroughly-dead seems useful.
>>
>> The dividing line is enormous
On Thu, Nov 17, 2011 at 5:49 PM, Royce Ausburn wrote:
> Thanks for the discussion so far all. Would it be worthwhile to make another
> patch that addresses the points from Yeb's reviews? It's not sounding like
> this unremovable tuple count is something that postgres wants, but I'm happy
> to
On Thu, Nov 17, 2011 at 5:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Nov 17, 2011 at 4:26 PM, Alvaro Herrera
>> wrote:
>>> So the buildfarm broke due to this change, because citext does
>
>> Thanks for fixing it. Should we revert the original change?
>
> I still think it's reasonab
On 18/11/2011, at 10:44 AM, Robert Haas wrote:
> On Thu, Nov 17, 2011 at 5:49 PM, Royce Ausburn wrote:
>> Thanks for the discussion so far all. Would it be worthwhile to make
>> another patch that addresses the points from Yeb's reviews? It's not
>> sounding like this unremovable tuple count
Robert Haas writes:
> On Thu, Nov 17, 2011 at 5:29 PM, Tom Lane wrote:
>> I still think it's reasonable to remove the extra downcasing step,
>> but we'll have to document it as a change.
> So, should we add a note to all the LANGUAGE command pages in the
> manual? Or just include this in the re
On Thu, Nov 17, 2011 at 4:12 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue nov 17 17:51:06 -0300 2011:
>> The trouble is, I'm not quite sure how to do that. It seems like
>> permissions checks and lock-the-heap-for-this-index should be done in
>> RangeVarGetRelid() just a
The core and packagers lists have agreed to the schedule that was
proposed towards the end of last week's discussion:
http://archives.postgresql.org/pgsql-hackers/2011-11/msg00578.php
That is, we'll wrap tarballs on Thursday Dec 1 for public announcement
Monday Dec 5.
Since the announced EOL date
On Thu, Nov 17, 2011 at 11:21 AM, Robert Haas wrote:
> On Tue, Nov 15, 2011 at 4:43 AM, Kohei KaiGai wrote:
>> Part-1) DROP statement refactoring
>> It is a remaining portion of what I submitted in the last commit fest.
>> It allows object types that didn't used DropStmt in gram.y to go
>> throug
On Tue, Nov 15, 2011 at 4:43 AM, Kohei KaiGai wrote:
> Part-2) Groundworks on objectaddress.c
> This patch adds necessary groundworks for Part-3 and Part-4.
> It adds ObjectPropertyType of objectaddress.c index-oid and cache-id
> for name lookup and attribute number of object name; these field is
On Thu, Nov 17, 2011 at 08:59:58PM -0500, Robert Haas wrote:
> On Thu, Nov 17, 2011 at 4:12 PM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of jue nov 17 17:51:06 -0300 2011:
> >> The trouble is, I'm not quite sure how to do that. ?It seems like
> >> permissions checks and loc
On Tue, Nov 15, 2011 at 4:43 AM, Kohei KaiGai wrote:
> Part-2) Groundworks on objectaddress.c
> This patch adds necessary groundworks for Part-3 and Part-4.
> It adds ObjectPropertyType of objectaddress.c index-oid and cache-id
> for name lookup and attribute number of object name; these field is
When using verbose error messages (psql \set VERBOSITY verbose) with a
vpath build, you get this sort of thing:
ERROR: 42703: column "foo" does not exist
LINE 1: select foo;
^
LOCATION: transformColumnRef,
/build/buildd-postgresql-9.1_9.1.1-3-i386-AP0ovQ/postgresql-9.1-9.1.1/buil
On Thu, Nov 17, 2011 at 10:48 PM, Noah Misch wrote:
> On Thu, Nov 17, 2011 at 08:59:58PM -0500, Robert Haas wrote:
>> On Thu, Nov 17, 2011 at 4:12 PM, Alvaro Herrera
>> wrote:
>> > Excerpts from Robert Haas's message of jue nov 17 17:51:06 -0300 2011:
>> >> The trouble is, I'm not quite sure how
On Sun, Sep 25, 2011 at 10:12 PM, Peter Geoghegan wrote:
> I've produced something much neater than my first patch, attached,
> although I still consider this to be at the POC stage, not least since
> I'm not exactly sure how I should be selecting the right
> specialisation in tuplesort_performsor
(2011/11/07 20:26), Shigeru Hanada wrote:
> (2011/10/20 18:56), Etsuro Fujita wrote:
>> I revised the patch according to Hanada-san's comments. Attached is the
>> updated version of the patch.
>>
>> Changes:
>>
>> * pull up of logging "analyzing foo.bar"
>> * new vac_update_relstats always
48 matches
Mail list logo
