> "Joe" == Joe Conway writes:
> On 6/6/23 15:55, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Jun 6, 2023 at 3:25 PM Tom Lane wrote:
Also +1, except that I find "none" a rather confusing choice of name.
There *is* a provider, it's just PG itself not either libc or ICU.
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> I thought they used CREATE RULE on a table?
Andrew> In fact here is an example from a pg 9.5 pg_dump output (with
Andrew> cruft removed):
And checking other versions, 9.6 is the same, it's only with pg 10 th
> "Tom" == Tom Lane writes:
Tom> Now, this is certainly syntax that's deprecated in favor of using
Tom> CREATE OR REPLACE VIEW, but I'm very hesitant to remove it. ISTR
Tom> that ancient pg_dump files used it in cases involving circular
Tom> dependencies.
I thought they used CREATE RULE
> "Jeff" == Jeff Davis writes:
>> Is that the right fix, though? (It forces --locale-provider=libc for
>> the cluster default, which might not be desirable?)
Jeff> For the "no locale" behavior (memcmp()-based) the provider needs
Jeff> to be libc. Do you see an alternative?
Can
> "Jeff" == Jeff Davis writes:
>> Also, somewhere along the line someone broke initdb --no-locale,
>> which should result in C locale being the default everywhere, but
>> when I just tested it it picked 'en' for an ICU locale, which is not
>> the right thing.
Jeff> Fixed, thank you.
> "Tom" == Tom Lane writes:
>> Also, somewhere along the line someone broke initdb --no-locale,
>> which should result in C locale being the default everywhere, but
>> when I just tested it it picked 'en' for an ICU locale, which is not
>> the right thing.
Tom> Confirmed:
Tom> $
> "Peter" == Peter Eisentraut writes:
Peter> If the database is created with locale provider ICU, then
Peter> lc_collate does not apply here,
Having lc_collate return a value which is silently being ignored seems
to me rather hugely confusing.
Also, somewhere along the line someone broke
> "David" == David Rowley writes:
David> I think the mistake is that the header file is not in
David> src/include/common. For some reason, it's ended up with all the
David> .c files in src/common.
David> I imagine Andrew did this because he didn't ever expect anything
David> else to
> "Andrew" == Andrew Dunstan writes:
Andrew> I'd be curious to know how this state came about.
Me too, but available information is fairly sparse: PG 12.5, in a
container, backing a (personal) instance of Gitlab; the only database
admin operations should have been those done by Gitlab
[warning, reviving a thread from 2018]
> "Andrew" == Andrew Dunstan writes:
> On Wed, Feb 21, 2018 at 7:48 PM, Andres Freund wrote:
>> Hi,
Andrew> Comments interspersed.
>>> @@ -4059,10 +4142,6 @@ AttrDefaultFetch(Relation relation)
>>>
>>> systable_endscan(adscan);
>>>
ExecBuildAggTrans has this sequence:
if (pertrans->deserialfn.fn_strict)
scratch.opcode = EEOP_AGG_STRICT_DESERIALIZE;
else
scratch.opcode = EEOP_AGG_DESERIALIZE;
scratch.d.agg_deserialize.fcinfo_data =
> "Tom" == Tom Lane writes:
>> I guess that's close enough; this should suffice then.
Tom> Looks about right. Not sure if we need to bother with a regression
Tom> test case; once that's in, it'd be hard to break it.
We could check the EXPLAIN output (since the Materialize node would
> "Tom" == Tom Lane writes:
Tom> Oh, sorry, I misread your comment to be that you wanted to add a
Tom> field to IndexAmRoutine. You're right, the real issue here is that
Tom> ExecSupportsMarkRestore lacks any convenient access to the needed
Tom> info, and we need to add a bool to
> "Tom" == Tom Lane writes:
>> The problem is that the planner calls ExecSupportsMarkRestore to
>> find out whether a Materialize node is needed, and that function
>> looks no further than the Path type of T_Index[Only]Path in order to
>> return true, even though in this case it's a GiST
>From a report by user "kes" on irc, I constructed this test case:
create table marktst (id integer, val numrange, exclude using gist (val with
&&));
insert into marktst select i, numrange(i, i+1, '[)') from
generate_series(1,1000) i;
vacuum marktst;
analyze marktst;
select * from (select val
> "Alexander" == Alexander Korotkov writes:
>> Another issue I don't understand yet is that even though this code
>> is largely unchanged since 8.x, the original reporter could not
>> reproduce the crash on any version before 13.0.
Alexander> I think this is related to my commit
(From a report by user "ftzdomino" on IRC of a segfault while loading
data with a pg_trgm gist index)
If gtrgm_picksplit is invoked on a vector of exactly 2 items (which I
think is rare, but it can happen if gistSplit recurses or I think in
cases of secondary splits), then it tries to access
> "Tom" == Tom Lane writes:
Tom> It's hardly surprising that datumCopy would segfault when given a
Tom> null "value" and told it is pass-by-reference. However, to get to
Tom> the datumCopy call, we must have passed the MemoryContextContains
Tom> check on that very same pointer value, and
> "Tom" == Tom Lane writes:
[...]
Tom> so that a finite value should never map to INT[64]_MIN, making it
Tom> safe to do as you suggest. I agree that distinguishing +Inf from
Tom> NaN is probably more useful than distinguishing it from the very
Tom> largest class of finite values, so
> "Tom" == Tom Lane writes:
Tom> @@ -359,10 +390,14 @@ typedef struct NumericSumAccum
Tom> #define NumericAbbrevGetDatum(X) ((Datum) (X))
Tom> #define DatumGetNumericAbbrev(X) ((int64) (X))
Tom> #define NUMERIC_ABBREV_NAN
NumericAbbrevGetDatum(PG_INT64_MIN)
Tom>
> "Tom" == Tom Lane writes:
Tom> * I'm only about 50% sure that I understand what the sort
Tom> abbreviation code is doing. A quick look from Peter or some other
Tom> expert would be helpful.
That code was originally mine, so I'll look at it.
--
Andrew (irc:RhodiumToad)
> "Ranier" == Ranier Vilela writes:
Ranier> Hi,
Ranier> Latest HEAD, fails with windows regress tests.
Ranier> three | f1 |sqrt_f1
Ranier> ---+--+---
Ranier> | 1004.3 |
> "David" == David Rowley writes:
David> Pending any objections, I'd like to push both of these patches
David> in the next few days to master.
For the second patch, can we take the opportunity to remove the
extraneous blank line at the top of pg_ltoa, and add the two missing
"extern"s in
> "Ranier" == Ranier Vilela writes:
Ranier> Sorry, my mistake.
Ranier> uvalue = (uint64) 0 - value;
This doesn't gain anything over the original, and it has the downside of
hiding an int64 to uint64 conversion that is actually quite sensitive.
For example, it might tempt someone to
> "Ranier" == Ranier Vilela writes:
Ranier> So I would change, just the initialization (var uvalue), even though
it is
Ranier> irrelevant.
Ranier> int
Ranier> pg_lltoa(int64 value, char *a)
Ranier> {
Ranier> int len = 0;
Ranier> uint64 uvalue;
Ranier> if (value < 0)
Ranier> {
> "Ranier" == Ranier Vilela writes:
Ranier> Where " ends up with two copies of pg_ultoa_n inlined into it",
Ranier> in this simplified example?
The two references to sprintf are both inlined copies of your pg_utoa.
Ranier> (b) I call this tail cut, I believe it saves time, for sure.
> "Ranier" == Ranier Vilela writes:
Ranier> Written like that, wouldn't it get better?
Ranier> int
Ranier> pg_lltoa(int64 value, char *a)
Ranier> {
Ranier> if (value < 0)
Ranier> {
Ranier> int len = 0;
Ranier> uint64 uvalue = (uint64) 0 - uvalue;
> "David" == David Rowley writes:
David> This allows us to speed up a few cases. int2vectorout() should
David> be faster and int8out() becomes a bit faster if we get rid of
David> the strdup() call and replace it with a palloc()/memcpy() call.
What about removing the memcpy entirely? I
> "David" == David Rowley writes:
David> As you can see, this squeezes about 5% extra out of a copy of a
David> 10 million row bigint table but costs us almost 3% on an
David> equivalent int table.
And once again I have to issue the reminder: you can have gains or
losses of several
> "Laurenz" == Laurenz Albe writes:
Laurenz> I played with a silly example and got a result that surprises
Laurenz> me:
Laurenz> WITH RECURSIVE fib AS (
Laurenz> SELECT n, "fibₙ"
Laurenz> FROM (VALUES (1, 1::bigint), (2, 1)) AS f(n,"fibₙ")
Laurenz> UNION ALL
> "Alvaro" == Alvaro Herrera writes:
>> This needs to be fixed in ruleutils, IMO, not by changing what the
>> grammar accepts.
Alvaro> Fair. I didn't change what the grammar accepts. I ended up only
Alvaro> throwing an error in parse analysis when a bare NULL const is
Alvaro> seen.
> "Alvaro" == Alvaro Herrera writes:
Alvaro> It turns out that the SQL standard is much more limited in what
Alvaro> it will accept there. But our grammar (what we'll accept for
Alvaro> the ancient LIMIT clause) is very lenient -- it'll take just
Alvaro> any expression. I thought about
> "Justin" == Justin Pryzby writes:
> On Thu, Mar 12, 2020 at 12:16:26PM -0700, Andres Freund wrote:
>> Indeed, that's incorrect. Causes the number of buckets for the
>> hashtable to be set higher - the size is just used for that. I'm a
>> bit wary of changing this in the stable branches
> "Stephen" == Stephen Frost writes:
>> I figure something along these lines for the fix. Anyone in a
>> position to test this?
Stephen> At least at first blush, I tend to agree with your analysis
Stephen> and patch.
Stephen> I'll see about getting this actually set up and tested in
> "Alvaro" == Alvaro Herrera writes:
Alvaro> My own inclination is that Andrew's implementation, being more
Alvaro> general in nature, would be the better one to have in the
Alvaro> codebase; but we don't have a complete patch yet. Can we reach
Alvaro> some compromise such as if Andrew's
> "Surafel" == Surafel Temesgen writes:
Surafel> Unlike most other executor node limit node has implementation
Surafel> for handling backward scan that support cursor operation but
Surafel> your approach didn't do this inherently because it outsource
Surafel> limitNode functionality to
> "Tom" == Tom Lane writes:
> Stephen Frost writes:
>> We already have a reserved namespace when it comes to roles,
>> specifically "pg_".. why invent something new like this '&' prefix
>> when we could just declare that 'pg_superusers' is a role to which
>> all superusers are members?
> "Bruce" == Bruce Momjian writes:
>> This came up recently on IRC, not sure if the report there was
>> passed on at all.
>>
>> ProcessStartupPacket assumes that there will be only one negotiation
>> request for an encrypted connection, but libpq is capable of issuing
>> two: it will
> "Jakob" == Jakob Egger writes:
Jakob> But this also needs to be fixed on the client side as well,
Jakob> otherwise affected clients can't connect to older servers
Jakob> anymore.
There's a workaround, which is to set PGGSSENCMODE=disable on the
client.
It would be far better to avoid
> "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes:
Dmitry> Hi,
Dmitry> Probably a simple question, but I don't see a simple answer so
Dmitry> far. In one extension I want to convert uint64 into a numeric
Dmitry> to put it eventually into a jsonb object. As far as I see in
> "Peter" == Peter Eisentraut writes:
>> It seems to me that this is a bug in ProcessStartupPacket, which
>> should accept both GSS or SSL negotiation requests on a connection
>> (in either order). Maybe secure_done should be two flags rather than
>> one?
Peter> I have also seen
This came up recently on IRC, not sure if the report there was passed on
at all.
ProcessStartupPacket assumes that there will be only one negotiation
request for an encrypted connection, but libpq is capable of issuing
two: it will ask for GSS encryption first, if it looks like it will be
able to
This patch is a rather hacky implementation of the basic idea for
implementing FETCH ... WITH TIES, and potentially also PERCENT, by using
a window function expression to compute a stopping point.
Large chunks of this (the parser/ruleutils changes, docs, tests) are
taken from Surafel Temesgen's
>>>>> "Alvaro" == Alvaro Herrera writes:
Alvaro> First, I noticed that there's a significant unanswered issue
Alvaro> from Andrew Gierth about this using a completely different
Alvaro> mechanism, namely an implicit window function. Robert was
Alvar
> "Tom" == Tom Lane writes:
>> Well, one obvious completely general method is to teach the planner
>> (somehow) to spot conditions of the form
>> (a > $1 OR (a = $1 AND b > $2) OR (a = $1 AND b = $2 AND c > $3) ...)
>> etc. and make them indexable if the sense of the > or < operator at
> "David" == David Fetter writes:
First, in testing the patch I found there were indeed some missing
cases: the sortsupport version of the comparator needs to be fixed too.
I attach a draft addition to your patch, you should probably look at
adding test cases that need this to work.
David>
> "Tom" == Tom Lane writes:
Tom> Lastly, your proposed use-case has some attraction, but this
Tom> proposal only supports it if the column you need to be differently
Tom> sorted is textual. What if the sort columns are all numerics and
Tom> timestamps?
There are already trivial ways to
> "Pierre" == Pierre Ducroquet writes:
Pierre> Hello
Pierre> In several queries relying on views, I noticed that the
Pierre> optimizer miss a quite simple to implement optimization. My
Pierre> views contain several branches, with different paths that are
Pierre> simplified by the
> "Tom" == Tom Lane writes:
>> But PostgreSQL effectively requires IEEE 754 since commit
>> 02ddd499322ab6f2f0d58692955dc9633c2150fc, right?
Tom> That commit presumes that floats follow the IEEE bitwise
Tom> representation, I think;
Correct. (It notably does _not_ make any assumptions
>>>>> "Tom" == Tom Lane writes:
>> On 2019-11-04 19:04:52 +, Andrew Gierth wrote:
>>> Uh, it seems obvious to me that it should be backpatched?
>> Fine with me. But I don't think it's just plainly obvious, it's
>> essentailly a ch
> "Andres" == Andres Freund writes:
>>> Obviously we _do_ need to be more picky about this; it seems clear
>>> that using CP_SMALL_TLIST | CP_LABEL_TLIST would be a win in many
>>> cases. Opinions?
>> Seems reasonable to me, do you want to do the honors?
Andres> I was briefly
> "Tom" == Tom Lane writes:
Tom> On closer inspection, it seems to be just blind luck. For example,
Tom> if I rearrange the inclusion order in a file using ecpglib.h:
Ugh.
Tom> I'm inclined to think that we need to make ecpglib.h's
Tom> bool-related definitions exactly match c.h,
I'm
> "Mark" == Mark Dilger writes:
Mark> I tried briefly to download this project from pgfoundry without
Mark> success. Do you have a copy of the relevant code where you can
Mark> see how this gets defined, and can you include it in a reply?
I have a backup of the CVS from the pgfoundry
> "Michael" == Michael Paquier writes:
> On Fri, Oct 18, 2019 at 02:21:30PM +0100, Colin Watson wrote:
>> However, an alternative would be to backport the new syntax to some
>> earlier versions. "WITH ... AS MATERIALIZED" can easily just be
>> synonymous with "WITH ... AS" in versions
> "Mark" == Mark Dilger writes:
>> +#ifdef HSTORE_IS_HSTORE_NEW
Mark> Checking the current sources, git history, and various older
Mark> commits, I did not find where HSTORE_IS_HSTORE_NEW was ever
Mark> defined.
In contrib/hstore, it never was.
The current version of contrib/hstore
> "Stefan" == Stefan Wolf writes:
Stefan> I´ve written some PostgreSQL C-Extensions (for the first
Stefan> time...) and they work as expected.
Stefan> But now I want to call other functions from inside the
Stefan> C-Extensions (but not via SPI_execute), for example
Stefan>
BTW, the prior discussion is here:
https://www.postgresql.org/message-id/24868.1550106683%40sss.pgh.pa.us
--
Andrew (irc:RhodiumToad)
> "Tom" == Tom Lane writes:
Tom> Perhaps we could change the back branches so that they interpret
Tom> "-f -" as "write to stdout", but without enforcing that you use
Tom> that syntax.
We should definitely do that.
Tom> Alternatively, we could revert the v12 behavior change. On the
> "Tom" == Tom Lane writes:
Tom> * Please run it through pgindent. Otherwise v13+ are going to be
Tom> randomly different from older branches in this area, once we next
Tom> pgindent HEAD.
gotcha.
Tom> * I think you missed s/walk/mutate/ in some of the comments you
Tom> copied into
> "Tom" == Tom Lane writes:
>> I'm going to leave the assertion out for now and put in a comment
>> for future reference.
Tom> WFM. At this point it's clear it would be a separate piece of work
Tom> not something to slide into the bug-fix patch, anyway.
OK. So here's the final patch.
> "Tom" == Tom Lane writes:
Tom> Hm. transformRuleStmt already does special-case utility statements
Tom> to some extent, so my inclination would be to make it do more of
Tom> that. However, it looks like that might end up with rather
Tom> spaghetti-ish code, as that function is kind of
[moving to -hackers, removing OP and -general]
> "Tom" == Tom Lane writes:
Tom> Also, in HEAD I'd be inclined to add assertions about utilityStmt
Tom> being NULL.
Tried this. The assertion is hit:
#3 0x00bb9144 in ExceptionalCondition (conditionName=0xd3c7a9
> "Antonin" == Antonin Houska writes:
>> It is set to false for numeric and float4, float8.
Antonin> Are you sure about these?
numeric values can compare equal but have different display scales (see
hash_numeric).
float4 and float8 both have representations for -0, which compares equal
This one just came up on IRC:
create table tltest(a integer, b text, c text, d text);
insert into tltest
select i, repeat('foo',100), repeat('foo',100), repeat('foo',100)
from generate_series(1,10) i;
set log_temp_files=0;
set client_min_messages=log;
select count(a+c) from (select a,
> "David" == David Fetter writes:
David> + return pg_ltostr_zeropad(str, (uint32)0 - (uint32)value, minwidth -
1);
No, this is just reintroducing the undefined behavior again. Once the
value has been converted to unsigned you can't cast it back to signed or
pass it to a function expecting
> "David" == David Fetter writes:
David> +static inline uint32
David> +decimalLength64(const uint64_t v)
Should be uint64, not uint64_t.
Also return an int, not a uint32.
For int vs. int32, my own inclination is to use "int" where the value is
just a (smallish) number, especially one
> "David" == David Fetter writes:
David> + /* Compute the result string. */
David> + if (value >= 1)
David> + {
David> + const uint32 value2 = value % 1;
David> +
David> + const uint32 c = value2 % 1;
David> +
> "Michael" == Michael Paquier writes:
Michael> Hi all,
Michael> (Andrew G. in CC)
Michael> We have the following set of header files in src/common/:
Michael> digit_table.h
Michael> d2s_full_table.h
Michael> d2s_intrinsics.h
Michael> ryu_common.h
Michael> Shouldn't all these files
> "Tom" == Tom Lane writes:
> Alvaro Herrera from 2ndQuadrant writes:
>> This discussion seems to have died down. Apparently we have three
>> directions here, from three different people. Are we doing anything?
Tom> I don't really want to do anything beyond the patch I submitted in
> "Sergei" == Sergei Kornilov writes:
Sergei> PS: my note about comments in tests from my previous review is
Sergei> actual too.
I changed the comment when committing it.
--
Andrew (irc:RhodiumToad)
> "Tom" == Tom Lane writes:
Tom> I'm dubious that relying on zone[1970].tab would improve matters
Tom> substantially; it would fix some cases, but I don't think it would
Tom> fix all of them. Resolving all ambiguous zone-name choices is not
Tom> the charter of those files.
Allowing zone
> "Richard" == Richard Guo writes:
Richard> Hi all,
Richard> During the reorder of grouping sets into correct prefix order,
Richard> if only one aggregation pass is needed, we follow the order of
Richard> the ORDER BY clause to the extent possible, to minimize the
Richard> chance that
> "Tom" == Tom Lane writes:
> Robert Haas writes:
>> I'm kind of unsure what to think about this whole debate
>> substantively. If Andrew is correct that zone.tab or zone1970.tab is
>> a list of time zone names to be preferred over alternatives, then it
>> seems like we ought to prefer
> "Tom" == Tom Lane writes:
Tom> No zone1970.tab.
zone.tab is an adequate substitute - a fact which I thought was
sufficiently obvious as to not be worth mentioning.
(also see https://reviews.freebsd.org/D20646 )
Tom> I do not think we can rely on that file being there, since zic
Tom>
> "Thomas" == Thomas Munro writes:
>> Pacific/Auckland -> NZ
Thomas> Right. On a FreeBSD system here in New Zealand you get "NZ"
Thomas> with default configure options (ie using PostgreSQL's tzdata).
Thomas> But if you build with --with-system-tzdata=/usr/share/zoneinfo
Thomas> you get
> "Tom" == Tom Lane writes:
Tom> TBH, I find this borderline insane: it's taking a problem we did
Tom> not have and moving the goalposts to the next county. Not just any
Tom> old county, either, but one where there's a shooting war going on.
Tom> As soon as you do something like putting
> "Tom" == Tom Lane writes:
>> I was referring to the fact that the regression was introduced by a,
>> presumably important, tzdb update (2019a, as mentioned above). At
>> least, I made the assumption that the commit of the import of 2019a
>> had more than just the change that introduced
> "Stephen" == Stephen Frost writes:
Stephen> In the situation that started this discussion, a change had
Stephen> already been made and it was only later realized that it
Stephen> caused a regression.
Just to keep the facts straight:
The regression was introduced by importing tzdb
> "Andres" == Andres Freund writes:
>> During the reorder of grouping sets into correct prefix order, if
>> only one aggregation pass is needed, we follow the order of the
>> ORDER BY clause to the extent possible, to minimize the chance that
>> we add unnecessary sorts. This is
>>>>> "Andrew" == Andrew Gierth writes:
>>>>> "Tom" == Tom Lane writes:
>>> This isn't good enough, because it still picks "UCT" on a system
>>> with no /etc/localtime and no TZ variable. Testing on HEAD as of
&
> "Tom" == Tom Lane writes:
>> This isn't good enough, because it still picks "UCT" on a system
>> with no /etc/localtime and no TZ variable. Testing on HEAD as of
>> 3da73d683 (on FreeBSD, but it'll be the same anywhere else):
Tom> [ shrug... ] Too bad. I doubt that that's a common
> "Tom" == Tom Lane writes:
>> This isn't good enough, because it still picks "UCT" on a system with no
>> /etc/localtime and no TZ variable. Testing on HEAD as of 3da73d683 (on
>> FreeBSD, but it'll be the same anywhere else):
Tom> [ shrug... ] Too bad. I doubt that that's a common
> "Tom" == Tom Lane writes:
>>> Anyway, moving on to the question of what should we do about this,
>>> I don't really have anything better to offer than back-patching
>>> 23bd3cec6.
>> The PG12 behavior seems sane, so +1.
Tom> OK, I'll make that happen.
This isn't good enough,
> "Daniel" == Daniel Verite writes:
Daniel> While testing pg_restore on v12, I'm stumbling on this too.
Daniel> pg_restore without argument fails like that:
Daniel> $ pg_restore
Daniel> pg_restore: error: one of -d/--dbname and -f/--file must be specified
Yeah, that's not good.
How
> "Christoph" == Christoph Berg writes:
Christoph> There is something wrong here. On Debian Buster/unstable,
Christoph> using system tzdata (2019a-1), if /etc/timezone is
Christoph> "Etc/UTC":
Christoph> 11.3's initdb adds timezone = 'UCT' to postgresql.conf
Christoph> 12beta1's initdb
>>>>> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> I believe I pointed out a long, long time ago that this tie-breaking
>> strategy was insane, and that the rule should be to prefer canonical
>> names and use something else only in
> "Christoph" == Christoph Berg writes:
>> Etc/UCT is now a backward-compatibility link to Etc/UTC, instead of
>> being a separate zone that generates the abbreviation "UCT", which
>> nowadays is typically a typo. Postgres will still accept "UCT" as an
>> input zone name, but it won't
> "Akim" == Akim Demaille writes:
>> Yeah, we've definitely found that resolving shift/reduce conflicts
>> via precedence declarations has more potential for surprising
>> side-effects than one would think.
Akim> That's why in recent versions of Bison we also provide a means to
Akim>
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> My inclination is to fix this in the planner rather than the
Andrew> executor; there seems no good reason to actually hash a
Andrew> duplicate column more than once.
I take this back; I don't believe it's possi
> "Finnerty" == Finnerty, Jim writes:
Finnerty> planstate-> total_cost cheapest_total_path
Finnerty> GEQO 54190.1354239.03
Finnerty> STD 54179.0254273.73
These differences aren't significant - the standard join search
>>>>> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> My inclination is to fix this in the planner rather than the
>> executor; there seems no good reason to actually hash a duplicate
>> column more than once.
Tom> Sounds reasonable -
>>>>> "Andrew" == Andrew Gierth writes:
>>> Attached is a patch for a write after allocated memory which we
>>> found in testing. Its an obscure case but can happen if the same
>>> column is used in different grouping keys, as in the example
> "Tom" == Tom Lane writes:
>> Attached is a patch for a write after allocated memory which we
>> found in testing. Its an obscure case but can happen if the same
>> column is used in different grouping keys, as in the example below,
>> which uses tables from the regress test suite
> "Robert" == Robert Haas writes:
Robert> But the number of people using out-of-core postfix operators
Robert> has got to be really tiny -- unless, maybe, there's some really
Robert> popular extension like PostGIS that uses them.
If there's any extension that uses them I've so far failed
> "Andres" == Andres Freund writes:
Andres> Any chance for you to propose a text?
This is what I posted before; I'm not 100% happy with it but it's still
better than any of the other versions:
* Output REAL and DOUBLE PRECISION values in shortest-exact format by
default, and change
[ To: header pruned ]
>>>>> "Andres" == Andres Freund writes:
Andres>
Andres> Avoid performing unnecessary rounding oflinkend="datatype-float">REAL and
DOUBLE
Andres> PRECISION values (Andrew Gierth)
Andres>
> "Tom" == Tom Lane writes:
Tom> Hmm. Oddly, you can't fix it by adding parens:
Tom> regression=# select 'foo' similar to ('f' || escape) escape escape from
(values ('oo')) v(escape);
Tom> psql: ERROR: syntax error at or near "escape"
Tom> LINE 1: select 'foo' similar to ('f' ||
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> The ESCAPE part could in theory be ambiguous if the SIMILAR
Andrew> expression ends in a ... SIMILAR TO xxx operator, since then we
Andrew> wouldn't know whether to attach the ESCAPE to that or keep it
Andr
>>>>> "Andrew" == Andrew Gierth writes:
Tom> I am, frankly, inclined to ignore this as a bad idea. We do have
Tom> SIMILAR and ESCAPE as keywords already, but they're
Tom> type_func_name_keyword and unreserved_keyword respectively. To
Tom> support t
> "Tom" == Tom Lane writes:
Tom> but in recent versions it's
Tom> ::=
Tom> SUBSTRING
Tom> SIMILAR
Tom> ESCAPE
Tom> I am, frankly, inclined to ignore this as a bad idea. We do have
1 - 100 of 444 matches
Mail list logo
