public inbox for [email protected]
help / color / mirror / Atom feedRe: Changing the autovacuum launcher scheduling; oldest table first algorithm
84+ messages / 16 participants
[nested] [flat]
* Re: Changing the autovacuum launcher scheduling; oldest table first algorithm
@ 2018-11-29 17:21 Dmitry Dolgov <[email protected]>
2018-11-30 01:48 ` Re: Changing the autovacuum launcher scheduling; oldest table first algorithm Michael Paquier <[email protected]>
0 siblings, 1 reply; 84+ messages in thread
From: Dmitry Dolgov @ 2018-11-29 17:21 UTC (permalink / raw)
To: Masahiko Sawada <[email protected]>; +Cc: Michael Paquier <[email protected]>; [email protected]; pgsql-hackers; [email protected]; [email protected]
> On Tue, Oct 2, 2018 at 4:42 AM Michael Paquier <[email protected]> wrote:
>
> On Thu, Jun 28, 2018 at 04:20:53PM +0900, Masahiko Sawada wrote:
> > If there is an up-to-date information meaning either that there is no
> > tables needing vacuum or that there is only table needing vacuum but
> > being vacuumed by other worker, AV launcher can launches new one to
> > other database.
>
> I am not completely sure what we want to do with this patch in
> particular as there are many approaches and things which can be
> discussed. For now, the latest patch proposed does not apply, so I am
> moving it to next CF, waiting for its author.
Nothing changed since then, but also the patch got not enough review to say
that there was substantial feedback. I'll move it to the next CF.
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Changing the autovacuum launcher scheduling; oldest table first algorithm
2018-11-29 17:21 Re: Changing the autovacuum launcher scheduling; oldest table first algorithm Dmitry Dolgov <[email protected]>
@ 2018-11-30 01:48 ` Michael Paquier <[email protected]>
2018-11-30 02:00 ` Re: Changing the autovacuum launcher scheduling; oldest table first algorithm Masahiko Sawada <[email protected]>
0 siblings, 1 reply; 84+ messages in thread
From: Michael Paquier @ 2018-11-30 01:48 UTC (permalink / raw)
To: Dmitry Dolgov <[email protected]>; +Cc: Masahiko Sawada <[email protected]>; [email protected]; pgsql-hackers; [email protected]; [email protected]
On Thu, Nov 29, 2018 at 06:21:34PM +0100, Dmitry Dolgov wrote:
> Nothing changed since then, but also the patch got not enough review to say
> that there was substantial feedback. I'll move it to the next CF.
I would have suggested to mark the patch as returned with feedback
instead as the thing does not apply for some time now, and the author
has been notified about a rebase.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Changing the autovacuum launcher scheduling; oldest table first algorithm
2018-11-29 17:21 Re: Changing the autovacuum launcher scheduling; oldest table first algorithm Dmitry Dolgov <[email protected]>
2018-11-30 01:48 ` Re: Changing the autovacuum launcher scheduling; oldest table first algorithm Michael Paquier <[email protected]>
@ 2018-11-30 02:00 ` Masahiko Sawada <[email protected]>
2018-11-30 09:40 ` Re: Changing the autovacuum launcher scheduling; oldest table first algorithm Dmitry Dolgov <[email protected]>
0 siblings, 1 reply; 84+ messages in thread
From: Masahiko Sawada @ 2018-11-30 02:00 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Dmitry Dolgov <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; Tsunakawa, Takayuki <[email protected]>; Ildus Kurbangaliev <[email protected]>
On Fri, Nov 30, 2018 at 10:48 AM Michael Paquier <[email protected]> wrote:
>
> On Thu, Nov 29, 2018 at 06:21:34PM +0100, Dmitry Dolgov wrote:
> > Nothing changed since then, but also the patch got not enough review to say
> > that there was substantial feedback. I'll move it to the next CF.
>
> I would have suggested to mark the patch as returned with feedback
> instead as the thing does not apply for some time now, and the author
> has been notified about a rebase.
Agreed and sorry for the late reply.
The design of this patch would need to be reconsidered based on
suggestions and discussions we had before. I'll propose it again after
considerations.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Changing the autovacuum launcher scheduling; oldest table first algorithm
2018-11-29 17:21 Re: Changing the autovacuum launcher scheduling; oldest table first algorithm Dmitry Dolgov <[email protected]>
2018-11-30 01:48 ` Re: Changing the autovacuum launcher scheduling; oldest table first algorithm Michael Paquier <[email protected]>
2018-11-30 02:00 ` Re: Changing the autovacuum launcher scheduling; oldest table first algorithm Masahiko Sawada <[email protected]>
@ 2018-11-30 09:40 ` Dmitry Dolgov <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Dmitry Dolgov @ 2018-11-30 09:40 UTC (permalink / raw)
To: Masahiko Sawada <[email protected]>; +Cc: Michael Paquier <[email protected]>; [email protected]; pgsql-hackers; [email protected]; [email protected]
> On Fri, Nov 30, 2018 at 3:05 AM Masahiko Sawada <[email protected]> wrote:
>
> On Fri, Nov 30, 2018 at 10:48 AM Michael Paquier <[email protected]> wrote:
> >
> > On Thu, Nov 29, 2018 at 06:21:34PM +0100, Dmitry Dolgov wrote:
> > > Nothing changed since then, but also the patch got not enough review to say
> > > that there was substantial feedback. I'll move it to the next CF.
> >
> > I would have suggested to mark the patch as returned with feedback
> > instead as the thing does not apply for some time now, and the author
> > has been notified about a rebase.
>
> Agreed and sorry for the late reply.
>
> The design of this patch would need to be reconsidered based on
> suggestions and discussions we had before. I'll propose it again after
> considerations.
Well, taking into account this information, then yes, it makes sense and I'll
mark it as "Returned with feedback", thanks!
^ permalink raw reply [nested|flat] 84+ messages in thread
* Policy on cross-posting to multiple lists
@ 2019-01-10 09:56 Dean Rasheed <[email protected]>
2019-01-10 15:58 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
0 siblings, 2 replies; 84+ messages in thread
From: Dean Rasheed @ 2019-01-10 09:56 UTC (permalink / raw)
To: pgsql-hackers
Has the policy on cross-posting to multiple lists been hardened recently?
The "Crash on ALTER TABLE" thread [1] started on -bugs, but Andrew's
message on 8 Jan with an initial proposed patch and my response later
that day both CC'ed -hackers and seem to have been rejected, and so
are missing from the archives.
In that case, it's not a big deal because subsequent replies included
the text from the missing messages, so it's still possible to follow
the discussion, but I wanted to check whether this was an intentional
change of policy. If so, it seems a bit harsh to flat-out reject these
messages. My prior understanding was that cross-posting, while
generally discouraged, does still sometimes have value.
[1] https://www.postgresql.org/message-id/flat/CAEZATCVqksrnXybSaogWOzmVjE3O-NqMSpoHDuDw9_7mhNpeLQ%40mai...
Regards,
Dean
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
@ 2019-01-10 15:58 ` Tom Lane <[email protected]>
2019-01-10 16:11 ` Re: Policy on cross-posting to multiple lists Amit Langote <[email protected]>
1 sibling, 1 reply; 84+ messages in thread
From: Tom Lane @ 2019-01-10 15:58 UTC (permalink / raw)
To: Dean Rasheed <[email protected]>; +Cc: pgsql-hackers
Dean Rasheed <[email protected]> writes:
> Has the policy on cross-posting to multiple lists been hardened recently?
Not that I've heard of.
> The "Crash on ALTER TABLE" thread [1] started on -bugs, but Andrew's
> message on 8 Jan with an initial proposed patch and my response later
> that day both CC'ed -hackers and seem to have been rejected, and so
> are missing from the archives.
I've done the same recently, without problems. I'd suggest inquiring
on the pgsql-www list; project infrastructure issues are not really
on-topic here.
regards, tom lane
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 15:58 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
@ 2019-01-10 16:11 ` Amit Langote <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Amit Langote @ 2019-01-10 16:11 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Dean Rasheed <[email protected]>; pgsql-hackers
On Fri, Jan 11, 2019 at 12:58 AM Tom Lane <[email protected]> wrote:
> Dean Rasheed <[email protected]> writes:
> > The "Crash on ALTER TABLE" thread [1] started on -bugs, but Andrew's
> > message on 8 Jan with an initial proposed patch and my response later
> > that day both CC'ed -hackers and seem to have been rejected, and so
> > are missing from the archives.
>
> I've done the same recently, without problems. I'd suggest inquiring
> on the pgsql-www list; project infrastructure issues are not really
> on-topic here.
Fwiw, an email I sent yesterday was rejected similarly because I'd
tried to send it to both pgsql-hackers and pgsql-performance. I
mentioned about that when I resent the same email successfully [1]
after dropping pgsql-performance from the list of recipients.
Thanks,
Amit
[1] https://www.postgresql.org/message-id/96720c99-ffa0-01ad-c594-0504c8eda708%40lab.ntt.co.jp
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
@ 2019-01-10 17:18 ` Stephen Frost <[email protected]>
2019-01-10 17:34 ` Re: Policy on cross-posting to multiple lists Alvaro Herrera <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 18:19 ` Re: Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 19:46 ` Re: Policy on cross-posting to multiple lists Robert Haas <[email protected]>
2019-01-10 20:52 ` Re: Policy on cross-posting to multiple lists Andres Freund <[email protected]>
1 sibling, 5 replies; 84+ messages in thread
From: Stephen Frost @ 2019-01-10 17:18 UTC (permalink / raw)
To: Dean Rasheed <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
Greetings,
(moving to -www as suggested downthread and as generally more
appropriate)
* Dean Rasheed ([email protected]) wrote:
> Has the policy on cross-posting to multiple lists been hardened recently?
So, the short answer is 'yes'.
We've made a few different changes in the recent weeks. The first
change that was made was actually to start dropping emails where the
list is being BCC'd. That was done a couple of weeks ago and seems to
have gone well and has reduced the amount of spam our moderators are
dealing with.
This most recent change was to implement a policy where we don't allow
public lists to be CC'd with other public lists; when that happens we
instead reply with an email basically saying "please pick the right list
to send your email to."
Perhaps that hasn't been getting through to people...? Though I had
someone respond to -owner basically saying "thanks, I'll pick the right
list", so at least some are seeing it.
As for how this change came to be implemented without much discussion
externally, I'm afraid that's probably the combination of "well, the BCC
change went just fine and no one complained", confusion between folks on
infra as to if we had only discussed it internally or if we had already
discussed it externally with people (the individual who actually made
the change *cough* apparently thought it had already been discussed
externally when we hadn't and probably should have at least announced
it when we did make the change anyway...), and general frustration among
some about the increasing number of cross-post emails we're getting
which really shouldn't be cross-posted.
In an ideal world, everyone would know that they really *shouldn't*
cross-post, and we also wouldn't have extremely long many-mailing-list
cross-posted threads, and we wouldn't need to have such a policy, but
that's not really where we are.
One thing which hadn't been considered and probably should have is the
impact on existing threads, but I'm not sure if we really could have
sensibly done something about that.
Then there's the big question which we really should have discussed
ahead of time, but, do people feel that such a restriction ends up doing
more harm than good? Are there concerns about the BCC restriction? In
the short period of time that it's been in place, I've seen some good
come from it in the form of people learning to post to the correct list
instead of just cross-posting to a bunch of lists, but I've also seen
(now) the cases where existing threads were confused do to the change,
so I suppose I'm on the fence, though I still tend towards having the
policy in place and hoping that it doesn't overly bother existing users
while helping newcomers.
We're here now though, so, thoughts? Should I go undo it right away?
Should we see how it goes? Try other things? We could possibly have it
only apply to emails from people who don't have accounts or who aren't
subscribed to the lists? Or have a flag on a per-account basis which
basically says "let me cross-post"? Open to suggestions (note: I've not
run all the above ideas by the other pglister hacker *cough*, so I can't
say if all of them would be possible/reasonable, just throwing out
ideas).
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
@ 2019-01-10 17:34 ` Alvaro Herrera <[email protected]>
4 siblings, 0 replies; 84+ messages in thread
From: Alvaro Herrera @ 2019-01-10 17:34 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Dean Rasheed <[email protected]>; PostgreSQL Hackers <[email protected]>
On 2019-Jan-10, Stephen Frost wrote:
> Are there concerns about the BCC restriction?
None here.
> We're here now though, so, thoughts? Should I go undo it right away?
I don't like the crosspost ban, personally. Some sort of limit makes
sense, but I think cross-posting to two lists should be allowed. I
don't see an use case for cross-posting to more than two lists (though
maybe -hackers + -bugs + -docs would make sense ...)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
@ 2019-01-10 17:47 ` Tom Lane <[email protected]>
2019-01-10 18:23 ` Re: Policy on cross-posting to multiple lists Dave Page <[email protected]>
2019-01-10 20:27 ` Re: Policy on cross-posting to multiple lists Andres Freund <[email protected]>
4 siblings, 2 replies; 84+ messages in thread
From: Tom Lane @ 2019-01-10 17:47 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Dean Rasheed <[email protected]>; [email protected]
Stephen Frost <[email protected]> writes:
> * Dean Rasheed ([email protected]) wrote:
>> Has the policy on cross-posting to multiple lists been hardened recently?
> So, the short answer is 'yes'.
> Perhaps that hasn't been getting through to people...?
If this was publicly announced anywhere, I didn't see it.
I would have pushed back if I had. CC'ing -hackers on a reply to
a bug report is something I do all the time, and I do not think
it'd be a good idea to stop doing so, nor to make the thread
disappear from the -bugs archives.
I'm quite on board with the need to reduce useless cross-posting,
but this is not the solution.
Maybe there could be a different rule for initial submissions
(one list only) than follow-ups (can add lists)?
regards, tom lane
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
@ 2019-01-10 18:23 ` Dave Page <[email protected]>
2019-01-10 19:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-11 01:08 ` Re: Policy on cross-posting to multiple lists Tatsuo Ishii <[email protected]>
1 sibling, 2 replies; 84+ messages in thread
From: Dave Page @ 2019-01-10 18:23 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Stephen Frost <[email protected]>; Dean Rasheed <[email protected]>; [email protected]
On Thu, Jan 10, 2019 at 11:17 PM Tom Lane <[email protected]> wrote:
>
> Stephen Frost <[email protected]> writes:
> > * Dean Rasheed ([email protected]) wrote:
> >> Has the policy on cross-posting to multiple lists been hardened recently?
>
> > So, the short answer is 'yes'.
> > Perhaps that hasn't been getting through to people...?
>
> If this was publicly announced anywhere, I didn't see it.
> I would have pushed back if I had. CC'ing -hackers on a reply to
> a bug report is something I do all the time, and I do not think
> it'd be a good idea to stop doing so, nor to make the thread
> disappear from the -bugs archives.
>
> I'm quite on board with the need to reduce useless cross-posting,
> but this is not the solution.
Agreed. Similarly, posts from pgadmin-support sometimes end up
intentionally being cross posted to pgadmin-hackers.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 18:23 ` Re: Policy on cross-posting to multiple lists Dave Page <[email protected]>
@ 2019-01-10 19:18 ` Stephen Frost <[email protected]>
1 sibling, 0 replies; 84+ messages in thread
From: Stephen Frost @ 2019-01-10 19:18 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Tom Lane <[email protected]>; Dean Rasheed <[email protected]>; [email protected]; Magnus Hagander <[email protected]>
Greetings,
* Dave Page ([email protected]) wrote:
> On Thu, Jan 10, 2019 at 11:17 PM Tom Lane <[email protected]> wrote:
> > I'm quite on board with the need to reduce useless cross-posting,
> > but this is not the solution.
>
> Agreed. Similarly, posts from pgadmin-support sometimes end up
> intentionally being cross posted to pgadmin-hackers.
So, in implementing this we did consider that different lists might wish
for different policies and given that -hackers seems to be common among
the discussion, what if we just dropped the restriction for posts to
-hackers?
That is, emails to -bugs and -hackers would be allowed through to both
lists, cross-posts to -general and -sql, for example, would get the
bounce-back.
As there seems relatively little downside, I've gone ahead and made that
change, but I don't mean to forstall further discussion. Should we
apply that change to other lists? To all of them?
Tom's idea about allowing cross-posts on replies is an interesting one
as well. I've also added a certain someone to the thread explicitly to
see what his thoughts are on that, and the rest.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 18:23 ` Re: Policy on cross-posting to multiple lists Dave Page <[email protected]>
@ 2019-01-11 01:08 ` Tatsuo Ishii <[email protected]>
2019-01-11 16:38 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
1 sibling, 1 reply; 84+ messages in thread
From: Tatsuo Ishii @ 2019-01-11 01:08 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]
>> I'm quite on board with the need to reduce useless cross-posting,
>> but this is not the solution.
>
> Agreed. Similarly, posts from pgadmin-support sometimes end up
> intentionally being cross posted to pgadmin-hackers.
Another use case is, pgsql-docs and pgsql-hackers. For non trivial
documentation changes I would like to register a doc patch to CF, but
CF app does not pick up any messages other than posted in
pgsql-hackers. So to discuss with pgsql-doc subscribers, while dealing
with CF app, I would like cross postings for pgsql-hackers and
pgsql-docs.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 18:23 ` Re: Policy on cross-posting to multiple lists Dave Page <[email protected]>
2019-01-11 01:08 ` Re: Policy on cross-posting to multiple lists Tatsuo Ishii <[email protected]>
@ 2019-01-11 16:38 ` Stephen Frost <[email protected]>
2019-01-11 16:43 ` Re: Policy on cross-posting to multiple lists Robert Haas <[email protected]>
2019-01-11 18:23 ` Re: Policy on cross-posting to multiple lists Andres Freund <[email protected]>
0 siblings, 2 replies; 84+ messages in thread
From: Stephen Frost @ 2019-01-11 16:38 UTC (permalink / raw)
To: Tatsuo Ishii <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; Magnus Hagander <[email protected]>
Greetings,
* Tatsuo Ishii ([email protected]) wrote:
> >> I'm quite on board with the need to reduce useless cross-posting,
> >> but this is not the solution.
> >
> > Agreed. Similarly, posts from pgadmin-support sometimes end up
> > intentionally being cross posted to pgadmin-hackers.
>
> Another use case is, pgsql-docs and pgsql-hackers. For non trivial
> documentation changes I would like to register a doc patch to CF, but
> CF app does not pick up any messages other than posted in
> pgsql-hackers. So to discuss with pgsql-doc subscribers, while dealing
> with CF app, I would like cross postings for pgsql-hackers and
> pgsql-docs.
So, cross-posting between -hackers and -docs should be working now,
thanks to the change I made yesterday.
After stealing some time from Magnus to chat quickly about this (he
seems to be mostly unavailable at present), what we're trying to figure
out is what the group, overall, wants, and in particular if the change
to allow cross-posting with -hackers solves the valid use-cases while
preventing the invalid use-cases (like cross-posting between -general,
-performance, and -sql).
Of course, it isn't perfect, but then it's unlikely that anything will
be. Changes which require us to write additional code into pglister
will, of course, take longer, but we can work towards it if there's
agreement about what such a change would look like. In the interim, we
could see how things go with the current configuration, or we could add
other lists to the 'exclude', beyond just -hackers and the private
lists, or we could add them all (effectively going back to where things
were before the changes were made).
Thoughts? Specific votes in one of those directions would help me, at
least, figure out what should be done today.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 18:23 ` Re: Policy on cross-posting to multiple lists Dave Page <[email protected]>
2019-01-11 01:08 ` Re: Policy on cross-posting to multiple lists Tatsuo Ishii <[email protected]>
2019-01-11 16:38 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
@ 2019-01-11 16:43 ` Robert Haas <[email protected]>
1 sibling, 0 replies; 84+ messages in thread
From: Robert Haas @ 2019-01-11 16:43 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Tatsuo Ishii <[email protected]>; Dave Page <[email protected]>; Tom Lane <[email protected]>; Dean Rasheed <[email protected]>; PostgreSQL Hackers <[email protected]>; Magnus Hagander <[email protected]>
On Fri, Jan 11, 2019 at 11:38 AM Stephen Frost <[email protected]> wrote:
> Thoughts? Specific votes in one of those directions would help me, at
> least, figure out what should be done today.
Well, you know, you could just undo the ban which you imposed
unilaterally and which nobody so far has said they liked, and multiple
people have said they disliked. Then after having the public
discussion about what the policy should be, you could implement the
conclusions of that discussion.
I mean, personally, I have no problem with SOME cross-posting
restrictions, but nothing you've proposed so far seems very good,
other than maybe the >2 rule. But if you're looking to understand
what people want better, you don't really need more votes. What has
been said by a whole bunch of people is not in any significant way
unclear. They don't like the restrictions, and they do like being
consulted.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 18:23 ` Re: Policy on cross-posting to multiple lists Dave Page <[email protected]>
2019-01-11 01:08 ` Re: Policy on cross-posting to multiple lists Tatsuo Ishii <[email protected]>
2019-01-11 16:38 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
@ 2019-01-11 18:23 ` Andres Freund <[email protected]>
2019-01-11 18:33 ` Re: Policy on cross-posting to multiple lists Alvaro Herrera <[email protected]>
1 sibling, 1 reply; 84+ messages in thread
From: Andres Freund @ 2019-01-11 18:23 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Tatsuo Ishii <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; Magnus Hagander <[email protected]>
Hi,
On 2019-01-11 11:38:05 -0500, Stephen Frost wrote:
> After stealing some time from Magnus to chat quickly about this (he
> seems to be mostly unavailable at present), what we're trying to figure
> out is what the group, overall, wants, and in particular if the change
> to allow cross-posting with -hackers solves the valid use-cases while
> preventing the invalid use-cases (like cross-posting between -general,
> -performance, and -sql).
Those don't really seem to be common and painful enough to really need a
technical solution. -performance still seems like a useful subset of
people, and sometimes threads migrate to/from there. I'd personally just
merge -sql with -general, it doesn't seem to have a use-case left
anymore. But that can be done later.
> Of course, it isn't perfect, but then it's unlikely that anything will
> be. Changes which require us to write additional code into pglister
> will, of course, take longer, but we can work towards it if there's
> agreement about what such a change would look like. In the interim, we
> could see how things go with the current configuration, or we could add
> other lists to the 'exclude', beyond just -hackers and the private
> lists, or we could add them all (effectively going back to where things
> were before the changes were made).
>
> Thoughts? Specific votes in one of those directions would help me, at
> least, figure out what should be done today.
I think you should just revert to the prior state, and then we can
discuss potential solutions and the problems they're intended to
address. I find it baffling that after being called out for
unilateral/not publicly discussed decisions you attempt to address that
criticism by continuing to make unilateral decisions.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 18:23 ` Re: Policy on cross-posting to multiple lists Dave Page <[email protected]>
2019-01-11 01:08 ` Re: Policy on cross-posting to multiple lists Tatsuo Ishii <[email protected]>
2019-01-11 16:38 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-11 18:23 ` Re: Policy on cross-posting to multiple lists Andres Freund <[email protected]>
@ 2019-01-11 18:33 ` Alvaro Herrera <[email protected]>
2019-01-11 20:18 ` Re: Policy on cross-posting to multiple lists Magnus Hagander <[email protected]>
2019-01-11 21:11 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
0 siblings, 2 replies; 84+ messages in thread
From: Alvaro Herrera @ 2019-01-11 18:33 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Stephen Frost <[email protected]>; Tatsuo Ishii <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; Magnus Hagander <[email protected]>
On 2019-Jan-11, Andres Freund wrote:
> On 2019-01-11 11:38:05 -0500, Stephen Frost wrote:
> > Thoughts? Specific votes in one of those directions would help me, at
> > least, figure out what should be done today.
>
> I think you should just revert to the prior state, and then we can
> discuss potential solutions and the problems they're intended to
> address.
+1
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 18:23 ` Re: Policy on cross-posting to multiple lists Dave Page <[email protected]>
2019-01-11 01:08 ` Re: Policy on cross-posting to multiple lists Tatsuo Ishii <[email protected]>
2019-01-11 16:38 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-11 18:23 ` Re: Policy on cross-posting to multiple lists Andres Freund <[email protected]>
2019-01-11 18:33 ` Re: Policy on cross-posting to multiple lists Alvaro Herrera <[email protected]>
@ 2019-01-11 20:18 ` Magnus Hagander <[email protected]>
1 sibling, 0 replies; 84+ messages in thread
From: Magnus Hagander @ 2019-01-11 20:18 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Andres Freund <[email protected]>; Stephen Frost <[email protected]>; Tatsuo Ishii <[email protected]>; Dave Page <[email protected]>; Tom Lane <[email protected]>; Dean Rasheed <[email protected]>; PostgreSQL WWW <[email protected]>
On Fri, Jan 11, 2019 at 7:33 PM Alvaro Herrera <[email protected]>
wrote:
> On 2019-Jan-11, Andres Freund wrote:
>
> > On 2019-01-11 11:38:05 -0500, Stephen Frost wrote:
>
> > > Thoughts? Specific votes in one of those directions would help me, at
> > > least, figure out what should be done today.
> >
> > I think you should just revert to the prior state, and then we can
> > discuss potential solutions and the problems they're intended to
> > address.
>
> +1
>
I've reverted this change across all lists it was enabled for.
And for the record, I'm the one who asked Stephen to go for a second round
of feedback and not just immediately revert it (he pinged me on chat, as I
was unable to keep track of the mail thread myself due to other commitments
and airplanes and things).
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 18:23 ` Re: Policy on cross-posting to multiple lists Dave Page <[email protected]>
2019-01-11 01:08 ` Re: Policy on cross-posting to multiple lists Tatsuo Ishii <[email protected]>
2019-01-11 16:38 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-11 18:23 ` Re: Policy on cross-posting to multiple lists Andres Freund <[email protected]>
2019-01-11 18:33 ` Re: Policy on cross-posting to multiple lists Alvaro Herrera <[email protected]>
@ 2019-01-11 21:11 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 84+ messages in thread
From: Tom Lane @ 2019-01-11 21:11 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Andres Freund <[email protected]>; Stephen Frost <[email protected]>; Tatsuo Ishii <[email protected]>; [email protected]; [email protected]; [email protected]; Magnus Hagander <[email protected]>
Alvaro Herrera <[email protected]> writes:
> On 2019-Jan-11, Andres Freund wrote:
>> On 2019-01-11 11:38:05 -0500, Stephen Frost wrote:
>>> Thoughts? Specific votes in one of those directions would help me, at
>>> least, figure out what should be done today.
>> I think you should just revert to the prior state, and then we can
>> discuss potential solutions and the problems they're intended to
>> address.
> +1
Same here. The problem you want to solve has been there for decades,
we don't need a solution urgently.
regards, tom lane
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
@ 2019-01-10 20:27 ` Andres Freund <[email protected]>
1 sibling, 0 replies; 84+ messages in thread
From: Andres Freund @ 2019-01-10 20:27 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Stephen Frost <[email protected]>; Dean Rasheed <[email protected]>; [email protected]
Hi,
On 2019-01-10 12:47:03 -0500, Tom Lane wrote:
> Stephen Frost <[email protected]> writes:
> > * Dean Rasheed ([email protected]) wrote:
> >> Has the policy on cross-posting to multiple lists been hardened recently?
>
> > So, the short answer is 'yes'.
> > Perhaps that hasn't been getting through to people...?
>
> If this was publicly announced anywhere, I didn't see it.
> I would have pushed back if I had. CC'ing -hackers on a reply to
> a bug report is something I do all the time, and I do not think
> it'd be a good idea to stop doing so, nor to make the thread
> disappear from the -bugs archives.
+1
This seems quite the significant change to make without public
discussion.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
@ 2019-01-10 18:19 ` Dean Rasheed <[email protected]>
4 siblings, 0 replies; 84+ messages in thread
From: Dean Rasheed @ 2019-01-10 18:19 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Thu, 10 Jan 2019 at 17:18, Stephen Frost <[email protected]> wrote:
> * Dean Rasheed ([email protected]) wrote:
> > Has the policy on cross-posting to multiple lists been hardened recently?
>
> This most recent change was to implement a policy where we don't allow
> public lists to be CC'd with other public lists; when that happens we
> instead reply with an email basically saying "please pick the right list
> to send your email to."
The problem with that as a mechanism for stopping people from cross
posting is that it doesn't (and can't) actually stop the message from
being delivered to people already on the CC list for that thread.
So in this case, Andrew first cross posted it, but I was already on
the CC list, so I got the message as normal, not realising that it
hadn't come via the lists. I then hit "Reply all" ... (rinse and
repeat). I didn't even immediately notice the failure to send the
message because my own reply just got added to end of the conversation
in my mail client, but presumably the intention was that both Andrew
and I should have noticed and re-posted to a single list. But of
course that would then have annoyed all the people already on the
thread who would have got duplicates of mails they had already
received.
Personally, I don't have a problem with people cross posting. I think
there are real cases where it's the right thing to do -- it's common
practice for legitimate reasons. Yes, it can be abused, but there are
worse abuses of email all the time.
Regards,
Dean
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
@ 2019-01-10 19:46 ` Robert Haas <[email protected]>
2019-01-10 20:03 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
4 siblings, 1 reply; 84+ messages in thread
From: Robert Haas @ 2019-01-10 19:46 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Dean Rasheed <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Jan 10, 2019 at 12:18 PM Stephen Frost <[email protected]> wrote:
> Are there concerns about the BCC restriction?
One thing people sometimes do when something is posted to the wrong
list is (1) reply, (2) explain in the reply that the message was
posted to the wrong pace, (3) move the original list from Cc into Bcc,
and (4) add the correct list into Cc. That has the advantage that
people on the original list can see that someone replied (which avoids
duplicate replies by different people) and know where to go to find
the rest of the discussion if they want to see it.
I think the idea of allowing 2 lists but not >2 is probably a good
one. Also, it might be good to be more permissive for, say, people
who have successfully posted at least 1000 emails to the lists. Such
people presumably are less likely to do abusive things, and more
likely to care about and heed any correction given to them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 19:46 ` Re: Policy on cross-posting to multiple lists Robert Haas <[email protected]>
@ 2019-01-10 20:03 ` Stephen Frost <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Stephen Frost @ 2019-01-10 20:03 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Dean Rasheed <[email protected]>; PostgreSQL Hackers <[email protected]>
Greetings,
* Robert Haas ([email protected]) wrote:
> On Thu, Jan 10, 2019 at 12:18 PM Stephen Frost <[email protected]> wrote:
> > Are there concerns about the BCC restriction?
>
> One thing people sometimes do when something is posted to the wrong
> list is (1) reply, (2) explain in the reply that the message was
> posted to the wrong pace, (3) move the original list from Cc into Bcc,
> and (4) add the correct list into Cc. That has the advantage that
> people on the original list can see that someone replied (which avoids
> duplicate replies by different people) and know where to go to find
> the rest of the discussion if they want to see it.
While considering that, we actively went and looked at both the
frequency and the success of that approach and, frankly, neither were
very inspiring. There were very few cases of that being tried and, as I
recall anyway, none of them were actually successful in 'moving' the
thread- that is, people continued on the original list to begin with
anyway, except that some of the thread was now on another list.
We had discussed allowing bcc's to lists when we detect that there's at
least *some* valid list in the To or Cc line, but it didn't seem
worthwhile given the research that was done.
For some (private) lists, we have the policy set to moderate emails
which bcc those lists (such as -security). Also, the "don't CC multiple
lists" was only applied to public/archived lists to begin with,
intentionally.
> I think the idea of allowing 2 lists but not >2 is probably a good
> one. Also, it might be good to be more permissive for, say, people
> who have successfully posted at least 1000 emails to the lists. Such
> people presumably are less likely to do abusive things, and more
> likely to care about and heed any correction given to them.
Yeah, that's in-line with what I had suggested up-thread where we have
some kind of flag which can either be set by the user themselves (maybe
we have some language above the flag that cautions against cross-posts
and whatnot), or set by the system (>1000 emails, as you say, or maybe
"after 2 weeks of being subscribed to a list", similar to the community
account "cooling off" period we have), or maybe by the list admins
(likely initially based on a heuristic of "lots of emails sent" or
something, but then handled on an individual basis).
I am a little concerned that we make the system too complicated for
people to understand too though. Haven't got a particularly good answer
for that, sadly.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: Policy on cross-posting to multiple lists
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
@ 2019-01-10 20:52 ` Andres Freund <[email protected]>
4 siblings, 0 replies; 84+ messages in thread
From: Andres Freund @ 2019-01-10 20:52 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Dean Rasheed <[email protected]>; PostgreSQL Hackers <[email protected]>
On 2019-01-10 12:18:35 -0500, Stephen Frost wrote:
> Should I go undo it right away?
Yes.
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH 1/2] Explicitly mark some attributes in catalog as no need for toast relation
@ 2019-02-08 02:22 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Kyotaro Horiguchi @ 2019-02-08 02:22 UTC (permalink / raw)
Currently, there's some attributes of catalogs that storage class is
'x' but really don't need toasted. This causes several sorts of
unwanted things. This patch adds a new storage class 'c' (compress),
which means "try compress in-line, but don't go external', then set
storage class of the attributes to it.
---
src/backend/access/heap/tuptoaster.c | 4 +++-
src/backend/catalog/Catalog.pm | 6 +++++-
src/backend/catalog/genbki.pl | 5 ++++-
src/backend/catalog/toasting.c | 2 +-
src/backend/commands/tablecmds.c | 2 ++
src/include/catalog/genbki.h | 2 ++
src/include/catalog/pg_attribute.h | 8 ++++----
src/include/catalog/pg_class.h | 6 +++---
8 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/src/backend/access/heap/tuptoaster.c b/src/backend/access/heap/tuptoaster.c
index cd921a4600..9718d15487 100644
--- a/src/backend/access/heap/tuptoaster.c
+++ b/src/backend/access/heap/tuptoaster.c
@@ -888,13 +888,15 @@ toast_insert_or_update(Relation rel, HeapTuple newtup, HeapTuple oldtup,
*/
for (i = 0; i < numAttrs; i++)
{
+ Form_pg_attribute att = TupleDescAttr(tupleDesc, i);
+
if (toast_action[i] != ' ')
continue;
if (VARATT_IS_EXTERNAL(DatumGetPointer(toast_values[i])))
continue; /* can't happen, toast_action would be 'p' */
if (VARATT_IS_COMPRESSED(DatumGetPointer(toast_values[i])))
continue;
- if (TupleDescAttr(tupleDesc, i)->attstorage != 'm')
+ if (att->attstorage != 'm' && att->attstorage != 'c' )
continue;
if (toast_sizes[i] > biggest_size)
{
diff --git a/src/backend/catalog/Catalog.pm b/src/backend/catalog/Catalog.pm
index 3bf308fe3b..e6e127645f 100644
--- a/src/backend/catalog/Catalog.pm
+++ b/src/backend/catalog/Catalog.pm
@@ -169,7 +169,7 @@ sub ParseHeader
$column{type} = $atttype;
$column{name} = $attname;
- $column{is_varlen} = 1 if $is_varlen;
+ $column{is_varlen} = 1 if ($is_varlen);
foreach my $attopt (@attopts)
{
@@ -198,6 +198,10 @@ sub ParseHeader
{
$column{lookup} = $1;
}
+ elsif ($attopt =~ /BKI_STORAGE\((\w)\)/)
+ {
+ $column{storage} = $1;
+ }
else
{
die
diff --git a/src/backend/catalog/genbki.pl b/src/backend/catalog/genbki.pl
index be81094ffb..1d6818c96f 100644
--- a/src/backend/catalog/genbki.pl
+++ b/src/backend/catalog/genbki.pl
@@ -734,13 +734,16 @@ sub morph_row_for_pgattr
$row->{attname} = $attname;
+ # copy explicitly specified storage
+ $row->{attstorage} = $attr->{storage} if ($attr->{storage});
+
# Copy the type data from pg_type, and add some type-dependent items
my $type = $types{$atttype};
$row->{atttypid} = $type->{oid};
$row->{attlen} = $type->{typlen};
$row->{attbyval} = $type->{typbyval};
- $row->{attstorage} = $type->{typstorage};
+ $row->{attstorage} = $type->{typstorage} if (!$row->{attstorage});
$row->{attalign} = $type->{typalign};
# set attndims if it's an array type
diff --git a/src/backend/catalog/toasting.c b/src/backend/catalog/toasting.c
index 77be19175a..ac45c51286 100644
--- a/src/backend/catalog/toasting.c
+++ b/src/backend/catalog/toasting.c
@@ -435,7 +435,7 @@ needs_toast_table(Relation rel)
maxlength_unknown = true;
else
data_length += maxlen;
- if (att->attstorage != 'p')
+ if (att->attstorage != 'p' && att->attstorage != 'c')
has_toastable_attrs = true;
}
}
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 35a9ade059..a7b37d6e2b 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -1854,6 +1854,8 @@ storage_name(char c)
return "EXTENDED";
case 'e':
return "EXTERNAL";
+ case 'c':
+ return "COMPRESS";
default:
return "???";
}
diff --git a/src/include/catalog/genbki.h b/src/include/catalog/genbki.h
index 1b8e4e9e19..8e71d11964 100644
--- a/src/include/catalog/genbki.h
+++ b/src/include/catalog/genbki.h
@@ -40,6 +40,8 @@
* OID-array field
*/
#define BKI_LOOKUP(catalog)
+/* Indicates storage type of attribute */
+#define BKI_STORAGE(storage)
/* The following are never defined; they are here only for documentation. */
diff --git a/src/include/catalog/pg_attribute.h b/src/include/catalog/pg_attribute.h
index a6ec122389..3e02e908ef 100644
--- a/src/include/catalog/pg_attribute.h
+++ b/src/include/catalog/pg_attribute.h
@@ -164,19 +164,19 @@ CATALOG(pg_attribute,1249,AttributeRelationId) BKI_BOOTSTRAP BKI_ROWTYPE_OID(75,
/* NOTE: The following fields are not present in tuple descriptors. */
/* Column-level access permissions */
- aclitem attacl[1] BKI_DEFAULT(_null_);
+ aclitem attacl[1] BKI_DEFAULT(_null_) BKI_STORAGE(c);
/* Column-level options */
- text attoptions[1] BKI_DEFAULT(_null_);
+ text attoptions[1] BKI_DEFAULT(_null_) BKI_STORAGE(c);
/* Column-level FDW options */
- text attfdwoptions[1] BKI_DEFAULT(_null_);
+ text attfdwoptions[1] BKI_DEFAULT(_null_) BKI_STORAGE(c);
/*
* Missing value for added columns. This is a one element array which lets
* us store a value of the attribute type here.
*/
- anyarray attmissingval BKI_DEFAULT(_null_);
+ anyarray attmissingval BKI_DEFAULT(_null_) BKI_STORAGE(c);
#endif
} FormData_pg_attribute;
diff --git a/src/include/catalog/pg_class.h b/src/include/catalog/pg_class.h
index 5d82ce09a6..46ad5c6d99 100644
--- a/src/include/catalog/pg_class.h
+++ b/src/include/catalog/pg_class.h
@@ -75,9 +75,9 @@ CATALOG(pg_class,1259,RelationRelationId) BKI_BOOTSTRAP BKI_ROWTYPE_OID(83,Relat
#ifdef CATALOG_VARLEN /* variable-length fields start here */
/* NOTE: These fields are not present in a relcache entry's rd_rel field. */
- aclitem relacl[1]; /* access permissions */
- text reloptions[1]; /* access-method-specific options */
- pg_node_tree relpartbound; /* partition bound node tree */
+ aclitem relacl[1] BKI_STORAGE(c); /* access permissions */
+ text reloptions[1] BKI_STORAGE(c); /* access-method-specific options */
+ pg_node_tree relpartbound BKI_STORAGE(c);/* partition bound node tree */
#endif
} FormData_pg_class;
--
2.16.3
----Next_Part(Fri_Feb_08_12_34_33_2019_619)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v2-0002-Let-ALTER-TABLE-accept-new-storage-class-compress.patch"
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v2 01/11] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/RgO6TscyR9fMvkEm1k5N=yu
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v2-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v3 01/11] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/.arW0LC=Yi8JO9BRih4YlyS
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v3-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v5 01/14] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_//gBZFZYGWm7urqUgDbu6PSe
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v5-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v6 01/15] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/74urtnrsBSymuH7bJczNOGS
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v6-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v3 01/11] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/.arW0LC=Yi8JO9BRih4YlyS
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v3-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v2 01/11] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/RgO6TscyR9fMvkEm1k5N=yu
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v2-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v7 01/16] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/VSGM3xNEmY7iJyL2wuWRCjV
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v7-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s)
@ 2023-09-24 20:49 Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Karl O. Pinc @ 2023-09-24 20:49 UTC (permalink / raw)
The current section title of "Executing a Command with a Single-Row
Result" does not reflect what the section is really about. Other
sections make clear how to _execute_ commands, single-row result or not.
What this section is about is how to _save_ a single row of results into
variable(s).
It would be nice to talk about saving results into variables in the
section heading but I couldn't come up with anything pithy. "Saving a
Single-Row of a Command's Result" seems good enough, especially since
there's few other places to save results other than in variables.
---
doc/src/sgml/plpgsql.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f55e901c7e..8747e84245 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1126,7 +1126,7 @@ PERFORM create_mv('cs_session_page_requests_mv', my_query);
</sect2>
<sect2 id="plpgsql-statements-sql-onerow">
- <title>Executing a Command with a Single-Row Result</title>
+ <title>Saving a Single-Row of a Command's Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
<primary>SELECT INTO</primary>
--
2.30.2
--MP_/OOXZvOwbpccKfGOtE9/SwX6
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-Change-section-heading-to-better-describe-referen.patch
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: memory leak in pgoutput
@ 2024-11-19 00:21 Michael Paquier <[email protected]>
2024-11-19 07:08 ` Re: memory leak in pgoutput by Yang <[email protected]>
0 siblings, 1 reply; 84+ messages in thread
From: Michael Paquier @ 2024-11-19 00:21 UTC (permalink / raw)
To: by Yang <[email protected]>; +Cc: Zhijie Hou (Fujitsu) <[email protected]>; pgsql-hackers
On Mon, Nov 18, 2024 at 04:58:38PM +0900, Michael Paquier wrote:
> On Mon, Nov 18, 2024 at 07:00:57AM +0000, by Yang wrote:
>> By the way, this issue is introduced in 52e4f0cd472d39d. Therefore, we may need
>> to backport the patch to v15.
>
> Yes. Note that nothing can happen on stable branches for a few days
> as a release is planned for this week. See here:
> https://www.postgresql.org/message-id/[email protected]
By the way, if possible, could you send an updated version of the
patch to show what you have in mind?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: memory leak in pgoutput
2024-11-19 00:21 Re: memory leak in pgoutput Michael Paquier <[email protected]>
@ 2024-11-19 07:08 ` by Yang <[email protected]>
2024-11-20 00:39 ` Re: memory leak in pgoutput Michael Paquier <[email protected]>
0 siblings, 1 reply; 84+ messages in thread
From: by Yang @ 2024-11-19 07:08 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: pgsql-hackers; Zhijie Hou (Fujitsu) <[email protected]>
> By the way, if possible, could you send an updated version of the
> patch to show what you have in mind?
Yeah, here is the new patch:
I have verifed that this patch works for REL_[15-17]_STABLE and master.
The memory consumption of "logical replication cache context" remains
consistently at 112 MB during the benchmark mentioned above.
> sysbench oltp_write_only --db-driver=pgsql \
> --pgsql-port=5432 \
> --pgsql-db=postgres \
> --pgsql-user=postgres \
> --tables=15000 --table_size=100 \
> --report-interval=1 \
> --threads=10 run \
> --time=180
Attachments:
[application/octet-stream] v2-0001-Fix-memory-leak-in-pgoutput.patch (1.2K, ../../DM3PR84MB344267C77FE5CF0612E59C6FE3202@DM3PR84MB3442.NAMPRD84.PROD.OUTLOOK.COM/3-v2-0001-Fix-memory-leak-in-pgoutput.patch)
download | inline diff:
From 3e6d9d1abf18fb36805eac25f765b3cd388b44f6 Mon Sep 17 00:00:00 2001
From: "yangboyu.yby" <[email protected]>
Date: Sat, 16 Nov 2024 16:26:02 +0800
Subject: [PATCH] Fix memory leak in pgoutput
---
src/backend/replication/pgoutput/pgoutput.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 00e7024563..390f41494e 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -2055,9 +2055,25 @@ get_rel_sync_entry(PGOutputData *data, Relation relation)
* Tuple slots cleanups. (Will be rebuilt later if needed).
*/
if (entry->old_slot)
+ {
+ TupleDesc desc = entry->old_slot->tts_tupleDescriptor;
+
+ Assert(desc->tdrefcount == -1);
+
+ FreeTupleDesc(desc);
+ desc = NULL;
ExecDropSingleTupleTableSlot(entry->old_slot);
+ }
if (entry->new_slot)
+ {
+ TupleDesc desc = entry->new_slot->tts_tupleDescriptor;
+
+ Assert(desc->tdrefcount == -1);
+
+ FreeTupleDesc(desc);
+ desc = NULL;
ExecDropSingleTupleTableSlot(entry->new_slot);
+ }
entry->old_slot = NULL;
entry->new_slot = NULL;
--
2.32.0.3.g01195cf9f
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: memory leak in pgoutput
2024-11-19 00:21 Re: memory leak in pgoutput Michael Paquier <[email protected]>
2024-11-19 07:08 ` Re: memory leak in pgoutput by Yang <[email protected]>
@ 2024-11-20 00:39 ` Michael Paquier <[email protected]>
2024-11-20 10:41 ` Re: memory leak in pgoutput by Yang <[email protected]>
0 siblings, 1 reply; 84+ messages in thread
From: Michael Paquier @ 2024-11-20 00:39 UTC (permalink / raw)
To: by Yang <[email protected]>; +Cc: pgsql-hackers; Zhijie Hou (Fujitsu) <[email protected]>
On Tue, Nov 19, 2024 at 07:08:26AM +0000, by Yang wrote:
> I have verifed that this patch works for REL_[15-17]_STABLE and master.
> The memory consumption of "logical replication cache context" remains
> consistently at 112 MB during the benchmark mentioned above.
You should be more careful with the amount of tests you are doing
here. This fails while waiting for some changes to be streamed when
creating a subscription:
cd src/test/subscription/ && PROVE_TESTS=t/017_stream_ddl.pl make check
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: memory leak in pgoutput
2024-11-19 00:21 Re: memory leak in pgoutput Michael Paquier <[email protected]>
2024-11-19 07:08 ` Re: memory leak in pgoutput by Yang <[email protected]>
2024-11-20 00:39 ` Re: memory leak in pgoutput Michael Paquier <[email protected]>
@ 2024-11-20 10:41 ` by Yang <[email protected]>
2024-11-21 06:25 ` Re: memory leak in pgoutput Michael Paquier <[email protected]>
0 siblings, 1 reply; 84+ messages in thread
From: by Yang @ 2024-11-20 10:41 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Zhijie Hou (Fujitsu) <[email protected]>; pgsql-hackers
> You should be more careful with the amount of tests you are doing
> here. This fails while waiting for some changes to be streamed when
> creating a subscription:
> cd src/test/subscription/ && PROVE_TESTS=t/017_stream_ddl.pl make check
I apologize for the obvious error in the previous patch. I have corrected it
in the new patch(v3) and pass the regression testing.
Attachments:
[application/octet-stream] v3-0001-Fix-memory-leak-in-pgoutput.patch (1.2K, ../../DM3PR84MB3442BCD53125120366645CF5E3212@DM3PR84MB3442.NAMPRD84.PROD.OUTLOOK.COM/3-v3-0001-Fix-memory-leak-in-pgoutput.patch)
download | inline diff:
From 242bff0c2fecf6b777bfd72ac077810822d8015d Mon Sep 17 00:00:00 2001
From: "yangboyu.yby" <[email protected]>
Date: Wed, 20 Nov 2024 11:14:09 +0800
Subject: [PATCH] Fix memory leak in pgoutput
---
src/backend/replication/pgoutput/pgoutput.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 00e7024563e..36b2c5fbbfe 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -2055,9 +2055,25 @@ get_rel_sync_entry(PGOutputData *data, Relation relation)
* Tuple slots cleanups. (Will be rebuilt later if needed).
*/
if (entry->old_slot)
+ {
+ TupleDesc *desc = &entry->old_slot->tts_tupleDescriptor;
+
+ Assert((*desc)->tdrefcount == -1);
+
+ FreeTupleDesc(*desc);
+ *desc = NULL;
ExecDropSingleTupleTableSlot(entry->old_slot);
+ }
if (entry->new_slot)
+ {
+ TupleDesc *desc = &entry->new_slot->tts_tupleDescriptor;
+
+ Assert((*desc)->tdrefcount == -1);
+
+ FreeTupleDesc(*desc);
+ *desc = NULL;
ExecDropSingleTupleTableSlot(entry->new_slot);
+ }
entry->old_slot = NULL;
entry->new_slot = NULL;
--
2.32.0.3.g01195cf9f
^ permalink raw reply [nested|flat] 84+ messages in thread
* Re: memory leak in pgoutput
2024-11-19 00:21 Re: memory leak in pgoutput Michael Paquier <[email protected]>
2024-11-19 07:08 ` Re: memory leak in pgoutput by Yang <[email protected]>
2024-11-20 00:39 ` Re: memory leak in pgoutput Michael Paquier <[email protected]>
2024-11-20 10:41 ` Re: memory leak in pgoutput by Yang <[email protected]>
@ 2024-11-21 06:25 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 84+ messages in thread
From: Michael Paquier @ 2024-11-21 06:25 UTC (permalink / raw)
To: by Yang <[email protected]>; +Cc: Zhijie Hou (Fujitsu) <[email protected]>; pgsql-hackers
On Wed, Nov 20, 2024 at 10:41:50AM +0000, by Yang wrote:
> I apologize for the obvious error in the previous patch. I have corrected it
> in the new patch(v3) and pass the regression testing.
It took me quite a bit of time to evaluate the amount of the damage,
and indeed sysbench has been quite good at showing the problem. It is
not that much though depending on the number of tables. With map
laptop and 500 tables, the cleanup of the slots showed up in sudden
burts that increased the memory footprint of the WAL sender.
I think that there is at least one more leak, which is even smaller
than the one you have reported here. It takes a longer run time to
show up with sysbench, but it's here with the WAL sender memory
growing slowly over time. We should be much more careful with this
area of the code in terms of memory handling. Perhaps with a broader
memory context associated to the data of the cached entries, reset
each time an entry is validated? This current coding style is quite
dangerous to rely on.
Anyway, this patch fixes a portion of the damage and Hou's method was
a bit cleaner, so I have used it and applied it down to v15.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 84+ messages in thread
end of thread, other threads:[~2024-11-21 06:25 UTC | newest]
Thread overview: 84+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-11-29 17:21 Re: Changing the autovacuum launcher scheduling; oldest table first algorithm Dmitry Dolgov <[email protected]>
2018-11-30 01:48 ` Michael Paquier <[email protected]>
2018-11-30 02:00 ` Masahiko Sawada <[email protected]>
2018-11-30 09:40 ` Dmitry Dolgov <[email protected]>
2019-01-10 09:56 Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 15:58 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 16:11 ` Re: Policy on cross-posting to multiple lists Amit Langote <[email protected]>
2019-01-10 17:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 17:34 ` Re: Policy on cross-posting to multiple lists Alvaro Herrera <[email protected]>
2019-01-10 17:47 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 18:23 ` Re: Policy on cross-posting to multiple lists Dave Page <[email protected]>
2019-01-10 19:18 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-11 01:08 ` Re: Policy on cross-posting to multiple lists Tatsuo Ishii <[email protected]>
2019-01-11 16:38 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-11 16:43 ` Re: Policy on cross-posting to multiple lists Robert Haas <[email protected]>
2019-01-11 18:23 ` Re: Policy on cross-posting to multiple lists Andres Freund <[email protected]>
2019-01-11 18:33 ` Re: Policy on cross-posting to multiple lists Alvaro Herrera <[email protected]>
2019-01-11 20:18 ` Re: Policy on cross-posting to multiple lists Magnus Hagander <[email protected]>
2019-01-11 21:11 ` Re: Policy on cross-posting to multiple lists Tom Lane <[email protected]>
2019-01-10 20:27 ` Re: Policy on cross-posting to multiple lists Andres Freund <[email protected]>
2019-01-10 18:19 ` Re: Policy on cross-posting to multiple lists Dean Rasheed <[email protected]>
2019-01-10 19:46 ` Re: Policy on cross-posting to multiple lists Robert Haas <[email protected]>
2019-01-10 20:03 ` Re: Policy on cross-posting to multiple lists Stephen Frost <[email protected]>
2019-01-10 20:52 ` Re: Policy on cross-posting to multiple lists Andres Freund <[email protected]>
2019-02-08 02:22 [PATCH 1/2] Explicitly mark some attributes in catalog as no need for toast relation Kyotaro Horiguchi <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v2 01/11] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v3 01/11] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v5 01/14] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v6 01/15] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v3 01/11] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v2 01/11] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v7 01/16] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2023-09-24 20:49 [PATCH v4 01/12] Change section heading to better reflect saving a result in variable(s) Karl O. Pinc <[email protected]>
2024-11-19 00:21 Re: memory leak in pgoutput Michael Paquier <[email protected]>
2024-11-19 07:08 ` Re: memory leak in pgoutput by Yang <[email protected]>
2024-11-20 00:39 ` Re: memory leak in pgoutput Michael Paquier <[email protected]>
2024-11-20 10:41 ` Re: memory leak in pgoutput by Yang <[email protected]>
2024-11-21 06:25 ` Re: memory leak in pgoutput Michael Paquier <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox