The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Passed make check-world. Running make installcheck-world had 2
>
>
> Another way that I tested and it's working is to use
> https://www.bottlecaps.de/convert/ paste the postgresql grammar there
> and press "convert" and after press "view diagram".
>
I tried this out and I'm pleased to see that one of the outputs is xhtml +
SVG, because SVGs have hover-over
On Tue, Jun 22, 2021 at 6:08 PM Mike wrote:
> When running a VACUUM or CLUSTER command, the namespace name is not part
> of the emitted message.
>
> Using `vacuumdb` CLI tool recently with multiple jobs, I found that
> reading the output messages harder to match the relations with their
>
>
> > This is nice. Are there any parallelism capabilities?
>
> Yes. It defaults to number-of-cores processes, but obviously can also be
> specified explicitly. One very nice part about it is that it'd work
> largely the same on windows (which has practically unusable testing
> right now). It
A Case For Inlining Immediate Referential Integrity Checks
--
The following is an overview of how Postgres currently implemented
referential integrity, the some problems with that architecture, attempted
solutions for those problems, and a
>
> > It seems to me 1 (RI_PLAN_CHECK_LOOKUPPK) is still alive. (Yeah, I
> > know that doesn't mean the usefulness of the macro but the mechanism
> > the macro suggests, but it is confusing.) On the other hand,
> > RI_PLAN_CHECK_LOOKUPPK_FROM_PK and RI_PLAN_LAST_ON_PK seem to be no
> > longer
On Wed, Feb 10, 2021 at 8:33 AM Pavel Stehule
wrote:
> Hi
>
> Is there some reason why \copy statement (parse_slash_copy parser) doesn't
> support psql variables?
>
> Regards
>
> Pavel
>
I remember wondering about that when I was working on the \if stuff. I dug
into it a bit, but the problem
On Sun, Jan 24, 2021 at 6:51 AM Amit Langote
wrote:
> On Sun, Jan 24, 2021 at 11:26 AM Corey Huinker
> wrote:
> > On Sat, Jan 23, 2021 at 12:52 PM Zhihong Yu wrote:
> >>
> >> Hi,
>
> Thanks for the review.
>
> >> + for (i = 0; i < riin
On Sat, Jan 23, 2021 at 12:52 PM Zhihong Yu wrote:
> Hi,
>
> + for (i = 0; i < riinfo->nkeys; i++)
> + {
> + Oid eq_opr = eq_oprs[i];
> + Oid typeid = RIAttType(fk_rel, riinfo->fk_attnums[i]);
> + RI_CompareHashEntry *entry =
>
>
>
> I decided not to deviate from pk_ terminology so that the new code
> doesn't look too different from the other code in the file. Although,
> I guess we can at least call the main function
> ri_ReferencedKeyExists() instead of ri_PrimaryKeyExists(), so I've
> changed that.
>
I think
>
> I decided not to deviate from pk_ terminology so that the new code
> doesn't look too different from the other code in the file. Although,
> I guess we can at least call the main function
> ri_ReferencedKeyExists() instead of ri_PrimaryKeyExists(), so I've
> changed that.
>
I agree with
On Wed, Jan 13, 2021 at 1:03 PM Corey Huinker
wrote:
> In addition to that, a following case would be solved with this approach:
>> When many processes are referencing many tables defined foreign key
>> constraints thoroughly, a huge amount of memory will be consumed
>>
On Mon, Jan 18, 2021 at 9:45 PM Amit Langote
wrote:
> On Tue, Jan 19, 2021 at 2:47 AM Zhihong Yu wrote:
> >
> > Hi,
> > I was looking at this statement:
> >
> > insert into f select generate_series(1, 200, 2);
> >
> > Since certain generated values (the second half) are not in table p,
>
>
>
> In file included from
> /home/japin/Codes/postgresql/Debug/../src/include/postgres.h:47:0,
> from
> /home/japin/Codes/postgresql/Debug/../src/backend/utils/adt/ri_triggers.c:24:
> /home/japin/Codes/postgresql/Debug/../src/backend/utils/adt/ri_triggers.c:
> In function
>
> In addition to that, a following case would be solved with this approach:
> When many processes are referencing many tables defined foreign key
> constraints thoroughly, a huge amount of memory will be consumed
> regardless of whether referenced tables are partitioned or not.
>
> Attached the
On Mon, Nov 30, 2020 at 9:48 PM Tom Lane wrote:
> Corey Huinker writes:
> > Given that we're already looking at these checks, I was wondering if this
> > might be the time to consider implementing these checks by directly
> > scanning the constraint index.
>
&
>
> I think this can be solved easily in the patch, by having
> ri_BuildQueryKey() compare the parent's fk_attnums to the parent; if
> they are equal then use the parent's constaint_id, otherwise use the
> child constraint. That way, the cache entry is reused in the common
> case where they are
>> One limitation of this approach is that \set can't span lines, so
>> writing complex queries would be kinda painful. But that would
>> be a good limitation to address separately; \set isn't the only
>> metacommand where can't-span-lines is a problem sometimes.
>> If you seriously want to
>
> I'm sure there's a lot of folks who'd like to see more of the logic we
> have in pg_dump for building objects from the catalog available to more
> tools through libpgcommon- psql being one of the absolute first
> use-cases for exactly that (there's certainly no shortage of people
> who've
>
>
> >
> > Please do list Jürgen, Corey and Roger as authors of the glossary.
>
> (Actually I should be listed as well, as the time I spent on it was
> considerable.)
>
+1, the time spent was quite considerable
>
>
> > Perhaps something like this would be more readable
> >
> > WITH t AS (
> >UPDATE ( SELECT 1 AS ctr, 'x' as val )
> >SET ctr = ctr + 1, val = val || 'x'
> >WHILE ctr <= 100
> >RETURNING ctr, val
> > )
> >
> > The notion of an UPDATE on an ephemeral subquery isn't that
On Wed, Apr 29, 2020 at 3:15 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> Why are all the glossary terms capitalized? Seems kind of strange.
>
>
They weren't intended to be, and they don't appear to be in the page I'm
looking at. Are you referring to the anchor like in
On Wed, Apr 29, 2020 at 10:34 AM Jonah H. Harris
wrote:
> On Wed, Apr 29, 2020 at 7:22 AM Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
>> Yeah the RECURSIVE vs ITERATIVE is a bit of a red herring here. As you
>> say, the RECURSIVE keyword doesn't specify the processing but
On Wed, Apr 22, 2020 at 2:36 PM Andres Freund wrote:
> Hi,
>
> On 2020-04-22 13:46:22 -0400, Robert Haas wrote:
> > On Wed, Apr 22, 2020 at 1:18 PM Alvaro Herrera
> wrote:
> > > Well, I was actually thinking in building ready-made execution trees,
> > > bypassing the planner altogether. But
>
> I can imagine removal of the SPI from the current implementation (and
> constructing the plans "manually"), but note that the queries I use in my
> patch are no longer that trivial. So the SPI makes sense to me because it
> ensures regular query planning.
>
As an intermediate step, in the
>
> Yeah, back at the beginning of this exercise, Alvaro wondered aloud
> if we should go to something other than tables altogether. I dunno
> what that'd look like though.
>
It would probably look like our acronyms and glossary pages.
Maybe the return example and return values get replaced
>
> Thinking out loud, it'd also be great if we could add in some anchors as
> well, so perhaps in the future on the pgweb side we could add in some
> discoverable links that other documentation has -- which in turn people
> could click / link to others directly to the function name.
>
+1
>
>
> Term 'relation': A sequence is internally a table with one row - right?
> Shall we extend the list of concrete relations by 'sequence'? Or is this
> not necessary because 'table' is already there?
>
I wrote one for sequence, it was a bit math-y for Alvaro's taste, so we're
going to try
On Wed, Apr 8, 2020 at 1:06 PM Pavel Stehule
wrote:
>
>
> st 8. 4. 2020 v 18:36 odesílatel Antonin Houska napsal:
>
>> After having reviewed [1] more than a year ago (the problem I found was
>> that
>> the transient table is not available for deferred constraints), I've
>> tried to
>> implement
On Sat, Apr 4, 2020 at 2:55 AM Fabien COELHO wrote:
>
> > BTW it's now visible at:
> > https://www.postgresql.org/docs/devel/glossary.html
Nice. I went looking for it yesterday and the docs hadn't rebuilt yet.
> ISTM that occurrences of these words elsewhere in the documentation should
>
>
> we have it, we can start thinking of patching the main part of the docs
> to make reference to it by using in key spots. Right now
> the glossary links to itself, but it makes lots of sense to have other
> places point to it.
>
I have some ideas about how to patch the main docs, but will
On Thu, Apr 2, 2020 at 8:44 AM Jürgen Purtz wrote:
> +1 and many thanks to Alvaros edits.
>
>
I did some of the grunt work Alvaro alluded to in v6, and the results are
attached and they build, which means there are no invalid links.
Notes:
* no definition wordings were changed
* added a linkend
>
> I propose we define "planner" and make "optimizer" a entry.
>
I have no objection to more entries, or edits to entries, but am concerned
that the process leads to someone having to manually merge several
start-from-scratch patches, with no clear sense of when we'll be done. I
may make sense
>
> 2. I found out that "see xyz" and "see also" have bespoke markup in
> Docbook -- and . I changed some glossentries
> to use those, removing some glossdefs and changing a couple of paras to
> glossseealsos. I also removed all "id" properties from glossentries
> that are just , because I
On Tue, Mar 31, 2020 at 2:09 PM Justin Pryzby wrote:
> On Sun, Oct 13, 2019 at 04:52:05PM -0400, Corey Huinker wrote:
> > 1. It's obviously incomplete. There are more terms, a lot more, to add.
>
> How did you come up with the initial list of terms ?
>
1. I asked some new
On Sun, Mar 29, 2020 at 5:29 AM Jürgen Purtz wrote:
> On 27.03.20 21:12, Justin Pryzby wrote:
> > On Fri, Mar 20, 2020 at 11:32:25PM +0100, Jürgen Purtz wrote:
> +Archiver
> >>> Can you change that to archiver process ?
> >> I prefer the short term without the addition of 'process' -
>
>
> > > + Records to the file system and creates a special
> >
> > Does the chckpointer actually write WAL ?
>
> Yes.
>
> > An FK doesn't require the values in its table to be unique, right ?
>
> I believe it does require that the values are unique.
>
> > I think there's some confusion.
>
> Perhaps this is what you mean by "deterministic", but isn't it
> possible for some collations to treat multiple byte sequences as equal
> values? And those multiple byte sequences wouldn't necessarily occur
> sequentially in C collation, so it wouldn't be possible to work around
> that by
On Fri, Mar 20, 2020 at 6:32 PM Jürgen Purtz wrote:
> man pages: Sorry, if I confused someone with my poor English. I just
> want to express in my 'offline' mail that we don't have to worry about
> man page generation. The patch doesn't affect files in the /ref
> subdirectory from where man
>
> It's hard to review work from a professional tech writer. I'm under the
> constant impression that I'm ruining somebody's perfect end product,
> making a fool of myself.
If it makes you feel better, it's a mix of definitions I wrote that Roger
proofed and restructured, ones that Jürgen had
>
> Jürgen mentioned off-list that the man page doesn't build. I was going to
>> look into that, but if anyone has more familiarity with that, I'm listening.
>>
>
Looking at this some more, I'm not sure anything needs to be done for man
pages. man1 is for executables, man3 seems to be dblink and
On Thu, Mar 19, 2020 at 8:11 PM Alvaro Herrera
wrote:
> I gave this a look. I first reformatted it so I could read it; that's
> 0001. Second I changed all the long items into s, which
>
Thanks! I didn't know about xrefs, that is a big improvement.
> are shorter and don't have to repeat the
On Fri, Mar 13, 2020 at 12:18 AM Jürgen Purtz wrote:
>
> The statement that names of schema objects are unique isn't *strictly* true,
> just *mostly* true. Take the case of a unique constraints.
>
> Concerning CONSTRAINTS you are right. Constraints seems to be an exception:
>
>- Their name
>
>
> * Transaction - yes, all those things could be "visible" or they could be
> "side effects". It may be best to leave the over-simplified definition in
> place, and add a "For more information see < tutorial-transactions>>
>
transaction-iso would be a better linkref in this case
>
> It will be helpful for diff-ing to restrict the length of lines in the
> SGML files to 71 characters (as usual).
I did it that way for the following reasons
1. It aids grep-ability
2. The committers seem to be moving towards that for SQL strings, mostly
for reason #1
3. I recall that the
On Wed, Mar 11, 2020 at 12:50 PM Jürgen Purtz wrote:
> I made changes on top of 0001-add-glossary-page.patch which was supplied
> by C. Huinker. This affects not only terms proposed by me but also his
> original terms. If my changes are not obvious, please let me know and I
> will describe my
e can link to the glossary from
outside if we so choose.
I encourage everyone to read the definitions, and suggest fixes to any
inaccuracies or awkward phrasings. Mostly, though, I'm seeking feedback on
the structure itself, and hoping to get that committed.
On Tue, Feb 11, 2020 at 11:22 PM Cor
>
> So, as with Jesse's example, what I'm wondering is whether or not 2to3
> will fix that for you (or even flag it). The basic difference between
> the two alternatives I suggested is whether we force people to put their
> python function through that converter before we'll even try to run it.
>
>
> A possible gotcha in this approach is if there are any python 2/3
> incompatibilities that would not manifest as syntax errors or
> obvious runtime errors, but would allow old code to execute and
> silently do the wrong thing. One would hope that the Python crowd
> weren't dumb enough to do
ventually found the time to take a second
pass at this.
Attached is a revised patch.
From f087e44fe4db7996880cf4df982297018d444363 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Wed, 12 Feb 2020 04:17:59 +
Subject: [PATCH] add glossary page with initial definitions
---
doc/src/sgml/filelist.sg
's probably some
spacing/padding issues I haven't thought of. Please try it out, make some
modifications to existing document pages to see how badges would work in
those contexts.
From ded965fc90b223a834ac52d55512587b7a6ea139 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Fri, 18 Oct 2019 0
that have different definitions
in different contexts. Should that be two glossdefs following one
glossterm, or two separate def/term pairs?
Please review and share your thoughts.
From 343d5c18bf23f98341b510595e3e042e002242cb Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Sun, 13 Oct 2019 17:57:36
>
>
> >- @> contains range/element
> >- <@ element/range is contained by
>
I'm not a heavy user or range types, so I can't really judge how useful
> that is in practice, but it seems like a fairly natural extension of the
> existing operators. I mean, if I understand it correctly, the proposed
>
>
>
> > The people who expressed opinions on nuking triggers from orbit (it's
> the only way to be sure) have yet to offer up any guidance on how to
> proceed from here, and I suspect it's because they're all very busy getting
> things ready for v12. I definitely have an interest in working on
>
> It seems this topic is ongoing so I've moved it to the September CF,
> but it's in "Waiting on Author" because we don't have a concrete patch
> that applies (or agreement on what it should do?) right now.
>
All recent work has been investigating the need(s) we're trying to address.
This is as
>
> I should probably split this into "actionable" (categories 3 and 4)
> and "noise and scaffolding" patches.
>
Breaking down the noise-and-scaffolding into some subgroups might make the
rather long patches more palatable/exceedingly-obvious:
* (Datum) 0 ---> NullDatum
* 0 > NullDatum
* The
On Fri, Jul 5, 2019 at 12:32 PM David Fetter wrote:
> Folks,
>
> Corey Huinker put together the documentation for this proposed
> feature. Does this seem like a reasonable way to do it?
>
>
In doing that work, it became clear that the command was serving two
masters:
>
> > So what is the uptake on implementing this at the server side, ie.
> > DESCRIBE?
>
> I'm pretty skeptical of this idea, unless you are willing to throw
> away at least one and possibly both of the following goals:
>
> 1. Compatibility with psql's existing \d behavior.
>
I don't think
>
> The thing that most approaches to this have fallen down on is triggers ---
> that is, a trigger function might access columns mentioned nowhere in the
> SQL text. (See 8b6da83d1 for a recent example :-() If you have a plan
> for dealing with that, then ...
>
Well, if we had a trigger
For CTEs, is forcing inlining the example we want to give, rather than the
example of forcing materialization given?
According to the docs, virtual generated columns aren't yet supported. I'm
pretty sure the docs are right. Do we still want to mention it?
Otherwise it looks good to me.
On Tue,
>
>
>> Is there anything preventing us from having the planner resolve object
>> names from strings?
>>
>
> The basic problem is fact so when you use PREPARE, EXECUTE protocol, you
> has not parameters in planning time.
>
I agree that it defeats PREPARE as it is currently implemented with
>
>
> You can pass table name as text or table object id as regclass type.
>
> inside procedure you should to use dynamic sql - execute statement.
> Generally you cannot to use a variable as table or column name ever.
>
> Dynamic SQL is other mechanism - attention on SQL injection.
>
On this
>
> One question is how to aggregate ranges that would leave gaps and/or
> overlaps. So in my extension there is a one-param version that forbids
> gaps & overlaps, but I let you permit them by passing extra parameters,
> so the signature is:
>
Perhaps a third way would be to allow and preserve
>
>
>\warn ...
>\warning ...
>
These two seem about the best to me, drawing from the perl warn command.
I suppose we could go the bash &2 route here, but I don't want to.
On Sun, Mar 31, 2019 at 5:04 PM Andres Freund wrote:
> On 2019-04-01 09:52:34 +1300, Thomas Munro wrote:
> > +/*
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software
On Thu, Mar 28, 2019 at 6:49 PM Peter Geoghegan wrote:
> On Thu, Mar 28, 2019 at 3:46 PM Jeremy Schneider
> wrote:
> > We're just gearing up for the Google Season of Docs and I think this
> > would be a great task for a doc writer to help with. Any reason to
> > expect serious objections to
(moving this over from pgsql-performance)
A client had an issue with a where that had a where clause something like
this:
WHERE 123456 = ANY(integer_array_column)
I was surprised that this didn't use the pre-existing GIN index on
integer_array_column, whereas recoding as
WHERE ARRAY[123456]
On Mon, Mar 4, 2019 at 1:45 PM Corey Huinker
wrote:
>
>>> - Tab completion for \descibe-verbose.
>>> I know that \d+ tab completion is also not there, but I think we must
>>> have tab completion for \descibe-verbose.
>>>
>>> postgres=# \
>
>
> I agree with Andres and Robert. This patch should be pushed to PG13.
>
> I'll do that on March 8 unless there is a compelling argument not to.
>
>
No objection. I'll continue to work on it, though.
>
>
>> - Tab completion for \descibe-verbose.
>> I know that \d+ tab completion is also not there, but I think we must
>> have tab completion for \descibe-verbose.
>>
>> postgres=# \describe-
>> \describe-extension
>> \describe-replication-publication \describe-user-mapping
>>
>
>
> In order to avoid per-row calls of the constraint trigger functions, we
> could
> try to "aggregate" the constraint-specific events somehow, but I think a
> separate queue would be needed for the constraint-specific events.
>
> In general, the (after) triggers and constraints have too much
>
> Right, this makes a lot of sense, similar to how ri_restrict() combines
> RESTRICT and NO ACTION.
>
I'm pretty sure that's where I got the idea, yes.
>
> Given that this patch has been added to the last commitfest for v12, I
> think we should mark it as targeting 13, so it can be skipped over by
> people looking to get things into v12. Even leaving fairness aside, I
> don't think it's likely to be ready quickly enough...
>
Obviously this
On Fri, Feb 22, 2019 at 1:12 PM Corey Huinker
wrote:
> On Fri, Feb 22, 2019 at 11:05 AM Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
>> ri_triggers.c is endlessly long and repetitive. I want to clean it up a
>> bit (more).
>>
>
> H
On Fri, Feb 22, 2019 at 11:05 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> ri_triggers.c is endlessly long and repetitive. I want to clean it up a
> bit (more).
>
Having just been down this road, I agree that a lot of cleanup is needed
and possible.
> I looked into all
>
>
> While the idea to use the transition table is good, this approach probably
> requires the trigger engine (trigger.c) to be adjusted, and that in a
> non-trivial way.
>
It probably does. Several people with advanced knowledge of trigger.c
expressed a desire to rebuild trigger.c from the
> Otherwise "\g -" looks good as a portable solution.
+1
e've got wins all around.
>
> Best,
> David.
> --
> David Fetter http://fetter.org/
> Phone: +1 415 235 3778
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
>
From e67e61ae789b09c98fe03378c819224d838c2f65 Mon Sep 17
Attached is a patch that refactors DELETE triggers to fire at the statement
level.
I chose delete triggers partly out of simplicity, and partly because there
some before/after row linkage in the ON UPDATE CASCADE cases where
statement level triggers might not be feasible as we have currently
On Fri, Jan 4, 2019 at 7:49 AM Peter Eisentraut
wrote:
>
> On 25/12/2018 00:56, Corey Huinker wrote:
> > The regression diff (attached) seems to imply that the triggers simply
> > are not firing, though.
>
> The reason for this was explained by Dean. If you take out the c
| 0 || \x ||
| pg_inserted_transition_table
(2 rows)
Any idea where I went wrong?
On Mon, Dec 17, 2018 at 9:56 AM Corey Huinker
wrote:
> In digging around the codebase (see thread: Referential Integrity Checks
> with Statement-level Triggers), I noticed that
In digging around the codebase (see thread: Referential Integrity Checks
with Statement-level Triggers), I noticed that unique constraints are
similarly enforced with a per-row trigger.
The situation with unique indexes is fairly similar to the situation with
RI checks: there is some overhead to
Back when Pg added statement-level triggers, I was interested in the
potential promise of moving referential integrity checks to statement-level
triggers.
The initial conversation, along with Kevin Grittner's POC script (in SQL)
that showed a potential for a 98% reduction in time spent doing RI
On Sun, Nov 25, 2018 at 11:23 PM Tom Lane wrote:
> Corey Huinker writes:
> > Could we have another output type called "separated" that uses the
> existing
> > --fieldsep / --recordsep?
>
> Uh, what's the difference from the existing unaligned format?
>
No f
>
>
> Or we could kill both issues by hard-wiring the separator as ','.
+1
I've never encountered a situation where a customer wanted a custom
delimiter AND quoted strings. So either they wanted pure CSV or a customed
TSV.
Could we have another output type called "separated" that uses the
>
> >>psql> \if :i >= 5
> >>
> > I think we're ok with that so long as none of the operators or values
> has a
> > \ in it.
> > What barriers do you see to re-using the pgbench grammar?
>
> The pgbench expression grammar mimics SQL expression grammar,
> on integers, floats, booleans & NULL.
>
>
> > 3. Radical alternative: Collapse everything into one new column. We
> > could combine atthasdef and attgenerated and even attidentity into a new
> > column. (Only one of the three can be the case.) This would give
> > client code a clean break, which may or may not be good. The
> >
>
>
> > 1. it seems that we will continue to to per-row RI checks for inserts and
> > updates. However, there already exists a bulk check in
> RI_Initial_Check().
> > Could we modify this bulk check to do RI checks on a per-statement basis
> > rather than a per-row basis?
>
> One of the goals when
On Fri, Nov 2, 2018 at 7:42 PM Alvaro Herrera
wrote:
> Here's a patch to allow partitioned tables to be referenced by foreign
> keys. Current state is WIP, but everything should work; see below for
> the expected exception.
>
> The design is very simple: have one pg_constraint row for each
>
>
> > SELECT x.a, sum(x.b)
> > FROM ( COPY INLINE '/path/to/foo.txt' FORMAT CSV ) as x( a integer, b
> numeric, c text, d date, e json) )
>
> Apologies for bike-shedding, but wouldn't the following be a better
> fit with the current COPY?
>
> COPY t(a integer, b numeric, c text, d date, e
>
> > Are you thinking something like having a COPY command that provides
> > results in such a way that they could be referenced in a FROM clause
> > (perhaps a COPY that defines a cursor…)?
>
> That would also be nice, but what I was thinking of was that some
> highly restricted subset of cases
>
> >> A use case that I see quite a lot of is needing to do reports and other
> >> calculations on data per day/hour/etc but in the user's time zone. The
> >> way to do that is fairly trivial, but it's not obvious what it does so
> >> reading queries becomes just a little bit more difficult.
>
>
>
> I think the code needs to be split up so that CopyFrom() in the loop
> body calls CopyFromOneTuple(), which then also splits out the tuple
> routing into its own CopyFromOneTupleRoute() function (that's 200 LOC on
> its own...). I suspect it'd also be good to refactor the
> partition-change
On Thu, Oct 11, 2018 at 5:04 AM Surafel Temesgen
wrote:
>
>
> On Thu, Oct 11, 2018 at 12:00 PM Christoph Moench-Tegeder <
> c...@burggraben.net> wrote:
>
>> You can:
>> COPY ( query ) TO 'filename';
>>
> it is for COPY FROM
>
> regards
> Surafel
>
It didn't get far, but you may want to take a
On Wed, Oct 10, 2018 at 1:44 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tuesday, October 9, 2018, Imai, Yoshikazu <
> imai.yoshik...@jp.fujitsu.com> wrote:
>>
>> Are there any rows which can satisfy the ct's CHECK constraint? If not,
>> why we
>> allow creating table when
On Mon, Sep 10, 2018 at 3:28 AM Hannu Krosing
wrote:
> Hi Corey
>
> Have you looked at pl/proxy ?
>
I have, a long while ago.
> It does this and then some (sharding)
>
PL/proxy isn't a part of the SQL Standard.
PL/proxy only connects to other libpq-speaking databases.
The hope with routine
>
> You appear to be saying that you think that renaming an index
> concurrently is not safe. In that case, this patch should be rejected.
> However, I don't think it necessarily is unsafe. What we need is some
> reasoning about the impact, not a bunch of different options that we
> don't
>
>
>psql> \if :i >= 5
>
>
I think we're ok with that so long as none of the operators or values has a
\ in it.
What barriers do you see to re-using the pgbench grammar?
>
> Hope it is useful or interesting for someone! Questions or comments are
>> very welcome.
>>
>
> good idea.
>
> Regards
>
> Pavel
>
In a recent PgConf NYC presentation [1] I was talking about the technical
hurdles to implementing materialized views that could be kept up to date at
all times,
On Mon, Apr 30, 2018 at 7:05 AM Pierre Ducroquet <
pierre.ducroq...@people-doc.com> wrote:
> On Monday, April 30, 2018 1:01:25 PM CEST Daniel Verite wrote:
> > Corey Huinker wrote:
> > > As of v11, DO blocks can do transactions. I think this will meet your
> >
201 - 300 of 308 matches
Mail list logo
