Konstantin Knizhnik writes:
> On 03/08/2016 07:01 AM, Tom Lane wrote:
>> I've not spent a lot of time on this, but I think maybe what would make
>> sense is to consider both the case where function calculations are
>> postponed to after ORDER BY and the case where
OSE mode. That's
probably fine. Never mind
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
necessary recalculations of the type's tupdesc. It means one
extra hashtable lookup per reference, but that's not that awful.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-scan-join steps.
See 51c0f63e4d76a86b44e87876a6addcfffb01ec28 --- I think this gets
things to where we could plug in additional levels of targets without
too much complication.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
just because those are less
common path types. But getting rid of the behavior entirely would be
a lot of work, and I'm not convinced it'd be an improvement.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
for many other cases. I
> think this approach will also resolve the issue but haven't tried yet.
I think this is the correct fix.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
too hard. The workaround is to do an update on pg_enum
> directly, but proper SQL support would be much nicer.
I have a vague recollection that we discussed this at the time the enum
stuff went in, and there are concurrency issues? Don't recall details
though.
x27;re not
toastable or compressable, they certainly won't exceed BLCKSZ.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
divides is good. It might happen to work
conveniently on your machine, but I wouldn't think it's portable.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan writes:
> On 03/09/2016 11:07 AM, Tom Lane wrote:
>> I have a vague recollection that we discussed this at the time the enum
>> stuff went in, and there are concurrency issues? Don't recall details
>> though.
> Rings a vague bell, but should it be any
Alvaro Herrera writes:
> Tom Lane wrote:
>> Yeah, fixed. I had assumed that the existing coding in create_gather_plan
>> was OK, because it looked like it was right for a non-projecting node.
>> But actually Gather can project (why though?), so it's not right.
>
't really see anything that this patch does that wouldn't be better
done that way. And I'd kind of like to get a working example of that type
of path insertion into 9.6, so that we can find out if we need any hooks
or callbacks that aren't there today.
Robert Haas writes:
> On Wed, Mar 9, 2016 at 1:12 PM, Tom Lane wrote:
>> I hadn't been paying any attention to this thread, but I wonder whether
>> this entire approach isn't considerably inferior to what we can do now
>> with the planner pathification patch. To q
atch
approach in particular? Want to bikeshed the specific
when-to-postpone-eval policies implemented here? Other comments?
regards, tom lane
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 8937e71..b15fca1 100644
***
re right: pstrdup in that context is a useless waste of cycles and
memory.
A quick grep in the current PG sources shows me only two occurrences of
the former, both in the same function and both doubtless introduced by
the same misinformed author. I find no occurrences of the latter.
ticular plan to do that. It's not like leaving
that code in place is costing us huge amounts of maintenance effort.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
ta replace them all with an "int flags" field.
That's probably material for a separate patch though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e sources.sgml)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
should not use.
I think what we need is configure logic to find out where wcstombs_l()
is declared, and then #include only if it's necessary to get
that definition. I haven't experimented but probably you could make such
a check with nested uses of AC_CHECK_DECL.
reg
, which will exist
fractionally longer than the postmaster, and thus might be trying to write
into the file after the postmaster has removed it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
problems if one plpython
function calls another (presumably via SPI)?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ERROR?
libpq/psql seem to more or less survive this situation:
regression=# set client_min_messages to fatal;
SET
regression=# select 2/0;
regression=# select 1;
?column?
--
1
(1 row)
but it doesn't really seem like a great idea.
regards, tom l
set_returning_function_1(...), set_returning_function_2(...);
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d change the environment for called functions too).
So for now, the recommendation has to be "write functions you want
to inline with schema qualifications". If you're worried about
preserving relocatability of an extension containing such functions,
the @extschema@ feature migh
by q1 limit 7;
q1 | generate_series
-+-
123 | 2
123 | 3
123 | 4
123 | 5
123 | 6
123 | 7
123 | 1
(7 rows)
I think that's pretty surprising, and if we have an opportuni
able. But it won't affect other functions as they no
> longer need to invoke any Python code.
Well, if you think that works, why not undo the global-dictionary changes
at the end of the first call, rather than later? Then there's certainly
no overlap in their lifespan.
t we'll
need to make another change in pull_var_clause in the foreseeable future.
I'm undecided which way to fix it. Anybody else have an opinion?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
these functions?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund writes:
> On 2016-03-10 13:48:31 -0500, Tom Lane wrote:
>> That was intentional: in my opinion, nothing outside createplan.c ought
>> to be making Plan nodes anymore. The expectation is that you make a
>> Path describing what you want. Can you explain wh
Andres Freund writes:
> On 2016-03-10 14:16:03 -0500, Tom Lane wrote:
>> I don't deny that you *could* continue to do things that way, but
>> I dispute that it's a good idea. Why can't you generate a Path tree
>> and then ask create_plan() to convert it?
&g
Gilles Darold writes:
> Then, should I have to use an alternate file to store the information or
> implement a bidirectional communication with the syslogger?
I'd just define a new single-purpose file $PGDATA/log_file_name
or some such.
regards, tom lane
-
it'd be really painful to do any complicated
joins. I think there may be a function to explicitly flush the cache,
if you really need to see intratransaction changes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
123 | 2
123 | 3
123 | 4
123 | 5
123 | 6
123 | 7
(7 rows)
I added some user-facing documentation too. I think this is committable,
though maybe we should add a regression test case or two.
Andres Freund writes:
> On 2016-03-10 15:03:41 -0500, Tom Lane wrote:
>> What it encourages is having module boundaries that actually mean
>> something, as well as code that can be refactored without having
>> to worry about which extensions will complain about it.
>
g out that it's a conceivable future feature.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
have this same issue. For
another, it might be version-specific, or might become so if FreeBSD
decides to start following POSIX on this point someday.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
e against it. I see that Alex
himself accepted that argument in his last message in the thread
().
So let's mark it rejected and move on.
> unexpected PQresultStatus: 8
It is a bit annoying that psql doesn't print "COPY_BOTH" here.
But fixing that is not this patch, either.
with Robert to reject this patch.
BTW, the context for the original report wasn't clear, but I wonder how
much of the actual problem could be addressed by teaching make_date()
and friends to accept negative year values as meaning BC.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
resql.org/docs/devel/static/error-style-guide.html
These seem to have multiple problems, starting with incorrect
capitalization and extending to failure to quote the whole string
being complained of.
In short, though, +1 for improving this stuff.
regards, tom lane
--
;d be well
advised to boot it to the 2016-09 CF and focus our efforts on other stuff
that has a better chance of getting finished this month.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ngs in
the executor and EXPLAIN. I'm not very enamored of plastering this
"match_first_tuple_only" flag on every join, in part because it doesn't
appear to have sensible semantics for other jointypes such as JOIN_RIGHT.
And I'd really be happier to see the information refle
g that in the SpecialJoinInfos, which is probably
fine. But for INNER joins it looks like you're just doing it over again
for every candidate join, and that seems mighty expensive.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers
r than just averting our eyes. The
use of int64 data isn't decreasing as time goes on.
These are small enough changes that there's no need for a new patch
submission. I'll take it from here, unless I find bigger issues.
regards, tom lane
--
Sent via
Anybody know what will happen when passing a uint64 to newSViv()?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
> Anybody know what will happen when passing a uint64 to newSViv()?
Oh, and how about Python's PyInt_FromLong()?
Or PyList_New()?
Or the second argument of PyList_SetItem()?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
empts to pass uint64 values (from SPI_processed)
into language-specific functions. We need to figure out whether
that will overflow and whether it's worth doing something about.
3. This patch still needs a lot of review as I may have missed
something.
So I'm bouncing this back to Wait
re how much that would affect semantics in typical
Perl code.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
on for the purposes we plan to put it to.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier writes:
> On Fri, Mar 11, 2016 at 9:35 PM, Tom Lane wrote:
>> IMO this is not committable as-is, and I don't think that it's something
>> that will become committable during this 'fest. I think we'd be well
>> advised to boot it to the
those things are hot spots in
most workloads. Do you have any evidence demonstrating that this
doesn't cause a performance hit?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
David Rowley writes:
> On 12 March 2016 at 11:43, Tom Lane wrote:
>>> I wondered why, instead of inventing an extra semantics-modifying flag,
>>> we couldn't just change the jointype to *be* JOIN_SEMI when we've
>>> discovered that the inner side is unique
=?UTF-8?Q?Salvador_Fandi=c3=b1o?= writes:
> On 03/12/2016 04:47 PM, Tom Lane wrote:
>> How much of a user-visible change would that be, if the "processed"
>> field of a spi_exec_query() result started coming back as an NV not
>> an IV? I'm not sure how much th
Andres Freund writes:
> On 2016-03-10 23:38:14 -0500, Tom Lane wrote:
>> I'll do it ... just send me the list.
> After exporting make_agg, make_limit, make_sort_from_sortclauses and
> making some trivial adjustments due to the pull_var_clause changes
> change, Citus'
#x27;s
suggestion of inventing two new join-type codes rather than overloading
JOIN_SEMI. I'd still be a bit inclined to display JOIN_INNER_UNIQUE or
whatever we call it as a "Semi" join in EXPLAIN, though, just to minimize
the amount of newness there.
regards,
hty ugly too.
In short: we've already been over this territory, at length,
and I am not excited by people trying to bikeshed it again
after the fact, especially when no new arguments are being
presented. Can we call the discussion closed, please?
regards, tom lan
Petr Jelinek writes:
> On 12/03/16 04:30, Tom Lane wrote:
>> 1. I found two places (marked XXX in this patch) that are using strtoul()
>> to parse a tuple count back out of a command tag. That won't do anymore.
>> pg_stat_statements has a messy hack for
ed this so we can get some buildfarm testing, but it wouldn't
be a bad idea for someone to review the committed patch. Chasing all
the dependencies was tedious and I'm still not real sure I found them
all.
regards, tom lane
--
Sent via pgsql-hackers maili
-fno-common". It is truly sad that we apparently have no test
machine that enforces that const means const ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
lect2: ld returned 1 exit status
Any thoughts how to fix that?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund writes:
> On 2016-03-12 12:22:01 -0500, Tom Lane wrote:
>> I wonder whether that's pathification per se.
> If you're interested enough, I've uploaded a dump of the schema relevant
> table to http://anarazel.de/t/lineitem_95_96_plan.dump.gz
I haven&#x
Petr Jelinek writes:
> On 13/03/16 03:30, Tom Lane wrote:
>> Per a comment from Petr Jelinek, I added this in commit 23a27b039d94ba35:
>>
>> #ifdef WIN32
>> return _strtoui64(str, endptr, base);
>> #else ...
>>
>> Several of the Windows buildfarm
Petr Jelinek writes:
> On 13/03/16 04:24, Tom Lane wrote:
>> So you're thinking "#ifdef _MSC_VER"? Or something else?
> Sorry for brevity, yes, that should work, afaics mingw has strtoul so
> the code should compile fine with that ifdef. Also just checked to ma
not familiar enough with this code
to decide what's the best way to do that. (Basically, the question is
"how much of startScanEntry() ought to run with keyCtx as current memory
context?") As a short-term fix I plan to reinstall the above-cited pfree.
rega
then bypass this check for such FDWs?
I'm not really sold on enforcing that people create meaningless user
mappings. For one thing, they're likely to be sloppy about it, which
could lead to latent security problems if the FDW later acquires a
concept that user mappings mean something.
Jim Nasby writes:
> All issues should now be addressed.
Pushed with some more tweaking: the test syntax wasn't terribly portable,
and the error messages weren't at all consistent.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
ire is "get the type of field 'foo' of this
composite type". I don't suggest that this patch needs to implement
that right now; but it would be a good thing if we could see how the
chosen syntax could be extended in such a direction. Otherwise we might
be painting ourselve
fancy to where we are today, we have
%TYPE as a remarkably ugly and limited implementation of TYPE_OF(),
and we have the precedent that foo[] means ARRAY_OF(foo). I'm not
sure how we get any extensibility out of either of those things.
Or in short: maybe it's time to blow up %TYPE and s
an
#if PERL_BCDVERSION >= 0x5019004 ?
> 3) To be able to actually return such result sets from sp_exec_query(),
>I had to change the repalloc() in spi_printtup() to repalloc_huge().
Hmm, good point. I wonder if there are any hazards to doing that.
regards, to
Thomas Munro writes:
> I guess pg_stat_get_progress_info should either be strict (see
> attached) or check for NULL.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
t only call it for FDW(s) actively involved
in the query. I'm not sure exactly what that ought to look like though.
Maybe only call the FDW identified as possible owner of the topmost
scan/join relation?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Sun, Mar 13, 2016 at 10:51 PM, Tom Lane wrote:
>> I'm not really sold on enforcing that people create meaningless user
>> mappings. For one thing, they're likely to be sloppy about it, which
>> could lead to latent security probl
Robert Haas writes:
> On Mon, Mar 14, 2016 at 1:04 PM, Tom Lane wrote:
>> It would be better if we invent an FDW callback that's meant to be
>> invoked at this stage, but only call it for FDW(s) actively involved
>> in the query. I'm not sure exactly what
Robert Haas writes:
> On Mon, Mar 14, 2016 at 1:37 PM, Tom Lane wrote:
>> Yeah. An alternative definition that would support that would be to
>> call the upper-path-providing callback for each FDW that's responsible
>> for any base relation of the query. But I t
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Tom Lane writes:
>> I thought about using UV where feasible, but it was not clear to me
>> whether unsigned numbers behave semantically differently from signed ones
>> in Perl. If they do, the change you
ion has
> been documented since 5.16, and 5.6 is no longer supported. The
> attached patch updates the comment to reflect this.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
he PGresult. That would eat a little more space but not much.
Then we just need to add API to let the application get at both forms.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ar 28 for public announcement on Thursday
Mar 31st.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Mon, Mar 14, 2016 at 12:04 PM, Tom Lane wrote:
>> Or in short: maybe it's time to blow up %TYPE and start fresh.
> That's not a dumb idea. I think %TYPE is an Oracle-ism, and it
> doesn't seem to have been their best-ever design decision
Robert Haas writes:
> On Mon, Mar 14, 2016 at 1:37 PM, Tom Lane wrote:
>> Yeah. An alternative definition that would support that would be to
>> call the upper-path-providing callback for each FDW that's responsible
>> for any base relation of the query. But I t
rser
has an implementation, and plpgsql has its own not-entirely-compatible
one. (And one thing I especially don't like about the submitted patch is
that it makes those two diverge even further.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
onable to expect extensions to update to the newer
behavior in a major release, but we're taking risks if we expect
that to happen in minor releases.
In any case, we need a patch that touches the backend-side code as well.
regards, tom lane
--
Sent via pgsql-hacke
Peter Geoghegan writes:
> On Mon, Mar 14, 2016 at 3:06 PM, Tom Lane wrote:
>> Agreed, we need to deal with this one way or the other. My proposal
>> is:
>>
>> 1. In HEAD, do it as Peter E. suggests, ie clear error queue before calls.
>>
>> 2. In back
Ioseph Kim writes:
> I want see that value of bind variable at a server log.
That's available if you turn on log_statements, IIRC.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
hanges like these. We make a point
of generating our configure using unmodified GNU autoconf installations,
so as to avoid dependencies on which platform a committer was using to
run autoconf.
regards, tom lane
diff --git a/config/c-library.m4 b/config/c-library.m4
index
at is
going to require some other syntax than this. As I said, I'm not
particularly pushing the function-like syntax I wrote upthread; but
I want to see something that is capable of supporting all those features
and can be extended later if we think of other type operators we want.
desirability of this function IMO.
I've also gone from "don't care" to "-1".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Wed, Mar 16, 2016 at 2:47 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Mon, Mar 14, 2016 at 9:21 PM, Kouhei Kaigai wrote:
>>>> So, even though we don't need to define multiple hook declarations,
>>>> I
today, I'm definitely planning to do it for psql's lexer,
since I'm messing with that right now, and I don't much like
Horiguchi-san's solution to the problem.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
ntences no longer agree as to
person is on-point.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s
> {DATE|TIMESTAMP}_END_JULIAN use "1" as month?
Because we're intentionally allowing a wider range for IS_VALID_JULIAN
than for IS_VALID_DATE/TIMESTAMP.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
t is strange ... unless maybe cmake is supplying a different set
of warning-enabling switches to the compiler?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Wed, Mar 16, 2016 at 2:05 PM, Tom Lane wrote:
>> Possible compromise: remove files only in non-Assert builds?
> That sorta seems like tying two things together that aren't obviously
> related. I think building with --enable-cassert is support t
se-case for that. What external
thing is likely to handle window functions but not aggregation,
for example?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
negative inputs. It isn't. Nobody sees this with inputs
after 4714BC, but when probing in 4714 the code considers the
reference point 4714-01-04, which has a negative Julian date and so
we end up passing a negative date to j2day().
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t timestamptz is the preferred type in this hierarchy isn't
really doing us any favors here.)
regards, tom lane
[1] http://www.postgresql.org/docs/devel/static/typeconv-func.html
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Wed, Mar 16, 2016 at 12:57 PM, Tom Lane wrote:
>> Yeah, I was thinking about the same thing. The comment block above
>> where you're looking would need some adjustment.
> OK, how about this?
Looks pretty close. One point is that if we do end
gh that it would break quite a number of
the proposed new regression tests for the float case. TBH, I thought
the number of added test cases was rather excessive anyway, so I wouldn't
have a problem with just leaving out whichever ones don't pass with both
build options.
Comments?
#x27;ve found so far is "-M prepared" not
working. And it's been there since -C was invented, AFAICT. The fact
that the bug went undetected this long says a lot about the amount of
real-world use the switch gets. So I think it's fair to consider whether
we should not eliminate
Robert Haas writes:
> On Thu, Mar 17, 2016 at 2:31 PM, Tom Lane wrote:
>> Also, I don't particularly see a need for a corresponding API for FDWs.
>> If an FDW is going to do anything in this space, it presumably has to
>> build up ForeignPaths for all the steps anyway.
t; because:
Possible compromise: remove files only in non-Assert builds?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
101 - 200 of 48047 matches
Mail list logo
