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
egatively affected, they'd be
rightfully 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 vanil
ly working on a prototype of partition pruning. It 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 Prof
while, Append will behave as it
should, since it doesn't care about 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
custom_scan_tlist'
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)
override behavior of use_physical_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?
TRUNCATE 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/
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/ca
k it must be rewritten. This 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 219d
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 Compan
m node for run-time partition 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
> 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 Co
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 (pg
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 Profess
truct 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/sr
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
s in docs, 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.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Se
y trimmed whitespaces in docs, 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.
--
> 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
on
equested. I'm going 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
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.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russi
for it.
I'm not sure 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
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
ired by the database system
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 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 else.
>
> TBH, this
ange, since there's no way to get the full list of objects that
depend on a given database. Currently the code changes ownership of all
schemas (excluding the 'information_schema' and some others) and their
contents, but this is a temporary limitation.
Feedback is welcome!
piler 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) ass
#x27;postgres has taken severe damage') @@
phraseto_tsquery('severely damaged');
?column?
--
t
(1 row)
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 Profes
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 Co
ay' type are deserialized 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
> 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
them to the GUC, perhaps with a special context.
Both approaches would allow us to create, 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.con
---
DB=# \copy (select dump_statistic()) to 'stat_backup.sql'
$ psql DB < stat_backup.sql
Proposed changes to pg_dump
===
Now that the approach has been developed, it may be applied to improve the
'pg_dump' utility. Some minor code changes woul
33 matches
Mail list logo
