eople misunderstand it in the same way that
Walter did, namely that this behaves just like security invoker functions.
But if the behavior is well documented, I think that is ok.
Yours,
Laurenz Albe
nsus.
>
> Here is my take on option 2, then: you get to choose exactly one method
> that the client will accept.
I am all for the idea, but you implemented the reverse of proposal 2.
Wouldn't it be better to list the *rejected* authentication methods?
Then we could have "password" on there by default.
Yours,
Laurenz Albe
->rd_rel->relkind == RELKIND_VIEW
&& RelationHasSecurityInvoker(relation))
user_for_check = InvalidOid;
else
user_for_check = relation->rd_rel->relowner;
setRuleCheckAsUser((Node *) rule->actions, user_for_check);
setRuleCheckAsUser(rule->qual, user_for_check);
This might be easier to read.
Yours,
Laurenz Albe
On Mon, 2022-03-14 at 13:40 +0100, Christoph Heiss wrote:
> On 3/9/22 16:06, Laurenz Albe wrote:
> > This paragraph contains a couple of grammatical errors.
>
> Replaced the two paragraphs with your suggestion, it is indeed easier to
> read.
>
> > Also, this:
>
#x27;12
hours' + INTERVAL '12 hours';
?column?
════
2022-03-27 21:00:00+02
(1 row)
test=> SELECT TIMESTAMPTZ '2022-03-26 20:00:00 Europe/Vienna' + INTERVAL '1
day';
?column?
2022-03-27 20:00:00+02
(1 row)
Yours,
Laurenz Albe
that you found the oversight in LOCK - I wasn't even
aware that views could be locked.
Yours,
Laurenz Albe
_size_str, total_size_str,
> percent);
I think you replied to the wrong thread...
Yours,
Laurenz Albe
ile. Both are unappealing.
I have been annoyed about this myself, and I have heard other prople
complain about it, so I propose to clear the query buffer if the
editor exits without modifying the file.
This behavior is much more intuitive for me.
Yours,
Laurenz Albe
From 209e4a0ab51f88a82e1fc0d4e4efd2
On Tue, 2020-12-01 at 11:03 -0500, Chapman Flack wrote:
> On 11/30/20 22:38, Laurenz Albe wrote:
> > I have been annoyed about this myself, and I have heard other prople
> > complain about it, so I propose to clear the query buffer if the
> > editor exits without modifying
dmin" might be interesting; I'll have a look.
I don't think we have to specifically count "closed by normal disconnect",
because
that should be the rule and could be more or less deduced from the other numbers
(with the uncertainty mentioned above).
> (Let me know if you th
On Thu, 2020-12-03 at 13:22 +0100, Laurenz Albe wrote:
> > Basically, that would change pgStatSessionDisconnectedNormally into instead
> > being an
> > enum of reasons, which could be normal disconnect, abnormal disconnect and
> > admin.
> > And we'd track all
).
>
> I am considering the cases
>
> 1) client just went away (currently "aborted")
> 2) death by FATAL error
> 3) killed by the administrator (or shutdown)
I think I figured it out. Here is a patch along these lines.
I named the three counters "sessions_client_eo
it's easier to
> correlate a value like "0x03" with definitions made in the former style.
> Or at least I think so; maybe others see it differently.
+1
Laurenz Albe
On Tue, 2020-12-08 at 17:29 +, Bossart, Nathan wrote:
> +1 to setting checkpoint_completion_target to 0.9 by default.
+1 for changing the default or getting rid of it, as Tom suggested.
While we are at it, could we change the default of "log_lock_waits" to "on"?
Yours,
Laurenz Albe
ENT_EOF:
> + ++(dbentry->n_sessions_client_eof);
> + break;
>
> The normal syntax we'd use for that would be
> dbentry->n_sessions_client_eof++;
Ok, changed.
> + typedef enum sessionEndType {
>
> To be consistent with the other enums i
On Tue, 2020-12-15 at 13:53 +0100, Laurenz Albe wrote:
> Attached is patch version 9.
Aah, I forgot the ++.
Version 10 attached.
Yours,
Laurenz Albe
From b40e34141c80ff59c0005f430bd8c273918eb7bb Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 15 Dec 2020 13:46:44 +0100
Subject: [PA
On Tue, 2020-12-01 at 11:34 -0500, Chapman Flack wrote:
> On 12/01/20 11:21, Laurenz Albe wrote:
> > On Tue, 2020-12-01 at 11:03 -0500, Chapman Flack wrote:
> > > > I propose to clear the query buffer if the
> > > > editor exits without modifying the file.
>
was provided.
Another thing that is missing is tab completion for
regression=# \dtS pg_toast.pg_
This should work just like for \d and \dS.
Both of these effects can also be observed with \di and toast indexes.
Yours,
Laurenz Albe
On Fri, 2020-12-18 at 00:58 -0600, Justin Pryzby wrote:
> On Thu, Dec 17, 2020 at 04:16:52PM +0100, Laurenz Albe wrote:
> > On Mon, 2020-11-30 at 10:54 -0600, Justin Pryzby wrote:
> > > This makes toast tables a bit less special and easier to inspect.
> >
tay lowercase.
Then you should also change the way \d does it (upper case).
I think we should be consistent.
I'd use TOAST for both to create no unnecessary change in \d output.
Anyway, I think that this is ready for committer and will mark it as such.
Yours,
Laurenz Albe
ment of PgStat_MsgConn says "Sent by pgstat_connection".
> I thought "pgstat_connection" is a function, but it doesn't exist.
>
> Is "Sent by the backend" right?
>
> Although this is a trivial thing, the following row has too many tabs.
> Other structs have only one space.
> // }Pgstat_MsgConn;
Thanks for the feedback.
I am currently on vacations and will take a look after January 7.
Yours,
Laurenz Albe
ight?
The function was renamed and is now called "pgstat_send_connstats".
But you are right, I might as well match the surrounding code and
write "Sent by the backend".
> Although this is a trivial thing, the following row has too many tabs.
>
> Other structs have onl
ere are some functions that do it like this:
int32 result;
result = 0;
for (...)
{
if (...)
result++;
}
PG_RETURN_INT32(result);
Again, it is a matter of taste, and I didn't detect a clear pattern
in the existing code that I feel I should
hoose a non-default setting
to avoid paying the price for a feature that they don't need.
Yours,
Laurenz Albe
y this patch, but that is somewhat related: if the executor prunes some
partitions, the degree of parallelism is unaffected, right?
So if the planner decides to use 24 workers for 25 partitions, and the
executor discards all but one of these partition scans, we would end up
with 24 workers scanning a single partition.
I am not sure how that could be improved.
Yours,
Laurenz Albe
e re-purpose "parallel_workers" like this, we'd have to change this.
Then for a normal table, "parallel_workers" would mean how many workers
work on a parallel table scan. For a partitioned table, it determines
how many workers work on a parallel append.
Perhaps that is similar enough that it is not confusing.
Yours,
Laurenz Albe
me a valid use case.
I think that if the option is set, it should override the number of workers
inherited from the partitions, and it should override the log2 default.
Yours,
Laurenz Albe
aultpw))
>
> I'm thinking it would be better to just modify the existing macro to
> check relkind to decide which struct pointer type to cast the value in
> rd_options to.
Here is an updated patch with this fix.
I added regression tests and adapted the documentation a bit.
I
allel Seq Scan on pagg_tab_ml_p2_s2 pagg_tab_ml_2
(14 rows)
The default number of parallel workers is taken, because the append is
on an upper relation, not the partitioned table itself.
One would wish that "parallel_workers" somehow percolated up, but I
have no idea how that should work.
Yours,
Laurenz Albe
Thanks for testing!
On Wed, 2021-03-03 at 00:07 +, Jacob Champion wrote:
> On Wed, 2020-12-16 at 10:45 +0100, Laurenz Albe wrote:
>
> > I consider this a bug fix, but one that shouldn't be backpatched.
> > Re-executing the previous query if the editor is quit is
&g
On Wed, 2021-03-03 at 17:58 +0900, Amit Langote wrote:
> On Tue, Mar 2, 2021 at 5:47 PM Laurenz Albe wrote:
> > On Tue, 2021-03-02 at 11:23 +0900, Amit Langote wrote:
> > > I got the same result with my implementation, but I am wondering if
> > > setting parallel_wo
On Wed, 2021-03-03 at 17:12 +, Jacob Champion wrote:
> On Wed, 2021-03-03 at 17:08 +0100, Laurenz Albe wrote:
> > This is no new behavior, and I think this is rare enough that we don't
> > have to bother.
>
> I agree that it's not new behavior, but this patch
t any save is guaranteed
> to move the timestamp forward. That should work even if the filesystem
> has extremely poor precision.
Ah, of course, that is the way to go.
Attached is version 3 which does it like this.
Yours,
Laurenz Albe
From 7ff01271cb8ea5c9011a57ed613026ec7511d785 Mon Sep 17 00:
On Wed, 2021-03-03 at 17:58 +0900, Amit Langote wrote:
> For example, with the attached PoC patch:
I have incorporated your POC patch and added a regression test.
I didn't test it thoroughly though.
Yours,
Laurenz Albe
From 34f7da98b34bc1dbf7daca9e2ca6055c80d77f43 Mon Sep 17 00:00:00 2
On Fri, 2021-03-05 at 22:55 +0900, Amit Langote wrote:
> On Fri, Mar 5, 2021 at 10:47 PM Laurenz Albe wrote:
> > On Wed, 2021-03-03 at 17:58 +0900, Amit Langote wrote:
> > > For example, with the attached PoC patch:
> >
> > I have incorporated your POC pat
pgbench_accounts from stdin");
> + res = PQexec(con, "copy pgbench_accounts from stdin freeze");
I think it would be better to use the official syntax and put the "freeze"
in parentheses. Perhaps the old syntax will be desupported some day.
Yours,
Laurenz Albe
xception.
In case of doubt, I would agree with you and forbid it in HEAD
as a corner case with little real-world use.
Yours,
Laurenz Albe
>
> PS: I seem to recall that some Microsoft filesystems have 2-second
> resolution on file mod times, so maybe it needs to be "time(NULL) - 2"?
Thanks for taking a look!
Taken together, these arguments are convincing.
Done like that in the attached patch version 4.
Yours,
Laurenz
er identifier to the
value it had after you connected to the database. This can be different
from the session identifier if ALTER DATABASE or
ALTER ROLE were used to assign a different default role.
(I hope what I wrote is correct.)
Yours,
Laurenz Albe
ROLE, perhaps ALTER DATABASE
(although I don't see what sense it could make to set that on the database
level),
and briefly explain the difference between RESET ROLE and SET ROLE NONE.
I think adding too much detail will harm - anyone who needs to know the
exact truth can resort to the implem
specifying "role" in a libpq connect string might be
worth documenting. Can you think of a use case?
Yours,
Laurenz Albe
From 5daa6c2a874898506fda316fe651f107dbed34d5 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Fri, 12 Mar 2021 15:32:01 +0100
Subject: [PATCH] Document ALTER ROLE ... S
gt;
> That seems reasonable to me.
+1 from me too.
Yours,
Laurenz Albe
the previous query
and quit, I don't expect it to be executed again.
Currently, the only way to achieve that is to empty the temporary
file and then save it, which is annoying.
Attached is version 6.
Yours,
Laurenz Albe
From 436f48e21adcf207dc267db834a2e80f846fb666 Mon Sep 17 00:00:00 2001
From: L
ng
> a new base backup.")));
>
> into a PANIC instead of a WARNING.
There is a patch in the commitfest that does exactly that (except it
uses ERROR rather than PANIC):
https://postgr.es/m/osbpr01mb4888cbe1da08818fd2d90ed8ed...@osbpr01mb4888.jpnprd01.prod.outlook.com
Yours,
Laurenz Albe
ne"? Will the recovery process fail, as it should,
or will you end up with data corruption?
We already have a performance-related footgun in the shape of
fsync = off. Do we want to add another one?
Yours,
Laurenz Albe
uot;specific opportunities", but we still
should make it as hard as possible for the user to cause harm. It may be that
MySQL, which inspired this feature, does not care about that, but I think we
should do better.
Another point that makes me worry is that this feature will unconditionally
break all replication, and there is not the least mention of that in the
documentation.
Yours,
Laurenz Albe
much different from changing to "wal_level =
minimal".
So as long as PostgreSQL refuses to start after a crash, we should be good.
Sorry for the noise, and I am beginning to think that this is actually
a useful feature.
Yours,
Laurenz Albe
would at least require some fat warnings in the documentation
and in postgresql.conf.
Yours,
Laurenz Albe
g ?
No, I think that "none" is quite accurate.
The worry is that it makes it quite easy for people to end up with
a crashed database that cannot start - at the very least there should be
warnings in the documentation and postgresql.conf that are as dire as
for "fsync = off".
Yours,
Laurenz Albe
it tests
if (ArchiveRecoveryRequested && ControlFile->wal_level <= WAL_LEVEL_MINIMAL)
and we should be safe.
Yours,
Laurenz Albe
ce it was a
> change in glibc.
Yes, this is a persistent pain; I had several customers suffering from
these issues too.
I wish
https://postgr.es/m/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com
hade made it into core.
Yours,
Laurenz Albe
"waiting for review".
Yours,
Laurenz Albe
From afc37856c12fd0a85587c638fca291a0b5652d9b Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 11 Nov 2020 20:14:28 +0100
Subject: [PATCH] Add session statistics to pg_stat_database
If "track_counts" is active, track the fo
ook: validity error : No declaration for attribute
id of element book
^
postgres.sgml:24: element title: validity error : No declaration for element
title
PostgreSQL &version; Documentation
I have the impression that this is not the fault of my patch, something seems
to be
wrong with the cfbot.
I see that other patches are failing with the same error.
Yours,
Laurenz Albe
ressed.
If you think that the patch is ready to go, you could mark it as
"ready for committer" in the commitfest app.
Yours,
Laurenz Albe
level <= WAL_LEVEL_MINIMAL
it will automatically work for your new feature too.
Then your new wal_level would be a second patch only for HEAD.
With that, the only remaining consideration with this patch is the danger
that enabling wal_level=none without taking a backup before can lead to
data loss. But that is intended, so I think that an unmistakable warning
in the documentation would be good enough.
Yours,
Laurenz Albe
for the stats
collector
to tell the difference between a start after a backend crash and - say -
starting from
a base backup.
Patch v6 attached.
I think that that would be material for another patch, and I don't think it
should go
to "pg_stat_database", because a) it might be har
to "FAST ON"? That would be along the parameter used in the
> streaming protocol command BASE_BACKUP, where "FAST" disables lazy
> checkpointing.
+1
That would also match pg_basebackup's "-c fast|spread".
Yours,
Laurenz Albe
;t give the user a clue
what would be the best way to proceed.
Suggestion:
FATAL: WAL was generated with wal_level=minimal, cannot continue recovering
DETAIL: This happens if you temporarily set wal_level=minimal on the primary
server.
HINT: Create a new standby from a new base backup after setting
wal_level=replica.
Yours,
Laurenz Albe
t; * Some very minor wording changes.
>
> * catversion bump (for once I didn't forget it!)
Thank you!
You included the catversion bump, but shouldn't PGSTAT_FILE_FORMAT_ID
in "include/pgstat.h" be updated as well?
Yours,
Laurenz Albe
robably people who care enough about their database to have
some monitoring in place that warns them about approaching transaction
wraparound
("datfrozenxid" and "datminmxid" in "pg_database").
People who lower the limit to get rid of the warning are hopeless, and there is
no need to support such activity.
So I don't see much point in making this configurable.
We have enough parameters as it is.
Yours,
Laurenz Albe
't cause
problems, but I still think that primary keys should change as little as
possible.
Yours,
Laurenz Albe
atch.
> I also enriched the new tap tests to show this perspective.
Looks good, thanks.
I'll mark this patch as "ready for committer".
Yours,
Laurenz Albe
mple output in the manual.
> The fix is attached.
+1. That was obviously an oversight.
Yours,
Laurenz Albe
(errmsg("hot standby is not possible
> because wal_level was not set to \"replica\" or higher on the primary
> server"),
> errhint("Either set wal_level to
> \"replica\" on the primary, or turn off hot_standby here.")));
>
> With the patch, we never reach the above code?
Right, that would have to go. I didn't notice that.
Yours,
Laurenz Albe
rver to start with "wal_level=minimal", you
must
set "archive_mode=off" and "max_wal_senders=0", and few people will do that and
still expect recovery to work.
My vote is that we should not have a GUC for such an unlikely event, and that
stopping recovery is good enough.
Yours,
Laurenz Albe
or
> withdrawn.
> Thank you for your explanation.
Well, that's just my opinion.
Fujii Masao seemed to disagree with the patch, and his voice carries weight.
Yours,
Laurenz Albe
patch where the second, now superfluous,
error message is removed.
Yours,
Laurenz Albe
by pgindent.
Looks good to me.
I'll set it to "ready for committer" again.
Yours,
Laurenz Albe
understand why. I think that this needs some more comments to
make this clear.
Is this new message level something we need to allow setting for
"client_min_messages" and "log_min_messages"?
Yours,
Laurenz Albe
On Tue, 2021-01-26 at 11:09 -0500, Dave Cramer wrote:
> On Tue, 26 Jan 2021 at 05:05, Laurenz Albe wrote:
>
> > I wonder about the introduction of the new USER_ERROR level:
> >
> > #define WARNING_CLIENT_ONLY20 /* Warnings to be sent to c
;t go through the normal transaction rollback steps,
but issue an error message.
At least we should fake it well...
Yours,
Laurenz Albe
On Mon, 2021-02-01 at 23:33 +0900, Masahiko Sawada wrote:
> I've closed this commitfest. If you have feedback or comment on my CFM
> work, please tell me here or by directly emailing me.
I think you did an excellent job.
Yours,
Laurenz Albe
ed to implement
"poly_distance", fine.
About the back branches, removing the documentation is a good choice.
I think the lack of complaints is because everybody who needs serious
geometry processing uses PostGIS.
Yours,
Laurenz Albe
doubt the claim that the average Postgres user needs this, and
> doubt even more that they need it on all the time.
> So I'm -1 on the idea.
I set "track_io_timing" to "on" all the time, same as "log_lock_waits",
so I'd want them both on by default.
Yours,
Laurenz Albe
t this, starting with
"Access to tables referenced in the view is determined by permissions of the
view owner."
This looks like the best place to me (and it would need to be adapted anyway).
Yours,
Laurenz Albe
ore targeted
> > approaches mentioned in the thread and see if any of them can be
> > used/improved to achieve the desired result?
>
> Other methods are not as easy-to-use, and more complex to implement.
Fast and loose often takes less effort, yes.
Yours,
Laurenz Albe
way to do that, but I cannot see how that would be any
more crash safe than this patch. Besides, the feature doesn't exist yet.
So I think that argument doesn't carry much weight.
Yours,
Laurenz Albe
LOGGED, it somehow remembers that it is not crash safe and is
emptied if there is a crash before the next checkpoint?
Wouldn't that cause corruption if you restore from an earlier backup?
At least with the feature in this thread we'd get an error on recovery.
Yours,
Laurenz Albe
On Mon, 2021-03-22 at 13:22 -0400, Stephen Frost wrote:
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > On Mon, 2021-03-22 at 11:05 -0400, Stephen Frost wrote:
> > > > Perhaps allowing to set unlogged tables to logged ones without writing
> > > > WAL
&g
;ve included a
> > rollup patch, equivalent to applying all five patches.
>
> I committed prerequisites from one thread, so here's a rebased rollup patch.
I am happy to see this problem tackled!
Yours,
Laurenz Albe
> The discrepancy comes from the fact that the sequential scan checks the
> condition using point_inside() / lseg_crossing(), while the gist index will
> check the condition using box_overlap() / box_ov(), which have different
> opinions on how to handle NaN.
>
> Getting a consistent behavior shouldn't be hard, but I'm unsure which behavior
> is actually correct.
I'd say that this is certainly wrong:
SELECT point('NaN','NaN') <@ polygon('(0,0),(1,0),(1,1),(0,0)');
?column?
--
t
(1 row)
Yours,
Laurenz Albe
g. What do
> you think about makeing NaN-involved comparison return NULL? If you
> agree to that, I'll make a further change to the patch.
If you think of "NaN" literally as "not a number", then FALSE would
make sense, since "not a number" implies "not a number between 0 and 1".
But since NaN is the result of operations like 0/0 or infinity - infinity,
NULL might be better.
So I'd opt for NULL too.
Yours,
Laurenz Albe
rest in solving this.
Thank you for your willingness to help!
Sure, this is the place to discuss your idea, go ahead.
Right now is the end of the final commitfest for v14, so people
are busy getting patches committed and you may get less echo than normally.
Yours,
Laurenz Albe
and 1".
> > But since NaN is the result of operations like 0/0 or infinity - infinity,
> > NULL might be better.
> > So I'd opt for NULL too.
>
> Thanks. Do you think it's acceptable that returning false instead of
> NULL as an alternative behavior?
Yes, I think that is acceptable.
Yours,
Laurenz Albe
(ucs >= 0xffe0 && ucs <= 0xffe6) ||
- (ucs >= 0x2 && ucs <= 0x2)));
+ (ucs >= 0x2 && ucs <= 0x2) ||
+ (ucs >= 0x1f300 && ucs <= 0x1faff))); /* symbols and emojis */
}
/*
This is guesswork based on the unicode entries that look like symbols.
Yours,
Laurenz Albe
On Mon, 2021-03-15 at 17:09 +, Bossart, Nathan wrote:
> On 3/15/21, 7:06 AM, "Laurenz Albe" wrote:
> > On Fri, 2021-03-12 at 21:41 +, Bossart, Nathan wrote:
> > > On 3/12/21, 11:14 AM, "Joe Conway" wrote:
> > > > Looking back at the
ions, so this could be seen as an independent problem.
I don't know if Seamus is still working on that; if not, we might
mark it as "returned with feedback".
Perhaps Amit's patch 0001 should go in independently.
I'll mark the patch as "waiting for author".
Yours,
Laurenz Albe
"Either use a later backup, or recover to a point in time before \"wal_level\"
was set to \"minimal\"."
I'd say that we can leave it to the intelligence of the reader to
deduce that recovering to an earlier time means more data loss.
Yours,
Laurenz Albe
On Sat, 2021-04-03 at 17:43 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > Attached is version 6.
>
> Pushed with some mostly-cosmetic fiddling.
>
> One thing I changed that wasn't cosmetic is that as you had it,
> the behavior of "\e file" varied depe
mewhere?
If it is a procedural language as the name suggests, you probably don't have
to modify PostgreSQL core code to make it work.
Yours,
Laurenz Albe
On Thu, 2020-07-23 at 18:16 +0500, Ahsan Hadi wrote:
> On Wed, Jul 8, 2020 at 4:17 PM Laurenz Albe wrote:
> > Here is a patch that adds the following to pg_stat_database:
> > - number of connections
>
> Is it expected behaviour to not count idle connections? The connection
uish between the class of returned errors it's
> hard to see how we can do better though.
>
> While poking at this, we might as well update the docs to point to the right
> URL for CrackLib as it moved from Sourceforge five years ago. The attached
> diff fixes that.
+1 on both patches.
Yours,
Laurenz Albe
On Mon, 2020-08-10 at 09:29 +0300, Anna Akenteva wrote:
> On 2020-07-07 01:08, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > On 2020-Jul-05, Anna Akenteva wrote:
> > > > -- Swapping primary key's index for an equivalent index,
> > > > -- but with INCLUDE-d attributes.
> > > > CREATE UNIQUE I
dmitted, the use case is pretty narrow, and I am not sure if it is
worth adding code and SQL syntax for that.
Yours,
Laurenz Albe
On Tue, 2020-08-11 at 13:53 +0200, I wrote:
> On Thu, 2020-07-23 at 18:16 +0500, Ahsan Hadi wrote:
>
> > On Wed, Jul 8, 2020 at 4:17 PM Laurenz Albe
> > wrote:
> > > Here is a patch that adds the following to pg_stat_database:
> > > - number of connections
On Fri, 2020-09-04 at 13:31 -0400, Alvaro Herrera wrote:
> On 2020-Sep-04, Laurenz Albe wrote:
> > On Fri, 2020-09-04 at 10:41 -0400, Alvaro Herrera wrote:
> > > > The value I see in this is:
> > > > - replacing a primary key index
> > > > - replacin
d introduce that feature in a weird way.
I agree that that is undesirable.
We should at least have
ALTER TABLE ... ADD PRIMARY KEY (id) INCLUDE (val);
or something before we consider this patch.
As to the information_schema, that could pretend that the INCLUDE
columns just don't exist.
Yours,
Laurenz Albe
plicated questions when
we dig deeper, such as "what about whole-row references?", tilts my vote.
If it were for free, I would say +1. But given the ratio of potential
headache versus added real-life benefit, I find myself voting -1.
Still, it is cute!
Yours,
Laurenz Albe
t for context: the -docs thread that belongs to this is
https://www.postgr.es/m/20211001163938.ifg4ayrsjwd7r6zr%40localhost
Yours,
Laurenz Albe
executeQuery("select oid, relfilenode,
relname from pg_class");
int count = 100;
while (rs.next() && count-- > 0) {
System.out.print(".");
}
rs.close();
stmt.close();
System.out.println("");
conn.close();
}
}
Yours,
Laurenz Albe
1 - 100 of 829 matches
Mail list logo
