Hi,
Attached patch adds GiST support to the inet datatypes with two new
operators. Overlaps operator can be used with exclusion constraints.
Is adjacent to operator is just the negator of it. Index uses only
the network bits of the addresses. Except for the new operators and
is contained within,
I am not sure it worth reporting but it took me a while to find out
what is wrong with comparing two values returned from
the bitncmp function. It does not return -1, 1 or 0 as it is written
on the comment when n % 8 == 0.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
2013-12-17 Emre Hasegeli e...@hasegeli.com:
Query planner never chooses to use the index for the operators which
the index is particularly useful because selectivity estimation functions
are missing. I am planning to work on them.
Attached patch adds selectivity estimation functions
I get assertion failure on initsplan.c line 1325 while executing following query
on HEAD (edc43458d797a5956f4bf39af18cf62abb0077db). It works fine
without --enable-cassert.
update subscriber set properties = hstore(a) from (select firstname,
lastname from player where player.id = subscriber.id)
2014/1/9 Oskari Saarenmaa o...@ohmu.fi:
The only useful feature of the uuid-ossp module in my opinion is the
uuid_generate_v4 function and as uuid-ossp is more or less abandonware
people have had trouble building and installing it. This patch implements
an alternative uuid v4 generation
2014-01-19 Andreas Karlsson andr...@proxel.se:
Hi,
I will review your two patches (gist support + selectivity). This is part 1
of my review. I will look more into the actual GiST implementation in a
couple of days, but thought I could provide you with my initial input right
away.
Thank you
2014-01-19 12:10, Emre Hasegeli e...@hasegeli.com:
2014-01-19 Andreas Karlsson andr...@proxel.se:
I am a bit suspicious about your memcmp based optimization in bitncommon,
but it could be good. Have you benchmarked it compared to doing the same
thing with a loop?
I did, when I was writing
Hi,
This is my review about 3th version of the patch. It is an useful
improvement in my opinion. It worked well on my environment.
2013-12-11 17:43:06, Sergey Muraviov sergey.k.murav...@gmail.com:
It works in expanded mode when either format option is set to wrapped
(\pset format wrapped), or
2014-02-16 18:37, Sergey Muraviov sergey.k.murav...@gmail.com:
New code doesn't work with empty strings but I've done minor optimization
for this case.
It seems better now. I added some new lines and spaces, removed unnecessary
parentheses and marked it as Ready for Committer.
2014-02-17 22:16, Tom Lane t...@sss.pgh.pa.us:
More generally, it doesn't look to me like these upgrade scripts are
complete; shouldn't they be creating some new objects, not just replacing
old ones?
The actual patches are on the previous mail [1]. I was just trying
to solve the problem that
2014-02-19 16:52, Tom Lane t...@sss.pgh.pa.us:
Not at all, AFAICS. If it were okay to decide that some formerly-default
opclass is no longer default, then having such a command would be better
than manually manipulating pg_opclass.opcdefault --- but extension upgrade
scripts could certainly
2014-02-20 01:37, Tom Lane t...@sss.pgh.pa.us:
Perhaps it would be acceptable to drop the btree_gist implementation
and teach pg_upgrade to refuse to upgrade if the old database contains
any such indexes. I'm not sure that solves the problem, though, because
I think pg_upgrade will still
2014-02-24 02:44, Andreas Karlsson andr...@proxel.se:
Note: The patches do not apply anymore due to changes to
src/backend/utils/adt/Makefile.
I will fix it on the next version.
I see, thanks for the explanation. But I am still not very fond of how that
code is written since I find it hard
2014-02-24 17:55, Bruce Momjian br...@momjian.us:
pg_upgrade has _never_ modified the old cluster, and I am hesitant to do
that now. Can we make the changes in the new cluster, or in pg_dump
when in binary upgrade mode?
It can be possible to update the new operator class in the new cluster
2014-02-27 18:15, Florian Pflug f...@phlo.org:
It can be possible to update the new operator class in the new cluster
as not default, before restore. After the restore, pg_upgrade can upgrade
the btree_gist extension and reset the operator class as the default.
pg_upgrade suggests to re-initdb
2014-02-28 17:30, Florian Pflug f...@phlo.org:
Hm, what if we put the new opclass into an extension of its own, say
inet_gist,
instead of into core?
It will work but I do not think it is better than adding it in core as
not default.
--
Sent via pgsql-hackers mailing list
Tom Lane t...@sss.pgh.pa.us:
Committed with some additional documentation work. Thanks for
submitting this!
Thank you for committing. I had not thought of using different structure
for the index. It works faster with my test case, too.
I am sending rebased version of the consistent operator
Pavel Stehule pavel.steh...@gmail.com:
Hello
I am checking feature
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=6513633b94173fc1d9e2b213c43f9422ddbf5faa
It works perfect with pager less, but it works badly with default more
see attached screenshots, pls
It is
New version of the selectivity estimation patch attached. I am adding
it to CommitFest 2014-06. Previous version of it reviewed by
Andreas Karlson on the previous CommitFest with the GiST support patch.
The new version includes join selectivity estimation.
Join selectivity is calculated in 4
I wanted to check the patch last time and found a bug effecting
MVC vs MVC part of the join selectivity. Fixed version attached.
Emre Hasegeli e...@hasegeli.com:
Comparing the lists with each other slows down the function when
statistics set to higher values. To avoid this problem I only use
Joshua Yanovski pythones...@gmail.com:
Proof of concept initial patch for enabling index only scans for
partial indices even when an attribute is not in the target list, as
long as it is only used in restriction clauses that can be proved by
the index predicate. This also works for index
Thank you for looking at it.
In inet_his_inclusion_selec function,
When the constant matches only the right side of the bucket, and if it’s a
last bucket then it's never considered as partial match candidate.
In my opinion, if it's not a last bucket then for next bucket it will become
I have one last comment, after clarifying this I can move it to ready for
committer.
1. In networkjoinsel, For avoiding the case of huge statistics, only some of
the values from mcv and histograms are used (calculated using SQRT).
-- But in my opinion, if histograms and mcv both are exist
The first two shapes on src/test/regress/sql/polygon.sql do not make
sense to me. They look more like polygons with some more tabs,
but still did not match the coordinates. I changed them to make
consistent with the shapes. I believe this was the intention of
the original author. Patch
That seems like a nonstarter :-(. Index-only scans don't have a license
to return approximations. If we drop the behavior for circles, how much
functionality do we have left?
It should work with exact operator classes, box_ops, point_ops,
range_ops, inet_ops.
--
Sent via pgsql-hackers
Well, I think the number of tabs that makes them look best depends on
your tab-stop setting. At present, I find that with 8-space tabs
things seem to line up pretty well, whereas with your patch, 4-space
tabs line up well. Either way, I have no idea what the picture is
supposed to mean,
1. This patch introduces a new polygon - point operator. That seems
useful on its own, with or without this patch.
Yeah, but exact-knn cant come with no one implementation. But it would
better come in a separate patch.
I tried to split them. Separated patches are attached. I changed
the
I agree with you that we can support other join type and anti join later,
If others don’t have any objection in doing other parts later I will mark as
Ready For Committer.
I updated the patch to cover semi and anti joins with eqjoinsel_semi().
I think it is better than returning a constant.
* Isn't X Y equivalent to network_scan_first(X) Y AND
network_scan_last(X) Y? Or at least close enough for selectivity
estimation purposes? Pardon my ignorance - I'm not too familiar with the
inet datatype - but how about just calling scalarineqsel for both bounds?
Actually, X Y is
Heikki Linnakangas hlinnakan...@vmware.com writes:
* inet_mcv_join_selec() is O(n^2) where n is the number of entries in
the MCV lists. With the max statistics target of 1, a worst case
query on my laptop took about 15 seconds to plan. Maybe that's
acceptable, but you went through
What you did there is utterly unacceptable from a modularity standpoint;
and considering that the values will be nowhere near right, the argument
that it's better than returning a constant seems pretty weak. I think
you should just take that out again.
I will try to come up with a better,
I updated the patch to cover semi and anti joins with eqjoinsel_semi().
I think it is better than returning a constant.
What you did there is utterly unacceptable from a modularity standpoint;
and considering that the values will be nowhere near right, the argument
that it's better
I added the point to polygon distance operator patch to the open
CommitFest as ready for committer and added myself as reviewer to
both of the patches.
I think that for most use cases just some operators require further sorting
and some of them not. But it could appear one day that some index
No. And we don't know how to change the default opclass without
breaking things, either. See previous discussions about how we
might fix the totally-broken default gist opclass that btree_gist
creates for the inet type [1]. The motivation for getting rid of that
is *way* stronger than it
Changing the default opclasses should work if we make
pg_dump --binary-upgrade dump the default opclasses with indexes
and exclusion constraints. I think it makes sense to do so in
--binary-upgrade mode. I can try to come with a patch for this.
Can you explain it a bit more detail? I
While looking it at I found a bug. It returns the second column
in wrong order when both of the distance functions return recheck = true.
Test script attached to run on the regression database. I tried to
fix but could not. searchTreeItemDistanceRecheck function is not
very easy to
I managed to break it again by ordering rows only by the second column
of the index. Test script attached.
I was confused. It is undefined behavior. Sorry for the noise.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Fixed, thanks.
Here are my questions and comments about the code.
doc/src/sgml/gist.sgml:812:
be rechecked from heap tuple before tuple is returned. If
literalrecheck/ flag isn't set then it's true by default for
compatibility reasons. The literalrecheck/ flag can be
Thanks. Overall, my impression of this patch is that it works very
well. But damned if I understood *how* it works :-). There's a lot
of statistics involved, and it's not easy to see why something is
multiplied by something else. I'm adding comments as I read through
it.
Thank you for
Thanks. The main question now is design of this patch. Currently, it does
all the work inside access method. We already have some discussion of pro
and cons of this method. I would like to clarify alternatives now. I can
see following way:
1. Implement new executor node which performs
I extracted Emre's diagram adjustments from the patch and applied it,
and no tabs now. Emre, I assume your regression changes did not affect
the diagram contents.
Thank you for looking at it. I wanted to make the tests consistent
with the diagrams. Now they look better but they still don't
Once again, many thanks for the review. Here's a new version. I have
added operator classes for int8, text, and actually everything that btree
supports except:
bool
record
oidvector
anyarray
tsvector
tsquery
jsonb
range
since I'm not sure that it
I spent a fair chunk of the weekend hacking on this patch to make
it more understandable and fix up a lot of what seemed to me pretty
clear arithmetic errors in the upper layers of the patch. However,
I couldn't quite convince myself to commit it, because the business
around estimation for
Actually, there's a second large problem with this patch: blindly
iterating through all combinations of MCV and histogram entries makes the
runtime O(N^2) in the statistics target. I made up some test data (by
scanning my mail logs) and observed the following planning times, as
reported by
I thought we can do better than minmax for the inet data type,
and ended up with a generalized opclass supporting both inet and range
types. Patch based on minmax-v20 attached. It works well except
a few small problems. I will improve the patch and add into
a commitfest after BRIN
New version of the patch attached with the optimization to break the
loop before looking at all of the histogram values. I can reduce
join selectivity estimation runtime by reducing the values of the
left hand side or both of the sides, if there is interest.
Even if the above aspects of the
Looking at patch 04, it seems to me that it would be better to have
the OpcInfo struct carry the typecache struct rather than the type OID,
so that we can avoid repeated typecache lookups in brin_deform_tuple;
Here's the patch.
Looks better to me. I will incorporate with this patch.
--
Can you please explain what is the purpose of patch 07? I'm not sure I
understand; are we trying to avoid having to add pg_amproc entries for
these operators and instead piggy-back on btree opclass definitions?
Not too much in love with that idea; I see that there is less tedium in
that the
I pushed patches 04 and 07, as well as adopting some of the changes to
the regression test in 06. I'm afraid I caused a bit of merge pain for
you -- sorry about that.
No problem. I rebased the remaining ones.
brin-inclusion-v09-02-strategy-numbers.patch
Description: Binary data
Indeed, I have done some testing of the patch but more people testing would
be nice.
The inclusion opclass should work for other data types as long
required operators and SQL level support functions are supplied.
Maybe it would work for PostGIS, too.
--
Sent via pgsql-hackers mailing list
Nice, I think it is ready now other than the issues Alvaro raised in his
review[1]. Have you given those any thought?
I already replied his email [1]. Which issues do you mean?
[1]
http://www.postgresql.org/message-id/CAE2gYzxQ-Gk3q3jYWT=1enlebsgcgu28+1axml4omcwjbkp...@mail.gmail.com
--
Judging from a quick look, I think patches 1 and 5 can be committed
quickly; they imply no changes to other parts of BRIN. (Not sure why 1
and 5 are separate. Any reason for this?) Also patch 2.
Not much reason except that 1 includes only functions, but 5 includes operators.
Patch 4 looks
Emre Hasegeli just pointed out to me that this patch introduced
box_contain_pt() and in doing so used straight C comparison (= etc)
instead of FPlt() and friends. I would think that that's a bug and
needs to be changed -- but certainly not backpatched, because gist
indexes would/might become
to handle DROP dependency behaviors properly. (On reflection, maybe
better if it's bernoulli(internal) returns tablesample_handler,
so as to guarantee that such a function doesn't create a conflict with
any user-defined function of the same name.)
The probability of conflict seems high with
Emre Hasegeli told me on IM he's going to submit a patch to add
something similar for the inclusion opclass framework.
It is attached. Thank you for pushing forward to improve the documentation.
0001-Improve-BRIN-documentation-for-Inclusion-opclass.patch
Description: Binary data
--
Sent
> Currently PostgreSQL only has trigonometric functions that work in
> radians. I think it would be quite useful to have an equivalent set of
> functions that worked in degrees. In other environments these are
> commonly spelled sind(), cosd(), etc.
I would prefer gradian over degree.
--
Sent
Thank you for working on this.
I tried the patch with a Turkish dictionary [1] I could find on the
Internet. It worked for some words, but not others:
> hasegeli=# create text search dictionary hunspell_tr (template = ispell,
> dictfile = tr, afffile = tr);
> CREATE TEXT SEARCH DICTIONARY
>
>
>> Pls. don't misunderstand my questions: They are directed to get an
>> even more useful spatial data handling of PostgreSQL. I'm working with
>> PostGIS since years and are interested in any work regarding spatial
>> types...
>>
>> Can anyone report use cases or applications of these built-in
> This was already fixed for GiST.
> See following discussion
> http://www.postgresql.org/message-id/capphfdvgticgniaj88vchzhboxjobuhjlm6c09q_op_u9eo...@mail.gmail.com
> and commit
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3c29b196b0ce46662cb9bb7a1f91079fbacbcabb
>
I was getting segfaults while working on the current master for a while.
This is the shortest way I could found to reproduce the problem:
create or replace function is_distinct_from(anyelement, anyelement)
returns boolean language sql
as 'select $1 is distinct from $2';
create operator !== (
> But is it? Is it impossible for the BRIN bitmap index scan to return 0 rows
> (say, if the value being matched is outside the min/max boundary for every
> block range?) Granted, if we document that it always returns 0 and should be
> ignored, then confusing the actual 0 with the 0 as a
> which is much closer to the actual number of rows removed by the index
> recheck + the one left.
Is it better to be closer? We are saying those are the "actual"
values not the estimates. If we cannot provide the actual rows, I
think it is better to provide nothing. Something closer to the
> I don’t see how to solve this problem without changing explain analyze output
> to accommodate for “unknown” value. I don’t think “0” is a non-confusing
> representation of “unknown” for most people, and from the practical
> standpoint, a “best effort” estimate is better than 0 (i.e. I will
> The patch is attached.
Now, it is actually attached.
brin-correlation-v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Somebody wrote to me a few days ago that the BRIN cost estimation is
> rather poor. One immediately obvious issue which I think is easily
> fixed is the correlation estimate, which is currently hardcoded to 1.
>
> Since a BRIN scan always entails a scan of the relation in physical
> order, it's
> I checked new snowball site http://snowballstem.org/ and found several new
> stemmers appeared (as external contributions):
>
> Irish and Czech
> Object Pascal codegenerator for Snowball
> Two stemmers for Romanian
> Hungarian
> Turkish
> Armenian
> Basque (Euskera)
> Catalan
>
> Some of them we
edback.
From a6f24b34fdb39eaaca1d3819f7f528b1689725a4 Mon Sep 17 00:00:00 2001
From: Emre Hasegeli <e...@hasegeli.com>
Date: Sun, 29 May 2016 18:53:37 +0200
Subject: [PATCH] Add regexp_match()
---
doc/src/sgml/citext.sgml | 5 ++
doc/src/sgml/func.sgml
[3] https://www.postgresql.org/message-id/flat/12549.1346111...@sss.pgh.pa.us
[4]
https://www.postgresql.org/message-id/flat/20150512181307.gj2...@alvh.no-ip.org
From aa79e331595860489cdbbdce2d5f35a7d1f33783 Mon Sep 17 00:00:00 2001
From: Emre Hasegeli <e...@hasegeli.com>
Date: Wed, 25 May 2016
> My interpretation of the standard is that FILTER is not allowable for
> a window function, and IGNORE|RESPECT NULLS is not allowable for an
> ordinary aggregate.
Yes, it is clear.
> So if we support IGNORE|RESPECT NULLS for anything other than a window
> function, we have to come up with our
17 00:00:00 2001
From: Emre Hasegeli <e...@hasegeli.com>
Date: Sun, 29 May 2016 18:53:37 +0200
Subject: [PATCH] Add regexp_match()
---
doc/src/sgml/citext.sgml | 5 ++
doc/src/sgml/func.sgml | 59 +++---
src/backend/catalog/information_sche
>> In create_opclass.sgml, not only do we have the list of AMs supporting
>> STORAGE, but there is also a paragraph describing which AMs do what
>> for input datatypes of FUNCTION members (around line 175).
>
> I placed BRIN together with gist/gin/spgist here, namely that the optype
> defaults to
Here are my first comments. I haven't read the actual index
implementation, yet.
I think traversal value is a useful addition. It is nice that the
implementation for the range types is also changed. My questions
about them are:
Do reconstructedValues is required now? Wouldn't it be cleaner
Here are my comments about the operator class implementation:
> + *implementation of quad-4d tree over boxes for SP-GiST.
Isn't the whole thing actually 3D?
> + * For example consider the case of intersection.
No need for a new line after this.
> + * A quadrant has bounds, but sp-gist
> I guess multicolumn BRIN behaves similarly to B-tree or GiST. But I'm
> no expert, so I need someone knowledgeable to confirm this. If the
> following wording is OK, I will update the patch.
Multicolumn BRIN is like GIN. Every column is indexed separately.
The order of the columns doesn't
> + * boxtype_spgist.c
The names on the file header need to be changed, too.
> I'll try to explain with two-dimensional example over points. ASCII-art:
>|
>|
> 1 | 2
>|
> ---+-
>|P
> 3 | 4
>
>>> I'll try to explain with two-dimensional example over points. ASCII-art:
>>
>> Thank you for the explanation. Should we incorporate this with the patch.
>
> added
I have worked on the comments of the patch. It is attached. I hope
it looks more clear than it was before.
>>> +
Attached patches add SP-GiST support to the inet datatypes. The operator
class comes with a small change on the SP-GiST framework to allow fixed
number of child nodes.
The index is like prefix tree except that it doesn't bother to split the
addresses into parts as text is split. It also doesn't
> Emre, I checked original thread and didn't find sample data. Could you
> provide them for testing ?
I found it on the Git history:
https://github.com/job/irrexplorer/blob/9e8b5330d7ef0022abbe1af18291257e044eb24b/data/irrexplorer_dump.sql.gz?raw=true
--
Sent via pgsql-hackers mailing list
>> Spgist index tree is much better than gist - 12149 pages vs 1334760 !
I assume this is the reason why it is bigger. IP addresses are very
well suited to SP-GiST. They naturally do not overlap.
> I also noticed, that spgist is much faster than gist for other inet
> operators. I'd like to
I think the variable "magick" should be "magic". Patch attached.
bloom-magick.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Thank you, pushed
Thank you for working on this.
I noticed that have overlooked this:
static RectBox *
-initRectBox()
+initRectBox(void)
{
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
> I do not know whether this would be a meaningful improvement for
> common use-cases, though. (It'd help if people were more specific
> about the use-cases they need to work.)
For what its worth, in the company I am working for, InnoGames GmbH,
not being able to alter enums is the number one
> It might be more useful after we get the infrastructure that Kevin's been
> working on to allow collecting all the updates into a tuplestore that
> could be passed to a statement-level trigger. Right now I tend to agree
> that there's little point.
Maybe, this can be used to re-implement
> I think that probably the most reasonable answer is to replace all the
> raw "double" comparisons in this code with float8_cmp_internal() or
> something that's the moral equivalent of that. Does anyone want to
> propose something else?
We can probably get away by changing the comparison on the
> Got it, but if other people don't agree then this is going nowhere.
Yes. As I wrote, I don't particularly care about functions like "is
point on line". I can prepare a patch to fix as many problems as
possible around those operators by preserving the current epsilon.
I though we were arguing
> I think this patch is already in a good shape.
I am sorry for introducing this bug. This fix looks good to me as well.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Backing up a bit here, have we lost track of the problem that we're
> trying to solve? Tom gave his opinion here:
>
> https://www.postgresql.org/message-id/3895.1464791...@sss.pgh.pa.us
>
> But I don't see that the latest patch I can find does anything to fix
> that.
This is what he wrote:
>
> As there are a lot of updates I did my best to consolidate some of the
> bullet points and as usual, people are directed to the release notes.
> Please let me know if there are any inaccuracies so I can fix them ASAP.
Just some minor points:
> * Several fixes for PostgreSQL operating in hot
I am responding both of your emails together.
> Perhaps I don't understand it. Many opclass are defined for
> btree. But since (ordinary) btree handles only one-dimentional,
> totally-orderable sets, geometric types even point don't fit
> it. Even if we relaxed it by removing EPSILON,
> Even though I'm not sure but I don't see a "natural" (or
> agreeable by many poeple) ordering of geometric types in
> general. Anyway it's quite application (not application program
> but the relationship with the real world) specific.
We can just define it for point as "ORDER BY point.x,
> The reason this is kind of scary is that it's just blithely assuming
> that the function won't look at the *other* fields of the FmgrInfo.
> If it did, it would likely get very confused, since those fields
> would be describing the GIN support function, not the function we're
> calling.
I am
> Here is v4, which changes the command from ALTER VALUE to RENAME VALUE,
> for consistency with RENAME ATTRIBUTE.
It looks like we always use "ALTER ... RENAME ... old_name TO
new_name" syntax, so it is better that way. I have noticed that all
the other RENAMEs go through ExecRenameStmt(). We
> ... this part of the patch breaks the existing API for SP-GiST opclasses.
> That is a hard sell. It may only matter for one existing opclass in core,
> but unless we have reason to think nobody is using any custom SP-GiST
> opclasses, that is not a pleasant thing to do. How important is it
> Given that you are now familiar with the internals of how enums are
> implemented would it be possible to continue the work and add the "ALTER
> TYPE DROP VALUE " command?
I was thinking to try developing it, but I would be more than happy to
help by testing and reviewing, if someone else
> Got around to looking at this. Attached is a revised version that I think
> is in committable shape. The main non-cosmetic change is that the test
> for "type was created in same transaction as new value" now consists of
> comparing the xmins of the pg_type and pg_enum rows, without consulting
> I started looking at this patch. I'm kind of unhappy with having *both*
> IF EXISTS and IF NOT EXISTS options on the statement, especially since
> the locations of those phrases in the syntax seem to have been chosen
> with a dartboard. This feels way more confusing than it is useful.
> Is
> Why not just disallow dropping a value that's still in use? That's certainly
> what I would prefer to happen by default...
Of course, we should disallow it. That problem is what to do next.
We cannot just remove the value, because it might still be referenced
from the inner nodes of the
> Bottom line here is that I'd rather commit ALTER TYPE RENAME VALUE with
> no EXISTS features and then see it accrete those features together with
> other types of RENAME, when and if there's a will to make that happen.
This sounds like a good conclusion to me.
--
Sent via pgsql-hackers
> I did *not* push the hunk in citext.sgml, since that was alleging support
> that doesn't actually exist in this patch. To make this work for citext,
> we need to add wrapper functions similar to citext's wrappers for
> regexp_matches. And that in turn means a citext extension version bump,
>
> Emre, I noticed you modified the commitfest entry
> (https://commitfest.postgresql.org/10/588/) to be for Andrew's
> transactional enum addition patch instead, but didn't change the title.
> I'll revert that as soon as it picks up this latest patch. Do you wish
> to remain a reviewer for this
1 - 100 of 140 matches
Mail list logo
