It's not clear from the web site in question that the relevant code is
released under the PostgreSQL license.
As author I allow to use this code in PostgreSQL and under its license.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
sizeof(LWLockPadded) *
nslots);
Attached patch fixes that by removing extra ShmemAlloc for SLRU.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Teodor Sigaev E-mail: teo...@sig
frz->t_infomask &= HEAP_XMAX_COMMITTED;
Seems, in last line it should be a bitwise OR instead of AND. Now this line
cleans all bits in t_infomask which later will be copied directly in tuple.
--
Teodor Sigaev
it as opaque
type. Except, at least, btree and GiST - they believ that internal pointers are
the same as outer (to heap)
Another dubious part - BitmapScan.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http
BTW, was the larger query plan that you showed (with a Materialize node)
generated by 9.6, or v10 HEAD? Because I would be surprised if 9.6 did
v10,
commit acbd8375e954774181b673a31b814e9d46f436a5
Author: Magnus Hagander <mag...@hagander.net>
Date: Fri Jun 2 11:18:24 2017 +0200
--
There were old threads about considering a risk factor when estimating
plans, and I'm thinking this issue is the planner failing to do
exactly that.
I'm afraid it's tool late for v10
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Teodor, could you check if this patch fixes your real-world problem?
It works fine with original query, thank you. But some other query slowdowns for
~10% (9 secs vs 10 secs). Look at following part of plans of huge query:
without patch:
-> Nested Loop (cost=34.82..50.91 rows=1 width
did you stumble upon it?
Unfortunately, it's taken from real application.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
loops:
-> Materialize (cost=0.00..1.40 rows=1 width=8) (actual time=0.000..0.001
rows=17 loops=1048576)
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
Timing is on.
DROP TABLE
Ti
and should wait for v11. Opinions?
Obviously, I'm voting for second patch applied to version 10.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql
Ah, thanks for the clue about enable_hashjoin, because it wasn't
reproducing for me as stated.
I missed tweaked config, sorry
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing
Both 9.6 and 10devel are affected to addiction of query result on seqscan
variable.
Oops, I was too nervious, 9.6 is not affected to enable_seqscan setting. But it
doesn't push down condition too.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
reproduce (subset of real data but obfucated), queries are in attachment
http://sigaev.ru/misc/exists_to_nested.sql.gz
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--query returns 162 rows
explain
patches?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
0001-covering-core.patch
Description: binary/octet-stream
0002-covering-btree.patch
Description: binary/octet-stream
--
Sent via
in this thread about naming and both databases, which
support covering indexes, use INCLUDE keyword.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql
Thank you, pushed
Excellent! I've attached a new (and hopefully final)
version of the patch.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql
-
Matheus de Oliveira
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
Thank you, pushed
Michael Paquier wrote:
On Fri, Mar 24, 2017 at 11:36 PM, Teodor Sigaev <teo...@sigaev.ru> wrote:
And the renaming of pg_clog to pg_xact is also my fault. Attached is
an updated patch.
Thank you. One more question: what about symlinks? If DBA moves, for
example, p
.
If something should be done in this area, that would be surely in
fsync_fname directly to centralize all the calls, and I would think of
that as a separate patch, and a separate discussion.
Agree
--
Teodor Sigaev E-mail: teo...@sigaev.ru
No, it is really needed so that the lag measure is correct.
Thank you, pushed
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Sorry, 1) and 4) is my fault, comment in hsearch.h:
* ... The hash key
* is expected to be at the start of the caller's hash entry data structure.
Ops, forgot that.
Teodor Sigaev wrote:
things in order I'm attaching the previous patch as well.
Patches look good, but I have some notices:
1
of view of pgStatTabList.
4 step 2. The same as 1) about SeenRelsEntry->rel_id but it even isn't
initialized anywhere.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pg
.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
Thank you all, pushed
Michael Paquier wrote:
On Fri, Mar 24, 2017 at 1:45 AM, Teodor Sigaev <teo...@sigaev.ru> wrote:
I believe patch looks good and it's ready to commit.
Thanks for the review!
As I understand, it fixes bug introduced by
commit 7117685461af50f50c03f43e6a622284c8d5469
g = false;
- st->is_throttled = false;
memset(st->prepared, 0, sizeof(st->prepared));
}
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing l
Hmm, it doesn't work (but appplies) on current HEAD:
% uname -a
FreeBSD *** 11.0-RELEASE-p8 FreeBSD 11.0-RELEASE-p8 #0 r315651: Tue Mar 21
02:44:23 MSK 2017 teodor@***:/usr/obj/usr/src/sys/XOR amd64
% pg_config --configure
'--enable-depend' '--enable-cassert' '--enable-debug' '--enable
to 9.6?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Thank you, pushed
Andrew Borodin wrote:
2017-03-22 22:48 GMT+05:00 Teodor Sigaev <teo...@sigaev.ru>:
hasEmptyChild? and hasNonEmptyChild (BTW, isAnyNonempy has missed 't')
Yes, I think this naming is good. It's clear what's in common in these
flags and what's different.
And if the
EmptyChild? and hasNonEmptyChild (BTW, isAnyNonempy has missed 't')
And if the whole posting tree is empty,then we could mark root page as leaf and
remove all other pages in tree without any locking. Although, it could be a task
for separate patch.
--
Teodor Sigaev E
to have another
protection? Like WAL-logging of WAL segment removing...
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
and patch should just remove lock for cleanup over
ginVacuumPostingTreeLeaves() and if it returns that tree contains empty page
then lock the whole posting tree to do ginScanToDelete() work.
--
Teodor Sigaev E-mail:
:not tested
As I can see, this bugfix was already discussed and reviewed.
All mentioned issues are fixed in the latest version of the patch
So I mark it "Ready for committer".
Thank you for fixing it!
The new status of this patch is: Ready for Committer
--
Teo
s same way as before. Revised patch is
attached.
I see the change was done in 9.6 release cycle in commit
48354581a49c30f5757c203415aa8412d85b0f70 at April, 10. Does it mean the fix
should be backpatched too?
--
Teodor Sigaev E-mail: teo...@sig
h_stem;
# select to_tsvector('english', 'bookings');
to_tsvector
--
'book':1 'booking':1
# select to_tsvector('english', 'bookings') @@ 'book <0> booking';
?column?
--
t
(1 row)
--
Teodor Sigaev
Please find attached a patch which makes it possible to disallow
UPDATEs and DELETEs which lack a WHERE clause. As this changes query
behavior, I've made the new GUCs PGC_SUSET.
What say?
DELETE FROM tbl WHERE true; ?
--
Teodor Sigaev E-mail: teo
ces also has significant problems, so care must be taken.
To see memory allocation by opinion of pgsql it's possible to use
https://github.com/postgrespro/memstat
This module (9.6+) could collect information about MemoryContexts allocation.
--
Teodor Sigaev E-mail: teo.
The above-described topic is currently a PostgreSQL 9.6 open item. Teodor,
I'm working on it now and believe that fix will be published today.
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong
That didn't cover all the places that needed to be fixed, but I have
re-read the docs and believe I've made things good now.
I have reviewed this thread and verified that all the cases raised in it
now work as desired, so I have marked the open item closed.
Thank you very much!
--
Teodor
Attached patch changes a precedences of operations to |, &, <->, | in ascending
order. BTW, it simplifies a bit a code around printing and parsing of tsquery.
|, &, <->, ! of course
--
Teodor Sigaev E-ma
gt;
operators appeared in situation when <-> degenerates to & in case of
absence of positional information. Looks like we mixed different
things, will fix.
Attached patch changes a precedences of operations to |, &, <->, | in ascending
order. BTW, it simpli
We're really quickly running out of time to get this done before
beta2. Please don't commit anything that's going to break the tree
because we only have about 72 hours before the wrap, but if it's
correct then it should go in.
Isn't late now? Or wait to beta2 is out?
--
Teodor Sigaev
m
okay with the patch as presented.
Huh, I found that my isn't correct for example which I show :(. Reworked patch
is in attach.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sig
Tom Lane wrote:
Teodor Sigaev <teo...@sigaev.ru> writes:
So I think there's a reasonable case for decreeing that should only
match lexemes *exactly* N apart. If we did that, we would no longer have
the misbehavior that Jean-Pierre is complaining about, and we'd not need
to argue
nformation. If this behavior looks more reasonable, I'll commit that.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
phrase_no_fallback.patch
Description: binary/octet-stream
--
Sent
) <-> 'bar'
and
# select to_tsvector('foo-bar') @@ phraseto_tsquery('foo-bar');
?column?
--
t
Patch is attached
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
phrase_exact_d
management team
ownership without further notice.
[1]
http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com
I'm working on it right now.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http
the in-core ones.
+1.
Are there other opinions? That's not a 9.6 blocker IMO, so I could get
patches out for 10.0 if needed.
I missed that on review process, but I'm agree it should be implemented.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
;
uint32 eas_used;
RBTree *tree;
Are you sure this is safe, Teodor? I don't have time to study the
patch in detail, but offhand I think that it might have been better to
make allocatedMemory of type int64, just like the tuplesort.c memory
accounting variables are post-MaxAllocHuge. It's
This all should me moved behind "access method" abstraction...
+1 relopt_kind should be moved in am, at least. Or removed.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
-
you should add "USING bloom" to the insert statement, in order make this
example work.
Patch in the attachment fixes an example. Please commit it ;-)
Thank you, applied
--
Teodor Sigaev E-mail: teo...
alize we're already in beta, but pgCon was actually the first time I
saw the new syntax. I think if we don't do this now, we'll be doing it
for 10.0.
Havn't an objections for 10.0
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WW
i-bin/show_log.pl?nm=curculio=2016-05-17+19%3A30%3A09
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
that.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
bug (first ERROR: attempted to delete invisible tuple). IMHO, it's
a separate bug, not related to oid. Unfortunately, I've never seen such error on
my notebook.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Hm. And you're not seeing the asserts I reported in
http://archives.postgresql.org/message-id/20160505185246.2i7qftadwhzewykj%40alap3.anarazel.de
?
I see it a lot, but I think that is a result of ereport(FATAL) after
FileWrite(BLCKSZ/3) added by Jeff.
Teodor Sigaev
0x008e54bd in exec_bind_message (input_message=0x7fffdf60) at
postgres.c:1602
#20 0x008e3957 in PostgresMain (argc=1, argv=0x801d3c968,
dbname=0x801d3c948 "teodor", username=0x801d3c928 "teodor") at postgres.c:4105
#21 0x00839744 in BackendR
, but it could take a time.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
_16424
The test required 10 hours to run on my notebook. postgresql was compiled with
-O0 --enable-debug --enable-cassert.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-h
Thank you, pushed.
Stas Kelvich wrote:
Hi.
As discovered by Oleg Bartunov, current filter() function for tsvector can
crash backend.
Bug was caused erroneous usage of char type in memmove argument.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
I think this number should be specified only once, in .h file.
Yep, that sounds true.
It may be a good idea to make something similar for contrib/bloom if >
0 values are defined for amstrategies or amsupport for consistency.
Thank you, pushed.
--
Teodor Sig
e with OID 16384
I've pushed v5 of gin-alone-cleanup patch, many thanks to all participants.
Will work on backpatch
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers ma
There are some previously unnoticed errors in docs (master branch), this patch
fixes them.
Thank you, pushed
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers
and gin_clean_pending_list() should do that. In all other cases it should
stop early to prevent possible infinite cleanup. Patch attached.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru
was a tail on cleanup
start then we sets cleanupFinish variable and after cleaning that page we will
stop further cleanup. Any insert caused during cleanup will be placed after
blknoFinish (corner case: in that page), so, vacuum should not miss tuples
marked as deleted.
--
Teodor Sigaev
it at mondeay and backpatch all supported
versions.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
. I
think that would probably be good enough, because the current
throttling behavior is purely accidentally and doesn't *guarantee* a
limit on the size of the pending list.
Added, see attached patch (based on v3.1)
--
Teodor Sigaev
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
I agree with both of these ideas. Patch is attached.
Hmm, you accidentally forget to change flag type of GenericXLogRegister in
contrib/bloom signature.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http
struct equals 6 bytes but special size is MAXALIGNED, so,
last two bytes will be unused. If unused field is not a problem, I will push
this patch.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http
Thank you very much
thank you, pushed. Pls, pay attention to buildfarm.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
dnkeyatts should be strictly less
than indnatts, pls, change assertion. If they are equal the this function
becomes complicated variant of CopyIndexTuple()
--
Teodor Sigaev E-mail: teo...@sigaev.ru
, it doesn't change an internal logic of lock machinery.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
sounds quite reasonable. Here is a new version of patch (it will throw
an error for an existing key). Is it better now?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hac
tests, but I think it should be allowed.
In this case it will work exactly as jsbonb_set
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
It seems to me that the patch is completed.
Except, maybe, grammar check of comments and documentation.
Looking forward to your review.
Are there any objectins on it? I'm planning to look closely today or tommorrow
and commit it.
--
Teodor Sigaev E-mail: teo
The above-described topic is currently a PostgreSQL 9.6 open item. Teodor,
since you committed the patch believed to have created it, you own this open
item. If that responsibility lies elsewhere, please let us know whose
responsibility it is to fix this. Since new open items may be discovered
aves rules
about duplicating character.
select 'fat'::tsquery ** 'cat';
select 'fat * cat'::tsquery;
select 'fat * [3] cat'::tsqyery; -- for non-default distance.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
hrase. It seems much more natural to me.
Yes, agree for omission. But for reason above its'n a good name although I don't
have a strong objections.
may be <=>? it isn't used anywhere yet.
select 'fat'::tsquery <=> 'cat';
select 'fat <=> cat'::tsquery;
select 'fat <3> cat':
far yet.
On 25.03.16 18:42 MSK, David Steele wrote:
Time is short and it's not encouraging that you say there is "still much
work to be done".
Indeed, I was inaccurate. I am more than interested in the positive outcome.
--
Teodor Sigaev E
also added support for
them. It is also attached with the updated version of my test script.
I hope I haven't changed the patch too much. I have also pushed the
changes here:
https://github.com/hasegeli/postgres/commits/box-spgist
--
Teodor Sigaev E-mail: teo...
discussion is about SQL-level types which could be stored on disk, not
about in-memory structs
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgs
ul example for such feature.
- add callback via RegisterResourceReleaseCallback() which will cleanup state
of genericXlogStatus variable
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgs
I incorporated your changes and did some additional refinements on top of them
still.
Attached is delta against v12, that should cause less issues when merging for
Teodor.
But last version is 13th?
BTW, it would be cool to add odcs in VII. Internals chapter, description should
be similar
ess/transam/generic_xlog.c...)
Patching file src/backend/access/transam/generic_xlog.c using Plan A...
patch: malformed patch at line 634: diff --git
a/src/backend/access/transam/rmgr.c b/src/backend/access/transam/rmgr.c
--
Teodor Sigaev E-mail: teo...@sigaev
Does that mean this patch should be closed or is there more remaining to commit?
Petr promises to check english in comments/docs in generic-wal patch at this
week, bloom patch depends on it. Bloom patch is ready from my point of view.
--
Teodor Sigaev E
for libicu with configure flag
--with-icu. Patch rebased to current HEAD, hope, it works.
It's based on https://people.freebsd.org/~girgen/postgresql-icu/readme.html
work, and it was migrated to 9.5 with abbrevation keys support.
Patch in current state is not ready to commit, of course.
--
Teodor
e move this to the top of the function?
yep, fixed
+ out->nodeNumbers = (int *) palloc(sizeof(int) * in->nNodes);
This could go before allTheSame block.
yep, fixed
I've attached all patches again. Thank you very much!
--
Teodor Sigaev
. See Oleg's message.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
tend to think of a *point* as having *zero* dimensions. Would it
perhaps be more accurate to say we are treating a 2-dimensional box
as a point in 4-dimensional space?
Exactly, sorry for ambiguity.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
t
+);
I don't think this matches the project coding style.
fixed
+ int flag = 1,
Wouldn't it be better as "bool"?
fixed.
The regression tests for the remaining operators are still missing.
Ooops, will be soon.
Attached all patches
to it before weekend.
So, per patch status:
create-am
ready
generic-xlog
need to fix comments/docs
bloom-contrib
need review. I'm an original author of this module and of course
I can do some review of it but, seems, it's needed more eyes.
--
Teodor Sigaev
ne.
added
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
0001-idx_or_core-v4.patch.gz
Description: GNU Zip compressed data
0002-idx_or_indexes-v4.patch.gz
Description: GNU Zip compressed data
--
o I think this way of building the index path from a BitmapOr path is
pretty much a dead-end.
I don't think so because separate code path to support OR-clause in index will
significanlty duplicate BitmapOr generator.
Will send next version as soon as possible. Thank y
Good catch, thanks! Tests were added.
I don't see any objection, is consensus reached? I'm close to comiit that...
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql
generated file
./src/include/utils/builtins.h
range patch is unchanged, but still attached to keep them altogether.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
q4d-2.patch.gz
Descripti
I hope so the messages are ok now. Few more regress tests added.
Thank you, committed.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql
r contains disallowed characters: "\"c"
Error message wrongly points to the reason of error.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
parse_ident-13.patch
Description: bina
I saw errors on windows, here is the fix:
Thank you, pushed
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
and
tsvector_to_array to have consistent name. Later we could add
to_tsvector([regconfig, ], text[]) with morphological processing.
Thoughts?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru
t(E'"\005"') as "\005";
\005
{\x05}
Display outputs of actual identifier and parse_indent are differ.
Actually, I can live with both but are any other opinions? Seems, at least
difference of actual identifier and output of parse_indent should be pointed in
docs.
--
Teod
1 - 100 of 817 matches
Mail list logo
