On 2019-Jun-01, Tom Lane wrote:
> Alvaro Herrera writes:
> > I ended up with these two patches. I'm not sure about pushing
> > separately. It seems pointless to backport the "fix" to back branches
> > anyway.
>
> Patch passes the eyeball test, though I did not try to run it.
> I concur with sq
On 2019-Jun-02, Michael Meskes wrote:
> On Thu, 2019-05-30 at 17:54 -0400, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Or do we just not want this test to be run by default, and thus I
> > > should add "make -C src/interfaces/ecpg/test checktcp" to
> > > coverage.pg.org's shell script?
> >
On Thu, 2019-05-30 at 17:54 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Apparently, for ecpg you have to do "make checktcp" in order for
> > some of
> > the tests to run, and "make check-world" doesn't do that. Not sure
> > what's a good fix for this; do we want to add "make -C
> > src/in
On Sat, Jun 01, 2019 at 12:19:43PM -0700, Andres Freund wrote:
> Yea, I think we should do that at some point. But I'm not sure this is
> the right design. Bulk insert probably needs to rather be something
> that's allocated inside the AM.
Yeah, actually you may be right that I am not taking the c
On 2019-06-01 15:41:29 -0400, Michael Paquier wrote:
> On Sat, Jun 01, 2019 at 12:25:29PM -0700, Andres Freund wrote:
> > I don't think these are bugs. I'm fine with adding those for 12, but I
> > don't think it's needed.
>
> I would just fix both. Once you apply the filtering of access AMs for
>
On 2019-06-01 15:37:43 -0400, Michael Paquier wrote:
> On Sat, Jun 01, 2019 at 12:22:10PM -0700, Andres Freund wrote:
> > On 2019-06-01 15:09:46 -0400, Michael Paquier wrote:
> >> While going through the table AM callbacks, I have bumped into a
> >> couple of references to heap. I think that we
On Sat, Jun 01, 2019 at 12:25:29PM -0700, Andres Freund wrote:
> I'm not sure I understand starting 10 threads about approximately the
> same topic. That seems purely confusing.
Well, each topic is separated IMO and has a separate patch, so I just
wanted to keep the discussion of each issue clear.
On Sat, Jun 01, 2019 at 12:22:10PM -0700, Andres Freund wrote:
> On 2019-06-01 15:09:46 -0400, Michael Paquier wrote:
>> While going through the table AM callbacks, I have bumped into a
>> couple of references to heap. I think that we should make that more
>> generic by using the term "table" as d
On Wed, May 29, 2019 at 02:26:50PM +0200, Gilles Darold wrote:
> Attached is a patch that fix this description. As CHECK OPTION is supported
> since 9.4, the patch might be applied on all versions since 9.4.
Thanks Gilles! Applied and back-patched.
--
Michael
signature.asc
Description: PGP sign
Hi,
I'm not sure I understand starting 10 threads about approximately the
same topic. That seems purely confusing.
On 2019-06-01 15:10:07 -0400, Michael Paquier wrote:
> I have bumped into a couple of issues with psql completion for access
> methods:
> 1) CREATE INDEX USING suggests both index an
Hi,
On 2019-06-01 15:09:46 -0400, Michael Paquier wrote:
> While going through the table AM callbacks, I have bumped into a
> couple of references to heap. I think that we should make that more
> generic by using the term "table" as done when opening relations and
> such. Attached is a cleanup p
Hi,
On 2019-06-01 15:09:24 -0400, Michael Paquier wrote:
> I have been playing lately with the table AM API to do some stuff, and
> I got surprised that in the minimum set of headers which needs to be
> included for a table AM we have a hard dependency with heapam.h for
> BulkInsertState and vacuu
Hi all,
I have bumped into a couple of issues with psql completion for access
methods:
1) CREATE INDEX USING suggests both index and table AMs.
2) CREATE TABLE USING has no completion support, USING not being
included in the completion, and the follow-up table AMs are missing as
well.
3) CREATE AC
Hi all,
I have been playing lately with the table AM API to do some stuff, and
I got surprised that in the minimum set of headers which needs to be
included for a table AM we have a hard dependency with heapam.h for
BulkInsertState and vacuum.h for VacuumParams.
I am fine to live with the depende
Hi all,
While going through the table AM callbacks, I have bumped into a
couple of references to heap. I think that we should make that more
generic by using the term "table" as done when opening relations and
such. Attached is a cleanup patch.
While on it, I found a set of typos which looked l
Jeremy Finzel writes:
> I've not submitted a patch before, and have a few suggestions I'd like
> feedback on before I write one (for the docs only).
OK ...
> First, even this summary looks untrue:
> REFRESH MATERIALIZED VIEW — replace the contents of a materialized view.
Agreed. I'd just make
Alvaro Herrera writes:
> I ended up with these two patches. I'm not sure about pushing
> separately. It seems pointless to backport the "fix" to back branches
> anyway.
Patch passes the eyeball test, though I did not try to run it.
I concur with squashing into one commit and applying to HEAD on
> On Sat, Jun 1, 2019 at 5:34 PM Floris Van Nee
> wrote:
>
> I did a little bit of investigation and it seems to occur because in
> pathkeys.c the function pathkey_is_redundant considers pathkeys redundant if
> there is an equality condition with a constant in the corresponding WHERE
> clause.
>
Hi,
Thanks for the helpful replies.
> Yes, good catch, I'll investigate. Looks like in the current implementation
> something is not quite right, when we have this order of columns in an index
> and where clause (e.g. in the examples above everything seems fine if we
> create
> index over (fee
Hi,
We had a short conversation about this on Friday but I didn't have time
to think of a constructive suggestion, and now I've had more time to
think about it.
Regarding the proposed PG 13 jsonpath extensions (array, map, and
sequence constructors, lambdas, map/fold/reduce, user-defined
function
On 05/31/19 16:04, Alvaro Herrera wrote:
> https://www.iso.org/standard/41528.html "XQuery Regular Expression
> Support in SQL"
Although I hadn't seen that particular document, I did see those in the
SQL spec and mention them in the wiki page [1].
I should point out that's also a conformance not
> On Sat, Jun 1, 2019 at 6:10 AM Floris Van Nee
> wrote:
>
> After some talks with Jesper at PGCon about the Index Skip Scan, I started
> testing this patch, because it seems to have great potential in speeding up
> many of our queries (great conference by the way, really enjoyed my first
> time
On Sat, 1 Jun 2019 at 06:10, Floris Van Nee wrote:
>
> Actually I'd like to add something to this. I think I've found a bug in the
> current implementation. Would someone be able to check?
>
I am willing to give it a try.
> Given a table definition of (market text, feedcode text, updated_at
> ti
23 matches
Mail list logo
