Tom Lane wrote:
I'm unimpressed by this part --- we couldn't back-patch such a change, and
I think it's unnecessary anyway in 9.6+ because the scan provider could
generate a nondefault pathtarget if it wants this to happen.
You're right, of course. Thank you very much!
--
Dmitry Ivanov
unhappy. Are you satisfied if we change this in HEAD?
It's kind of bittersweet. I'm really glad that you've changed your mind and
this is going to be fixed in HEAD, but this change is crucial for our
extension (if we use it with vanilla postgres).
Maybe you'll like my patch more.
--
Dmitry
could be much
simpler if I just patched the core, but we have a working extension for 9.5
and 9.6, and we can't throw it away just yet. I wouldn't bother you if I
didn't encounter a broken query :)
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
-
out physical tlists.
It's not just my imagination.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ist'
to 'targetlist'). However, this doesn't mean that it's unable to produce
the same result.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
cal_tlist(), which means that we might see
something like this:
ERROR: variable not found in subplan target list
if we use child IndexOnlyScan and the index does not include some of the
relation's columns.
Is there any existing workaround?
--
Dmitry Ivanov
Postgres Professio
and also in transformTableEntry(). It might be hacky, but it gives
an idea.
I didn't touch RenameConstraint() and renameatt() since this would break
ALTER TABLE ONLY command.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Companydiff --git a/src/backend/commands/tab
Huh, this code is broken as well. We have to ignore partitions that don't
have any subpartitions. Patch is attached below (v2).
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Companydiff --git a/src/backend/catalog/partition.c b/src/backend/catalog
s bug hunt surely took a while: I
had to recheck all of the steps several times.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Companydiff --git a/src/backend/catalog/partition.c b/src/backend/catalog/partition.c
index 219d380..119a41d 100644
--- a/src/
to be something where you can get something done quickly, with
the hope of getting it into v10?
Yes, I've just cleared my schedule in order to make this possible. I'll
bring in the patches ASAP.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via
tion elimination, so I
think I'm capable of developing something similar.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
> Hi hackers,
>
> I've found a typo in a comment to function LockHasWaitersRelation() [lmgr.c
> :
> 271, master branch]:
> >> This is a functiion to check
Attached a patch.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
Hi hackers,
I've found a typo in a comment to function LockHasWaitersRelation() [lmgr.c :
271, master branch]:
>> This is a functiion to check
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-h
ting to a local struct in a dead
> frame, which is an obvious UB. I've attached a patch which fixes this
> behavior in the aforementioned function, but there might be more errors
> like that elsewhere.
Forgot some curly braces, my bad. v2 attached.
--
Dmitry Ivanov
Postgres Professional: htt
in a dead
frame, which is an obvious UB. I've attached a patch which fixes this behavior
in the aforementioned function, but there might be more errors like that
elsewhere.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Companydiff --git a/src/backend/
There are some previously unnoticed errors in docs (master branch), this patch
fixes them.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Companydiff --git a/doc/src/sgml/textsearch.sgml b/doc/src/sgml/textsearch.sgml
index 930c8f0..78eaf74 100644
--- a/doc
er one.
After a brief but reasonable discussion with Teodor I've come up with a more
proper piece of code for phrase operator parsing. The patch is included below.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (
ocs, this is a
> > better one.
>
> After a brief but reasonable discussion with Teodor I've come up with a more
> proper piece of code for phrase operator parsing. The patch is included
> below.
Attached the patch. Sorry for the inconvenience.
--
Dmitry Ivanov
Postgres Professi
> It seems that everything is settled now, so here's the patch introducing the
> '<->' and '' operators. I've made the necessary changes to docs &
> regression tests.
I noticed that I had accidently trimmed whitespaces in docs, this is a better
one.
--
Dmitry Ivanov
Postgres
to add it to the
following commitfest later.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Companydiff --git a/contrib/tsearch2/expected/tsearch2.out b/contrib/tsearch2/expected/tsearch2.out
index 972f764..97379e7 100644
--- a/contrib/tsearch2/expected/tsearc
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.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgre
e it's worth the trouble. IMO these functions are relatively small
and we won't benefit from extracting the duplicate code.
> These functions was removed in 9acb9007de30b3daaa9efc16763c3bc6e3e0a92d.
> It seems that tsvector_op.c was not synchronized with the master.
Got it, thanks!
--
D
Hi Constantin,
I did a quick review of your patch, and here are my comments:
- This patch applies cleanly to the current HEAD (61d2ebdbf91).
- Code compiles without warnings.
- Currently there's no documentation regarding parallel gin build feature and
provided GUC variables.
- Built indexes
em
I think that my solution might fit better.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Dmitry Ivanov <d.iva...@postgrespro.ru> writes:
> > As of now there's no way to transfer the ownership of an object and all
> > its
> > dependent objects in one step. One has to manually alter the owner of each
> > object, be it a table, a schema or something
(excluding the 'information_schema' and some others) and their
contents, but this is a temporary limitation.
Feedback is welcome!
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Companydiff --git a/src/backend/catalog/dependency.c b/src/backend/catalog
to
> just straight-up error out?
stdbool.h defines the '_Bool' type. The standard says:
C99 and C11 §6.3.1.2/1 “When any scalar value is converted to _Bool, the
result is 0 if the value compares equal to 0; otherwise, the result is 1.”
It seems that MSVC's bool (_Bool) assignment complies to
This patch was originally developed by Teodor Sigaev and Oleg Bartunov in
2009, so all credit goes to them. Any feedback is welcome.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Companydiff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
in
Here's the patch with an 'array_elemtype' procedure which returns array's
element type as an oid. It should apply to the commit fc995b. I wasn't sure if
I shoud start a new thread.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Companydiff --git a/doc/src
using the 'array_in'
procedure which performs various sanity checks, including the element type
check. Thus it is not possible to insert an anyarray object which will cause
server death.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via
> That concern is exactly the reason why we never did this originally.
> In particular, emitting raw INSERTs into pg_statistic is just plain
> foolish; we have changed the rowtype of pg_statistic in the past and
> are likely to do so again. At a minimum we would need such a facility
> to be proof
, for example, a dedicated view for
the 'recovery.conf' file using a drastically simplified procedure written in C.
Also it would get easier to reload at least some settings from the
'recovery.conf' file at runtime.
Suggestions and comments are welcome.
--
Dmitry Ivanov
Postgres Professional: http
ially-formed recovery INSERTS for 'pg_statistic' in the 'binary-upgrade'
mode, thus allowing us to restore saved stats after an upgrade.
Conclusion
==
I've attached a tarball with sources so that anyone could try the extension.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro
33 matches
Mail list logo
