Given:
select * from test1 full join test2 using (a,b) where b=1;
8.3.1 and CVS HEAD produce a plan in which the b=1 condition is pushed
down into each side of the join, but 8.3.6 and 8.3.7 do not.
Is this intentional? I wasn't able to identify anything applicable in
the release notes.
testcase
Revision to previous hstore patch to fix (and add tests for) some edge
case bugs with nulls or empty arrays.
--
Andrew (irc:RhodiumToad)
hstore_20090716.patch.gz
Description: hstore patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
Having been helping someone out on IRC with what looked initially like
an index corruption problem, it turns out to be (almost certainly) a
locale initialization error.
environment: debian packaged 8.4.0
scenario: restoring a dump results in incorrect indexes for some
specific tables (indexscan o
> "David" == "David E Wheeler" writes:
>> The moment you're adding specific schemas where to put extensions
>> into, you have to adapt your search_path. Some applications
>> already have to manage search_path for their own needs, so we're
>> trying to avoid having those people to care abo
Magnus asked me for this, when the subject came up on IRC. This is a
longstanding ignored issue, for example
http://archives.postgresql.org/message-id/slrnemslp5.2rcr.andrew+non...@atlantis.supernews.net
http://archives.postgresql.org/message-id/15d55918-fa9c-4e6a-ba15-bdc9142a6...@contegix.com
--
>>>>> "Peter" == Peter Eisentraut writes:
> On Tuesday 14 April 2009 07:07:27 Andrew Gierth wrote:
>> FWIW, the SQL spec puts the onus of normalization squarely on the
>> application; the database is allowed to assume that Unicode
>> strings a
> "Gregory" == Gregory Stark writes:
>>> I don't believe that the standard forbids the use of combining
>>> chars at all. RFC 3629 says:
>>>
>>> ... This issue is amenable to solutions based on Unicode
>>> Normalization Forms, see [UAX15].
Gregory> This is the relevant part. Tom was
> "Tom" == Tom Lane writes:
>>> Perhaps more to the point: the previous round of discussion about
>>> this already rejected the idea of treating window functions as a
>>> category fundamentally separate from plain functions --- that is,
>>> we are not following the "aggregate" model of ha
> "Tom" == Tom Lane writes:
Tom> Back to the point at hand: do we want to look at making plpgsql
Tom> respect the GUC?
Surely what matters is the value of the GUC at the time that you did
the CREATE FUNCTION, not the value at the time you happen to be
calling it?
--
Andrew (irc:RhodiumTo
> "Bruce" == Bruce Momjian writes:
>> In the absence of feedback to the contrary, I will submit it for
>> the first commitfest of 8.5, and maintain the pgfoundry version
>> for 8.3 and 8.4.
Bruce> Andrew, do you want to add it to the 8.5 commitfest:
I will do so soon but I need to revis
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> While answering a question about something else, I spotted
Andrew> another omission regarding \ef - no tab-completion for it.
Andrew> This is the trivial patch, not sure if there's any benefit in
Andrew&g
While answering a question about something else, I spotted another
omission regarding \ef - no tab-completion for it.
This is the trivial patch, not sure if there's any benefit in trying
to be more specific.
--
Andrew (irc:RhodiumToad)
Index: src/bin/psql/tab-complete.c
> "Tom" == Tom Lane writes:
> David Fetter writes:
>> On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote:
>>> I still see no point in this unless we expose the information in
>>> pg_timezone_names, which requires rather more than a one-line patch.
>> There's really no point, and
> "Alvaro" == Alvaro Herrera writes:
>> Andrew did, in fact, submit the patch to install zone.tab.
Alvaro> Hmm, yeah, that he did. (Seems to be missing "make
Alvaro> uninstall" support though.)
The rm -rf in the uninstall rule seems to be sufficient for that.
(What _is_ missing, as I s
Back before 8.2 came out, I posted:
> Any view over the full timezone names should also include the
> corresponding data from zone.tab in the timezone library source.
I got no meaningful response to this (Tom responded with an erroneous
statement and ignored my explanation of his mistake).
Back
> "Tom" == Tom Lane writes:
[empty arrays and containment ops]
Tom> From what I understand of GIN's internal workings, this is
Tom> unfixable because there is nothing to make an index entry on
Tom> when looking at an empty array. Unless you know of a trick to
Tom> get around that, we'v
Happened to notice this while looking for something else; the \ef
command appears to be missing from \? output. Suggested patch below.
--
Andrew (irc:RhodiumToad)
Index: src/bin/psql/help.c
===
RCS file: /projects/cvsroot/pgsql/src/
> "Teodor" == Teodor Sigaev writes:
>> even further. And what confidence do you have that this change
>> eliminates all forms of the problem, anyway?
Teodor> Yes, I think. Because that part of code ( if (IS_BADRATIO)
Teodor> {...} ) is a corner case itself. In example from Andrew, all
> "Tom" == Tom Lane writes:
> Teodor Sigaev writes:
>> Look at the patch, it fixes the problem by comparing for equality
>> by FPeq() macros which is used everywhere in geometry calculation.
Tom> Ick. FPeq() is a crock; I'd like to see us get rid of it, not
Tom> spread it even further
> "Tom" == Tom Lane writes:
>>> Yup, fails the same way on an --enable-cassert build of 8.3.7.
And on 8.2.13.
Tom> Do you have a quick test case? I just finished coding up my
Tom> plan-C fix, and I need some test cases ...
Andrew> This is the one I've been using:
This one is simpler
>>>>> "Tom" == Tom Lane writes:
Tom> Andrew Gierth writes:
>> Yup, fails the same way on an --enable-cassert build of 8.3.7.
Tom> Do you have a quick test case? I just finished coding up my
Tom> plan-C fix, and I need some test cases ...
Thi
> "Tom" == Tom Lane writes:
Tom> Yeah, good point. However I think that you could still get a
Tom> failure. The cases where a slot might contain a minimal tuple
Tom> are generally where we are reading out of a tuplestore or
Tom> tuplesort object, and all you have to do to get it to be a
> "Tom" == Tom Lane writes:
>> For example, given some function foo(out a text, out b text) returning
>> setof record, the query select t.a, t from foo() t; follows the
>> sequence of events you describe, but it doesn't fail because
>> slot-> tts_shouldFree is false, so the original minim
> "Tom" == Tom Lane writes:
Tom> What is happening is that ExecProject fetches the Datum value of
Tom> t2.path from a TupleTableSlot that contains a "minimal tuple"
Tom> fetched from the tuplestore associated with the CTE "t". Then,
Tom> it fetches the value of the whole-row variable t2.
> "Bruce" == Bruce Momjian writes:
>> 1) select ... from foo, unnest(foo.bar); -- UNNEST is implicitly LATERAL
[...]
>> It's point (1) that's the killer - without it, unnest() is just a
>> trivial shorthand for stuff that can be done anyway; it doesn't
>> actually add any functionality
>>>>> "Jeff" == Jeff Davis writes:
> On Sat, 2009-03-28 at 11:57 +, Andrew Gierth wrote:
>> The array_agg() does, I believe, match the standard one, at least
>> my reading of the spec doesn't reveal any obvious issues there.
Jeff> I think
> "Bruce" == Bruce Momjian writes:
>> The unnest() implementation is largely unrelated to the standard
>> one, which is impossible to provide without LATERAL.
Bruce> I removed the duplicate item; we can add more details about
Bruce> what additional functionality we need once we get user
> "Martijn" == Martijn van Oosterhout writes:
>> The nature of the problem is this: if gist_box_picksplit doesn't
>> find a good disposition on the first try, then it tries to split
>> the data again based on the positions of the box centers. But
>> there's a problem here with floating-po
> "Jaime" == Jaime Casanova writes:
Jaime> In the TODO list there is an item "[D] Completed itemAdd
Jaime> array_agg() and UNNEST functions for arrays " marked as done
Jaime> but 5 items below there is: "Add SQL-standard array_agg() and
Jaime> unnest() array functions " it's the same item
>>>>> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> GET DIAGNOSTICS ROW_COUNT is documented as working for all commands;
>> if it doesn't work for MOVE (and FETCH), that's a bug.
Tom> Or a documentation problem. I don't s
> "Bruce" == Bruce Momjian writes:
>> hi all,
>>
>> I read the code that it seems easy for the cursor in plpgsql to
>> return ROW_COUNT after MOVE LAST etc. The SPI_processed variable
>> already there, but didn't put it into estate structure, any reason
>> for that?
>>
>> thanks and
> "Guillaume" == Guillaume Smet writes:
Guillaume> - "While semi-joins merely replace existing IN joins,
Guillaume> anti-joins are a new capability for NOT IN and NOT EXIST
Guillaume> clauses (Tom) This improves optimization possibilities."
Guillaume> -> remove the "(Tom)", s/EXIST/EXISTS
A user on IRC reported a crash (backend segfault) in GiST insertion
(in 8.3.5 but I can reproduce this in today's HEAD) that turns out
to be due to misbehaviour of gist_box_picksplit.
The nature of the problem is this: if gist_box_picksplit doesn't find
a good disposition on the first try, then it
> "Tom" == Tom Lane writes:
Tom> BTW ... while I'm thinking about it: it seems to me to be a
Tom> serious error that the consistent() function isn't given nkeys
Tom> so that it can know the length of the arrays it's being handed.
Tom> I suppose it's possible for it to re-deduce nkeys by e
>>>>> "David" == "David E Wheeler" writes:
> On Mar 24, 2009, at 2:51 PM, Andrew Gierth wrote:
>> By popular demand, a version of this will go up on pgfoundry for
>> use with 8.3 etc.
David> Wow. Nice stuff! I hope it's not too lat
> "Sam" == Sam Mason writes:
Sam> Hi,
Sam> I had an idea while going home last night and still can't think
Sam> why it's not implemented already as it seems obvious.
[snip idea about WAL fsyncs]
Unless I'm badly misunderstanding you, I think it already has (long
ago).
Only the holder of
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> - many new functions and operators:
Andrew> hstore = hstore returns hstore (equality)
Andrew> hstore <> hstore returns hstore (inequality)
Of course those should be
hstor
Patch attached, also available at
http://www.rhodiumtoad.org.uk/junk/hstore_20090324.patch.txt
The user-visible changes are:
- removal of previous 65535-byte limit on keys/values; both keys and
values can now be as long as desired, within the 1GB limit for the
whole hstore value (though
> "Tom" == Tom Lane writes:
Tom> I think the way most people are envisioning this is that a
Tom> module is a set of SQL objects (functions, types, tables,
Tom> whatever). Whether any of those are C functions in one or more
Tom> underlying .so files is not really particularly relevant to
> "Tom" == Tom Lane writes:
Tom> I doubt that we want to decorate every CREATE statement we've
Tom> got with an optional MODULE clause; to name just one objection,
Tom> it'd probably be impossible to do so without making MODULE a
Tom> fully reserved word.
Tom> What was discussed in the
> "Dimitri" == Dimitri Fontaine writes:
Dimitri> Hi,
Dimitri> Heard about http://wiki.postgresql.org/wiki/ExtensionPackaging ? :)
Yes, I left a short note on its discussion page a while ago :-)
--
Andrew.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
> "Dimitri" == Dimitri Fontaine writes:
>> Partly that's based on the relative inflexibility of the
>> search_path setting; it's hard to modify the search_path without
>> completely replacing it, so knowledge of the "default" search path
>> ends up being propagated to a lot of places.
D
> "Alvaro" == Alvaro Herrera writes:
>> I've been thinking about this, and my conclusion is that schemas
>> as they currently exist are the wrong tool for making
>> modules/packages.
Alvaro> This has been discussed at length previously, and we even had
Alvaro> an incomplete but substant
> "Robert" == Robert Haas writes:
>> I'm hesitant to do that when we don't yet have either a design or
>> a migration plan for the module facility. We might find we'd shot
>> ourselves in the foot, or at least complicated the migration
>> situation unduly.
Robert> I think there have be
> "Tom" == Tom Lane writes:
> Robert Treat writes:
>> We've been talking about this magical "proper module facility" for
>> a few releases now... are we still opposed to putting contrib
>> modules in thier own schema?
Tom> I'm hesitant to do that when we don't yet have either a design
> "Tom" == Tom Lane writes:
Tom> I agree that this wasn't an amazingly good choice, but I think
Tom> there's no real risk of name collisions because fmgr only
Tom> searches for such names within the particular .so.
>> Oh, if only life were so simple.
Tom> I think you are missing the po
> "Tom" == Tom Lane writes:
Tom> I agree that this wasn't an amazingly good choice, but I think
Tom> there's no real risk of name collisions because fmgr only
Tom> searches for such names within the particular .so.
Oh, if only life were so simple.
Consider two modules mod1 (source files
>>>>> "Simon" == Simon Riggs writes:
> On Sat, 2009-03-21 at 01:57 +, Andrew Gierth wrote:
>> Note that I'm talking here about the names of the C functions, not
>> the SQL names.
>>
>> The existing hstore has some very dubious ch
Note that I'm talking here about the names of the C functions, not
the SQL names.
The existing hstore has some very dubious choices of function names
(for non-static functions) in the C code; functions like each(),
delete(), fetchval(), defined(), tconvert(), etc. which all look to me
like prime c
> "Josh" == Josh Berkus writes:
> Tom Lane wrote:
>> Josh Berkus writes:
>>> As an hstore user, I'd be fine with simply limiting it to 64K (or,
>>> heck, 8K) and throwing an error. I'd also be fine with limiting
>>> keys to 255 bytes, although we'd have to warn people.
>> Yeah, 255 mi
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> I have a patch almost done that adds some obvious but
Andrew> currently missing functionality to hstore, specifically the
Andrew> ability to construct an hstore from a record, and the ability
Andrew> t
> "Ron" == Ron Mayer writes:
Ron> Currently hstore gives me an indexed operator to query if a
Ron> hstore contains a single key. It'd be nice if there were as way
Ron> to extend this so that I could ask for only records that have
Ron> all or any the keys in a query.
Ron> 'a=>1, b=>1'
This is just the fix for hstore's silent truncation, including
doc patch and regression test. Actual new functionality will
follow later in another patch.
--
Andrew.
Index: contrib/hstore/hstore.h
===
RCS file: /projects/cvsroot/pgs
> "David" == "David E Wheeler" writes:
>> select ('a=>1,b=>2,c=>3'::hstore) -> ARRAY['a','b'];
>> -- returns '{1,2}'
>>
>> select ('a=>1,b=>2,c=>3'::hstore) => ARRAY['a','b'];
>> -- returns 'a=>1,b=>2'
>>
>> (by analogy to the existing operators -> for lookup and => for
>> construct
> "Tom" == Tom Lane writes:
Tom> As for truncation rather than throwing an error, I'd argue that
Tom> that's a flat-out bug and the fix deserves back-patching.
Separate patch for that part then?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
>>>>> "David" == "David E Wheeler" writes:
> On Mar 13, 2009, at 11:06 AM, Andrew Gierth wrote:
>> If there's any other features that people find notably missing
>> from hstore, I could stick them in too; any requests?
David> Can y
I have a patch almost done that adds some obvious but currently
missing functionality to hstore, specifically the ability to construct
an hstore from a record, and the ability to construct one from a pair
of arrays.
If there's any other features that people find notably missing from
hstore, I coul
> "Joshua" == Joshua D Drake writes:
> On Tue, 2009-03-10 at 15:02 +, Simon Riggs wrote:
>> Yeh Andrew said. That I never noticed in the last 3+ years makes
>> me think there's not many people using it...
The fact that it never got beyond an early incomplete alpha version is
a big fac
> "Simon" == Simon Riggs writes:
>> Now, of course, counting the upcoming 8.4 there have been three
>> (and a bit - the original design predates 8.1, though it did
>> anticipate some 8.1 features) new releases against which the
>> original concept can be tested. And, guess what, nothing i
Some of this behaviour (the plpgsql stuff) could be considered a bug,
but given the differences between pg's behaviour and the spec, the
expected behaviour probably needs to be thrashed out first (which is
why I didn't post this directly to -bugs).
Given (in 8.3.6):
create type ftype as (a intege
> "Tom" == Tom Lane writes:
> Magnus Hagander writes:
>> I think this sounds a lot like another request for a set of system
>> views with nicer names.
Tom> What's the state of the newsysviews project, anyway? I don't
Tom> recall hearing much about it lately.
At the time it was propos
> "Albe" == Albe Laurenz writes:
Albe> I *guess* it is the problem addressed by
Albe> http://archives.postgresql.org/pgsql-committers/2008-04/msg00275.php
Albe> and
Albe> http://archives.postgresql.org/pgsql-committers/2008-04/msg00358.php
No; the problem is with stop -mimmediate (not -
> "Alvaro" == Alvaro Herrera writes:
Alvaro> Is errdetail not printed when verbosity = terse?
No, it's not.
--
Andrew.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> "Tom" == Tom Lane writes:
>> I propose that this behaviour be changed such that 'terse' is
>> ignored for all log messages of FATAL or PANIC severity.
>> [ on the strength of a single example ]
Tom> This seems like using a blunderbuss where a rifle is called for.
Maybe so.
Tom> Ther
Currently setting "log_error_verbosity = terse" causes all HINT output
to the log file to be suppressed (along with some other stuff).
I propose that this behaviour be changed such that 'terse' is ignored
for all log messages of FATAL or PANIC severity.
The main reason for this is messages like (
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> I get a segfault too if I force misc/ossp-uuid to build with
Andrew> -fPIC:
[...]
Andrew> I can try this on another box with a debug-enabled pg build
Andrew> later.
The problem, unsurprisingly, is that th
>>>>> "Peter" == Peter Eisentraut writes:
> Andrew Gierth wrote:
>> Has anyone ever managed to get uuid generation working on FreeBSD?
>> There seems to be no way to build contrib/uuid-ossp successfully,
>> and no apparent agreement anywhere as
Has anyone ever managed to get uuid generation working on FreeBSD?
There seems to be no way to build contrib/uuid-ossp successfully,
and no apparent agreement anywhere as to whether this is problem
with pg or with the misc/ossp-uuid port.
(I tried this, without success, a couple of weeks back in r
>>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
> Andrew Gierth <[EMAIL PROTECTED]> writes:
>> Obviously, this happens because the locale support functions in
>> backend/regex/regc_locale.c are (presumably intentionally)
>> crip
This came up on irc:
postgres=# show lc_ctype;
lc_ctype
-
fr_FR.UTF-8
postgres=# show server_encoding;
server_encoding
-
UTF8
(1 row)
postgres=# select E'\303\201' ILIKE E'\303\241';
?column?
--
t
(1 row)
postgres=# select E'\303\201' ~* E'\303\
While waiting for a large restore to complete (and investigating why
parts of it were so slow), I came across this scenario. This isn't
quite the same as some previous discussion of hint bits, but I thought
it was something that could probably be taken into account in future.
This also may be relev
> "Alvaro" == Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> so it's like this:
>>
>> select * from foo order by bar offset 5 rows fetch first 10 rows only;
Alvaro> Oh, I see -- it's just a cumbersome way to have our LIMIT
Alvaro> clause. What's the "ONLY" for?
It seems to be just a ma
> "Jeff" == Jeff Davis <[EMAIL PROTECTED]> writes:
Jeff> I am looking into the SQL standard to try to determine
Jeff> precisely how the CTE feature should behave.
Jeff> Taking a simple case like:
Jeff> with recursive
Jeff> foo(i) as
Jeff> (values(1)
Jeff> union all
> "Jeff" == Jeff Davis <[EMAIL PROTECTED]> writes:
Jeff> Aggregates should be blocked according to the standard.
Jeff> Also, causes an infinite loop. This should be fixed for 8.4.
>> Does the standard require anywhere that non-conforming statements
>> must be diagnosed? (seems impractical
> "Jeff" == Jeff Davis <[EMAIL PROTECTED]> writes:
Jeff> * Mutual Recursion:
This limitation isn't at all uncommon in other implementations; DB2
docs for example say:
"If more than one common table expression is defined in the same
statement, cyclic references between the common table expre
> "Alvaro" == Alvaro Herrera <[EMAIL PROTECTED]> writes:
Alvaro> Wow, this is really horrid:
Alvaro> # F856 through F859: FETCH FIRST clause in subqueries,
Alvaro> views, and query expressions. The SQL:2008 syntax for
Alvaro> restricting the rows of a result set is FETCH FIRST, rather
>>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
>> Andrew Gierth wrote:
>>> 2. The server accepts either the old-style or the secure cancel
>>> request from the client, but doesn't allow old-style requests
>>> once a va
> "Magnus" == Magnus Hagander <[EMAIL PROTECTED]> writes:
[snip]
I'm looking (at Magnus' suggestion) at implementing this.
There appears to be only one significant obstacle; since the query
cancel message is received _after_ forking a new backend, there has to
be some mechanism for recordin
> "Decibel" == Decibel! <[EMAIL PROTECTED]> writes:
Decibel> OK, ran the test again via this query:
Decibel> explain analyze select (select value from oneblock where id = i)
Decibel> from generate_series(1,1) i, generate_series(1,10) j;
Decibel> changing 1,1 to 200,200 as needed. I
> "Decibel!" == Decibel! <[EMAIL PROTECTED]> writes:
Decibel> Roughly what I get on my MBP (I'm about a factor of 2
Decibel> slower). This makes me think it's an issue of having to slog
Decibel> through an entire page one row at a time vs just using the
Decibel> index. To test this I test
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
>> Proposal: Make the first block of a seq scan cost
>> random_page_cost, then after that every additional block costs
>> seq_page_cost.
Tom> This is only going to matter for a table of 1 block (or at least
Tom> very few blocks), and for su
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> I wonder if we can do something diffie-hellman'ish, where we have
>> a parameter exchanged in the initial SSL'ed handshake, which is
>> later used to generate new cancel keys each time the previ
> "Merlin" == "Merlin Moncure" <[EMAIL PROTECTED]> writes:
Merlin> postgres=# alter table abc alter a type numeric;
Merlin> ALTER TABLE
Merlin> Time: 254.847 ms
Merlin> postgres=# EXECUTE ins_abc;
Merlin> INSERT 0 1
Merlin> Time: 0.452 ms
Merlin> postgres=# select * from abc;
Merlin> E
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
>> Tom, could you please elaborate where you see a security hole?
Tom> The problem that we've seen in the past shows up when the user
Tom> lies in the CREATE TYPE command, specifying type representation
Tom> properties that are different fro
> "Tatsuo" == Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> At David's request I've been looking through this patch.
>>
>> Regarding documentation: if it would help, I can write some; I
>> have already made a start on writing down what is going on
>> internally in order to understand it my
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
>> Since the problem is using the result of a WITH clause more than
>> once, would it be sufficient to simply detect that case and bail?
>> You don't want materialisation is most cases, the
> "Gregory" == Gregory Stark <[EMAIL PROTECTED]> writes:
Gregory> I just wonder where all these examples of real-world queries
Gregory> were when I posted this patch and asked for such feedback
Gregory> originally. sigh.
Gregory> In any case I think we've already made this decision. If we
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> We are not in the business of getting spec-required semantics
Tom> 80% right;
I guess that's why we still fold identifiers to lowercase, why our
timestamp implementation differs from the standard, why we used to
require AS for select-list
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
[snip spec]
Just out of curiosity, since I don't have a copy of the spec handy, how
does the language for WITH compare to that for views?
Tom> I think this is a "must fix" because of the point about volatile
Tom> functions --- changing it la
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
>> I think it needs this change in addition; without it, incorrect
>> results are returned when you reference a recursive view from
>> within the recursive query, due to the RecursionScan nodes
>> becoming linked to the wrong tuplestores.
T
> "Tatsuo" == Tatsuo Ishii <[EMAIL PROTECTED]> writes:
Tatsuo> Included patches from Yoshiyuki should fix 1) and 2). I also
Tatsuo> add your SQLs to the regression test. Thanks.
I think it needs this change in addition; without it, incorrect
results are returned when you reference a recursi
> "Tatsuo" == Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> This behaviour is clearly intentional, since the entire mechanism of
>> estate-> es_disallow_tuplestore exists for no other reason, but it
>> seems to me to be clearly wrong. What is the justification for it?
Tatsuo> Yes, this is d
At David's request I've been looking through this patch.
Regarding documentation: if it would help, I can write some; I have
already made a start on writing down what is going on internally in
order to understand it myself.
I've found three more bugs so far:
1)
create view v2(id) as values (1);
While trying to construct testcases for a patch, I ran into this:
execAmi.c has a function ExecMayReturnRawTuples which indicates whether
a given plan might return tuples that come straight from a table rather
than having been projected.
InitPlan() uses this to force the addition of a junk filter
401 - 494 of 494 matches
Mail list logo
