27;something', 'oldvalue');
> $$;
Yes, in that case, lacking PERFORM in SQL, nothing simple comes to
mind on how to return certain results and not others.
But if it was in an SQL function, it wouldn't return the rows of
"interesting_table" either. I think it would
SELECT * FROM cp_test3;
$$;
by which the two result sets would go back to the client again
without declaring explicit cursors.
Currently, it does not error out and no result set is sent.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
-
o think of something going forward.
Thanks to everyone who participated, and to everyone who have responded to my
nagging via the CF app email function. This is clearly an awesome community.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
more discussion as to exactly what
> the strategy for to_number() (and friends) is.
Based on this review, I am moving this patch to the next commitfest and will
update it to Ready for committer. There might, as you say, be more discussion
needed, but due to the lack of extensive such so far
-+
> id | integer | | not null |
> nextval('t1_id_seq'::regclass)
> height_cm | integer | | |
> height_in | integer | | | generated always as ()
> “""
Based on this review, and the errors noted in upthread in the previous review,
I’m marking this Returned with feedback. When an updated version of the patch
is ready, please re-submit it to an upcoming commitfest.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ncies in the naming strategy. For
> example, this function is called _equalDatabaseSpec(), but the
> struct is DBSpecName. I would suggest calling it DatabaseSpec or
> DbSpec throughout the patch.
Based on this review, and that there hasn’t been a new version submitted, I’m
marking this
ddNode. In this case new branch of the tree is
> added. And this new branch could probably be used by scans we made in the
> past. Therefore, you need to do predicate locking for internal pages too in
> order to detect all the possible conflicts.
Based on this review, I’ve marked thi
time from a
>> different session, so let's get that working first, and then see what
>> else we want to do.
>
> I understood and agreed. I'll post the first version patch of new
> design to next CF.
Closing this patch with Returned with feedback in this commitfes
e backup system
>>> can make it as durable as the WAL segments, etc.
>>
>> Well, in some not so rare cases users encrypt backups and send to S3.
>> And there is no system with CPUs that can handle that WAL parsing.
>> Currently, I'm considering mocking prototype
> On 07 Sep 2017, at 09:30, Daniel Gustafsson wrote:
>
>> On 06 Sep 2017, at 07:13, David Rowley wrote:
>>
>> On 6 September 2017 at 00:43, Daniel Gustafsson wrote:
>>> This patch was moved to the currently open Commitfest. Given the above
>>> comme
want to double-check that that is the case.
Based on the discussions in this thread, I’m marking this patch Returned with
feedback. Please re-submit a new version in an upcoming commitfest when ready.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
t more work on this patch,
which also hasn’t moved in the current commitfest, so marking it Returned with
Feedback. Please re-submit this work in a future commitfest when ready for a
new round of reviews.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t been
submitted, I’m marking this Returned with Feedback. Please re-submit the new
version in an upcoming commitfest when ready.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
’m marking this Returned with
Feedback. Please re-submit a new version in an upcoming commitfest.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ss or
resolve, and the fact that the patch has been without update during the CF, I’m
marking this Returned with Feedback. Please re-submit a new version of the
patch to a future commitfest.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
mping status to Ready for committer
based on the discussion in this thread.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
le to observe that the value of session_read_only
> changed after triggering failover once the standby server exited recovery
>
> When attempting to connect to a primary server with
> target_session_attrs=read-write, I was successful and when attempting to
> connect with targe
nch tap test patch get through, coverage tests should
> be added.
>
> Maybe the cache overflow could be counted, to allow for a possible warning
> message in the final report?
Since this patch has been Waiting for author and no update on this patch has
been posted during the commitfe
through this and had a few thoughts:
>
> I agree with your suggestions, I will try to produce a new patch before the
> end of the week.
This patch has been marked as Returned with Feedback as no new version has been
submitted. Please re-submit the new version of this patch to th
> On 28 Sep 2017, at 14:55, Yugo Nagata wrote:
>
> On Sun, 3 Sep 2017 22:47:10 +0200
> Daniel Gustafsson wrote:
>
> I have reviewed your latest patch.
>
> I can apply this to the master branch and build this successfully,
> and the behavior is as expected.
tor.
> If someone wants to watch the current progress monitor, you can use
> this test case as a example.
>
> [Terminal1]
> Run this query on psql:
>
> select * from pg_stat_progress_cluster; \watch 0.05
>
> [Terminal2]
> Run these queries on psql:
>
> drop ta
st
without being committed or rejected. Moving to the next commitfest, but since
it has bitrotted I’m moving it to Waiting for author.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ork on this for PG11.
This patch has been marked Ready for Committer in the current commitfest
without being committed or rejected. Moving to the next commitfest, but since
it has bitrotted I’m moving it to Waiting for author.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hacke
SRFs, and apply the patch thus gaining
> both consistency and a clean syntax at the expense of limited backward
> incompatibility.
>
> Arrays not considered; single-column composites might end up looking like
> scalars when presented to a (c) target.
>
> Hope this helps som
e recent commit
>> 7df2c1f8daeb361133ac8bdeaf59ceb0484e315a. I have verified that the
>> new test result is as expected.
>
> The latest patch again needs to be rebased. Find rebased patch
> attached with this email.
Moved to next commitfest, but changed to Waiting for author
;s
> going to take far longer than I thought.
>
> Regardless of that, I think the patch can move forward. I'm still
> planning to do the test at some point, but this patch shouldn't block
> on it.
This patch has been marked Ready for committer after review, but wasn’t
co
round it. So
> attached are a rebased versions for both 0001 and 0002, I have updated
> the messages as well to be more in-line with what is in HEAD for
> corrupted entries.
I’ve moved this to the next CF, but since this no longer applies cleanly I’ve
reset it to Waiting for author.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On 15 Sep 2017, at 16:19, Daniel Gustafsson wrote:
>
>> On 01 Sep 2017, at 13:44, Simon Riggs wrote:
>>
>> On 14 August 2017 at 23:58, Peter Eisentraut
>> wrote:
>>> On 2/28/17 02:39, Tsunakawa, Takayuki wrote:
>>>> The code for sto
ime to find out
> right design including FDWs support.
I’m marking this patch Returned with Feedback since it has been Waiting for
author during the commitfest without updates.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
space at the end of the executeStatement call line.
>
> The patch potentially interacts with other patches in the long and slow
> queue...
>
> As usual with pgbench there are no regression tests.
This patch has been Waiting for author during the commitfest without updates,
movi
> On 13 Sep 2017, at 01:24, Daniel Gustafsson wrote:
>
>> On 18 Apr 2017, at 05:13, Amos Bird wrote:
>>
>> Ah, thanks for the suggestions. I'll revise this patch soon :)
>
> Have you had a chance to revise the patch to address the review comments such
>
> On 15 Sep 2017, at 13:26, Daniel Gustafsson wrote:
>
>> On 01 Sep 2017, at 14:28, Aleksander Alekseev
>> wrote:
>>
>> The following review has been posted through the commitfest application:
>> make installcheck-world: not tested
>> Implements f
ing %s due to administrator command",
+ MyBgworkerEntry->bgw_type)));
Updating the status to “Ready for committer” with the discussion around missing
bgw_type left as a decision point for a committer.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers
> On 26 Sep 2017, at 10:51, Maksim Milyutin wrote:
>
> On 19.09.2017 11:09, Daniel Gustafsson wrote:
>
>> Removing reviewer Maksim Milyutin from patch entry due to inactivity and
>> community account email bouncing. Maksim: if you are indeed reviewing this
>>
all for your contributions to PostgreSQL!
Sincerely
Daniel Gustafsson
CFM201709
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
This is a useful feature. This isn't a
> design level review of the patch. I may get back to that later. But
> here are some assorted comments
> ..
Looking forward to further review on this patch, but based on this feedback I’m
moving this to Waiting for author.
cheers ./daniel
-
reviewing this
patch, then please update the community account and re-add to the patch entry.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
will move your patch
there.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On 16 Sep 2017, at 01:51, Alexander Korotkov
> wrote:
>
> On Tue, Sep 5, 2017 at 2:47 PM, Daniel Gustafsson <mailto:dan...@yesql.se>> wrote:
> > On 04 Apr 2017, at 14:58, David Steele > <mailto:da...@pgmasters.net>> wrote:
> >
> > On 4/
> On 15 Sep 2017, at 17:19, Robert Haas wrote:
>
> On Fri, Sep 15, 2017 at 10:15 AM, Daniel Gustafsson wrote:
>> Have you had a chance to look at this such that we can expect a rebased
>> version
>> of this patch during the commitfest?
>
> Frankly, I th
ode.
>
> One option if we do feel that way is that we could provide the
> old names as alternatives, thus not breaking external modules.
> But that seems like it's sabotaging the basic goal of improving
> consistency of naming.
>
> If there are not objections, I pl
too good offer to pass up on, can we expect a rebased patch
for the commitfest?
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to the next CF.
>
> This patch needs to be rebased for the upcoming commit fest.
Have you had a chance to look at this such that we can expect a rebased version
of this patch during the commitfest?
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
needs a major rebase.
Can we expect a rebased version of this patch for this commitfest? Since it’s
a rather large feature it would be good to get it in as early as we can in the
process.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
dtuple is used to frame the slot, if the
> returning clause is present. But in case of instead of triggers, the call
> is returned early as above and the framed old tuple is not used.
>
> Either change the logic of returning for instead of triggers, or remove
> the generation of oldtuple after instead triggers call execution.
Have you had a chance to work on this patch to address the above review?
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e before sending them to stats in function lazy_vacuum_rel(),
>
> /* report results to the stats collector, too */
> new_live_tuples = new_rel_tuples - vacrelstats->new_dead_tuples;
>
> The fix needs a correction here also. Or change the correction in
> laz
n:not tested
>
> Hi Craig,
>
> I'm afraid patches 0002 and 0003 don't apply anymore. Could you please
> resolve the conflicts?
>
> The new status of this patch is: Waiting on Author
Have you had a chance to look at rebasing this patch so we can get it furth
;--start" breaks the documentation build (missing
> slash on the closing tag).
This patch is "Waiting for Author” due to the above review comments from Peter
and Thomas. Do you think you will have time to address these shortly so we can
move this patch further in the process?
cheer
ou take a look at it and submit a new
version rebased on top of HEAD?
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
icism. Your (and everyone involved in this)
initiative is great and automation will no doubt make the CF process better.
We just need to finetune it a little to make it work for, as well as with, the
community.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
> +char *strtol_endptr = NULL
> And there are more than this one.
Like Michael said above, this patch no longer applies and have some whitespace
issues. The conflicts in applying are quite trivial though, so it should be
easy to create a new version. Do you plan to work on this during
since it's an existing bug from previous
> releases (and I have other open items to focus on).
I’m not entirely sure why this was flagged as "Waiting for Author” by the
automatic run, the patch applies for me and builds so resetting back to “Needs
review”.
Simon: do you think you wi
oesn’t seem to have been moved to this CF but was actually created here in
the first place. Reading this thread it seems like there is clear concensus on
the status though so changing to RWF.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nkly I don't
>>> think anyone should.
>
> This submission has been moved to CF 2017-07.
This patch was automatically marked as “Waiting for author” since it needs to
be updated with the macro changes in 2cd70845240087da205695baedab6412342d1dbe
to compile. Changing to using Tu
> On 18 Apr 2017, at 05:13, Amos Bird wrote:
>
> Ah, thanks for the suggestions. I'll revise this patch soon :)
Have you had a chance to revise the patch to address the review comments such
that the patch can move forward during this Commitfest?
cheers ./daniel
--
Sent via
approach with format.
>
> That would allow to simplify the code significantly and to share it between
> MARKDOWN and others. Also, the multiple "else if" list would be simplified by
> using strchr or the escaped_chars string.
This patch was moved into the current Commitfest marked “Waiting for author”
with the above review. Have you had a chance to work on it addressing the
review comments such that we can expect a new version within this CF?
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
from
the 201701 CF). Have you had the chance to address the review comments such
that there is an update expected within this CF?
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n this case please let me know.>
>
> With all due respect, it's hard not to see this as a disruption of the
> current CF. I agree automating the patch processing is a worthwhile
> goal, but we're not there yet and it seems somewhat premature.
>
> Let me e
are not necessarily done this way, or
at least not consistently. If only for that, having more
characters in the description before screen wrap should help
a bit. In the above example, I think with the new presentation
only the polish version wouldn't fit in 80 chars without
wrapping.
Best reg
most options in our syntax
are enclosed with (), like: SET (guc1 = x, guc2 = y) FOR SELECT ..;
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
never reviewed a patch before, there won’t be a better time to get
involved. Remember that everyones input is just as valuable, PostgreSQL is a
community effort!
Again, thank you for all the hard work so far.
cheers ./daniel, as CFM 201709
* The keen observer will have noted that some patches were
> On 06 Sep 2017, at 07:13, David Rowley wrote:
>
> On 6 September 2017 at 00:43, Daniel Gustafsson wrote:
>> This patch was moved to the currently open Commitfest. Given the above
>> comment, is the last patch in this thread still up for review, or are you
>> work
gt;
>> In short: we should make partition.h's copyright look like partition.c's
>> not vice versa.
>
> Attached patch does that.
This reminded me that I’d seen one of these before while hacking, and with some
grep and xargs abuse I spotted one more (there might be mor
> On 05 Sep 2017, at 18:37, Peter Eisentraut
> wrote:
>
> On 4/25/17 11:00, Daniel Gustafsson wrote:
>> Makes sense, assuming a “clean slate” to run on seems a reasonable assumption
>> for the test and it makes for simpler code in PostgresNode. Updated the
>>
to mark this MovedToNextCF, barring objections from
> committers willing to make it happen in this release.
Next CF has now become This CF, has there been any work on this highly sought
after patch? Would be good to get closure on this early in the v11 cycle.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
fest, and is marked as “Needs
review”. Based on this thread I will however change it to "waiting for author”,
since there seems to be some open questions. Has there been any new work done
on this towards a new design/patch?
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
or are you
working on a new version? Just to avoid anyone reviewing an outdated version.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gt;> No objections.
>
> This submission has been moved to CF 2017-07.
This CF has now started (well, 201709 but that’s what was meant in above), can
we reach closure on this patch in this CF?
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
e conditional locks. But I
> think this patch is a step to right direction.
Thanks for your review! Based on your review and conclusions, I’ve bumped the
status to “Ready for Committer”. If you believe another status would be more
appropriate, please go in an update.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t it's been really
>> some time since I looked at this patch...
>
> My point is hash-search on every tuple insertion should be evaded
> even if it happens rearely. Once it was a bit apart from your
> original patch, but in the latest patch the significant part
> (pending-sync hash) is revived from the original one.
This patch has followed along since CF 2016-03, do we think we can reach a
conclusion in this CF? It was marked as "Waiting on Author”, based on
developments since in this thread, I’ve changed it back to “Needs Review”
again.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On 17 Aug 2017, at 11:08, Daniel Gustafsson wrote:
>
>> On 16 Aug 2017, at 17:51, Tom Lane wrote:
>>
>> Heikki Linnakangas writes:
>>> This no longer works:
>>
>>> postgres=# CREATE TEXT SEARCH DICTIONARY public.simple_dict (
>&g
H_COUNT
The number of result rows to fetch and display at a time
(default: 0=unlimited)
etc..
To me that looks like a good trade-off: it eases the size constraints
for both the description and the name of the variable, at the cost
of consuming one more line per variable, but that's why
> On 03 Sep 2017, at 21:12, Magnus Hagander wrote:
>
> On Sun, Sep 3, 2017 at 8:55 PM, Daniel Gustafsson <mailto:dan...@yesql.se>> wrote:
>
> That leaves us back at parsing/scraping -committers and adding the mailthread.
> For this CF I can add the commits manuall
> On 02 Sep 2017, at 02:21, Thomas Munro wrote:
>
> On Fri, Jun 23, 2017 at 1:48 AM, Daniel Gustafsson wrote:
>> Good point. I’ve attached a new version which issues a NOTICE on truncation
>> and also addresses all other comments so far in this thread. Thanks a lot
>
> On 03 Sep 2017, at 19:33, Magnus Hagander wrote:
>
> On Sun, Sep 3, 2017 at 12:00 AM, Daniel Gustafsson <mailto:dan...@yesql.se>> wrote:
> > On 01 Sep 2017, at 15:40, Robert Haas > <mailto:robertmh...@gmail.com>> wrote:
> >
> > On Fri, Sep 1,
s well, this gets us off the
ground quickly.
Unless there are objections, I’ll ensure that this is maintained during this CF
as part of my commitfest tinkering.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> PostgreSQL.
>
> Depending on macOS TLS instead of OpenSSL has similar advantages, of
> course, just for a somewhat less common platform.
I think providing alternatives to OpenSSL on platforms where OpenSSL can’t be
relied on to be already available (Windows and macOS come to mind) would
use
Keychain files on top of plain PEM files, so I think we have to. That being
said, we should probably define a (as large possible) minimum set which applies
to all to ensure compatability between different frontends and backends.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-h
ne it before, and
the CF in question is rather large I wouldn’t mind it co-managing it with
someone as you mention.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On 19 Aug 2017, at 23:13, Thomas Munro wrote:
>
> On Sun, Aug 20, 2017 at 8:10 AM, Thomas Munro
> mailto:thomas.mu...@enterprisedb.com>> wrote:
>> On Fri, Aug 18, 2017 at 2:14 AM, Daniel Gustafsson wrote:
>>> Attached is an updated set of patches, rebased on t
In that case it would be up to the consumer of the data to handle required
case-folding for the expected input, so pg_strcasecmp or strcmp depending on
situation.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On 03 Aug 2017, at 19:27, Michael Paquier wrote:
>
> On Thu, Aug 3, 2017 at 12:02 PM, Daniel Gustafsson wrote:
>> In https://postgr.es/m/69db7657-3f9d-4d30-8a4b-e06034251...@yesql.se I
>> presented a WIP patch for adding support for the Apple Secure Transport SSL
>&
> On 03 Aug 2017, at 13:06, Heikki Linnakangas wrote:
>
> On 08/03/2017 01:02 PM, Daniel Gustafsson wrote:
>>
>> The frontend has support for using PEM files for certificates and keys. It
>> can
>> also look up the key for the certificate in a Keychain, or bot
./daniel
0002-WIP-Add-support-for-Apple-Secure-Transport-SSL-libra.patch
Description: Binary data
0001-Allow-running-SSL-tests-against-different-binaries.patch
Description: Binary data
securetransport_test.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
> On 27 Jul 2017, at 19:40, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 19 Jun 2017, at 17:32, Tom Lane wrote:
>>> So, if we're getting into enforcing consistency in describe.c, there's
>>> lots to do.
>
>> Addressed in attached
tently across these programs.
Since Ctrl-C’ing the program to terminate is not an error, I agree that it
should require verbose mode too. I took a look as well and concur with your
findings. Moving to Ready for Committer.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ut psql_error() was
the most prevelant option used, so went there for consistency as a starting
point for discussion. Also adds appropriate NULL deref check on pattern and
adds a not-found message in describePublications() which previously didn’t
print anything at all on not-found.
Hope there is
> On 22 Jun 2017, at 17:52, Dilip Kumar wrote:
>
> On Thu, Jun 22, 2017 at 7:18 PM, Daniel Gustafsson wrote:
>> Good point. I’ve attached a new version which issues a NOTICE on truncation
>> and also addresses all other comments so far in this thread. Thanks a lot
>
no difference, I was just not seeing that libpq already provides
this functionality...
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
> On 22 Jun 2017, at 17:02, Tom Lane wrote:
>
> Robert Haas writes:
>> On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson wrote:
>>> While reading I noticed that we allow multiple TO in ALTER
>>> EXTENSION
>>> UPDATE, and defer throwing a
> On 22 Jun 2017, at 10:24, Yugo Nagata wrote:
>
> On Thu, 22 Jun 2017 09:24:54 +0900
> Michael Paquier wrote:
>
>> On Wed, Jun 21, 2017 at 11:42 PM, Daniel Gustafsson wrote:
>>> The message is truncated in SetBackendCancelMessage() for safety, but
>>>
o those who really want to squeeze performance may tune it
for their network and workload.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
g from their 10g R2.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On 21 Jun 2017, at 16:30, Yugo Nagata wrote:
>
> On Wed, 21 Jun 2017 12:06:33 +0900
> Michael Paquier wrote:
>
>> On Tue, Jun 20, 2017 at 3:24 AM, Daniel Gustafsson wrote:
>>> The message is stored in a new shmem area which is checked when the session
>&
ther change.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index c3bd4f9..366f278 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -4656,6 +4656,526 @@
keep things simple a small buffer is kept per backend for the
message. If deemed too costly, keeping a central buffer from which slabs are
allocated can be done (but seemed rather complicated for little gain compared
to the quite moderate memory spend.)
cheers ./daniel
terminate_msg_v2.patch
Spotted one “paramter” typo and git grep found two more, patch attached with
s/paramter/parameter/ for these.
cheers ./daniel
typo-paramter.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
hatever value there is in there.
As an example of app requirement, if the app has to let a user create a
large object and a different user to delete it, this GUC must be on,
otherwise such a scenario is not allowed, as unlinking is not a grantable
privilege, just like drop table.
Best regards,
--
direction because allowing or disallowing
compound statements is a clear-cut thing, whereas making
a list of SQL constructs to cripple to mitigate bugs is more like opening
a Pandora box.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerit
Spotted s/fiedls/fields/ in src/interfaces/ecpg/pgtypeslib/datetime.c per the
attached patch.
cheers ./daniel
typo-ecpg_datetime.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
1 - 100 of 868 matches
Mail list logo
