ry, they can dump with 8.3 and restire that.
Yours,
Laurenz Albe
ted? It may not be worth worrying about,
and they can always come and make a case for that symbol to be exported.
Yours,
Laurenz Albe
la the work that's been happening on attaching collation versions
> to indexes). But personally I can't summon the motivation to work
> on that, when ICU is the *only* such infrastructure that offers
> readily program-readable versioning.
Nobody will want to hear that, but the only
d xlog /
> sequence stuff today and found this case].
I think that is a bad idea.
It will have an intolerable performance impact on OLTP queries, doubling
the number of I/O requests for many cases.
Perhaps it would make sense to document that you should never rely on
sequence values from an uncommitted transaction.
Yours,
Laurenz Albe
argument was expected before this writing. If we look at the
> nextval_interval more carefully, we can find it would not flush the xlog every
> time even the sequence's cachesize is 1. Currently It happens every 32 times
> on the nextval_internal at the worst case.
Right, I didn't think of that. Still, I'm -1 on this performance regression.
Yours,
Laurenz Albe
; ...
>
> A bit of polishing later, maybe like the attached.
That looks good to me.
Yours,
Laurenz Albe
PostgreSQL, but not
part of it.
Yours,
Laurenz Albe
ignorespace
test=> -- line that starts with space
test=> SELECT 42;
?column?
══
42
(1 row)
Now that query is not added to the history file at all.
Yours,
Laurenz Albe
On Mon, 2021-11-29 at 09:43 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > There was one other problem mentioned in the original mail, and that
> > seems to be the most serious one to me:
> > [ HISTCONTROL behavior ]
>
> The actual behavior of that option (whi
to continue to support exclusive
> backup to be at all compelling and the lack of huge issues with the new
> way restore works to make it abundently clear that we can, in fact,
> remove exclusive backup in a major version change without the world
> coming down.
I guess the lack of hue and cry was at least to a certain extent because
the exclusive backup API was deprecated, but not removed.
Yours,
Laurenz Albe
need to store those in
> pg_constraint too, which is more work that I'm going to do for this
> patch.
That makes sense; thanks for explaining.
Yours,
Laurenz Albe
t from the last commitfest is settling, I'll make a second
attempt to attract attention for this small bug fix.
The original commit was Simon's.
Yours,
Laurenz Albe
Michael Paquier wrote:
> On Mon, Apr 16, 2018 at 02:32:10PM +0200, Laurenz Albe wrote:
> > Now that the dust from the last commitfest is settling, I'll make a second
> > attempt to attract attention for this small bug fix.
> >
> > The original commit was S
nt over who uses the letter :-) Also, it would be super
> helpful if you review Alexey's patch:
> https://commitfest.postgresql.org/24/1849/
I believe that -R should be reserved for creating recovery.conf,
similar to pg_basebackup.
Everything else would be confusing.
I've been missing pg_rewind -R!
Yours,
Laurenz Albe
archive the WAL segment that contains the target.
In this case the proposed change will solve the problem.
2. Someone specified the recovery target wrong, e.g. used CET rather
than CEST in the recovery target time, so that the recovery target
was later than intended.
In that case the only solution is to start recovery from scratch.
But perhaps there are use cases I didn't think of.
Yours,
Laurenz Albe
ion to "on").
+1
Yours,
Laurenz Albe
e-time
clean-up of a table where taking a truncation lock would be too disruptive.
> If we want to change a given execution of VACUUM, then we can ALTER TABLE
> SET, VACUUM,
> and ALTER TABLE SET back.
True. That ALTER TABLE would probably need a SHARE UPDATE EXCLUSIVE lock on the
table,
and t
ld say "*may* not start", because it will if the WAL segment is still
there.
> + recommends that backup_label be removed if not
> + restoring from a backup.
> +
Yours,
Laurenz Albe
David Steele wrote:
> I added some extra language to the warning that gets emitted in the log.
> Users are more like to see that than the documentation.
>
> I also addressed a comment from another thread by adding pg_basebackup
> as .e.g. rather than or.
Looks good to me.
Magnus Hagander wrote:
> Maybe have the first note say "This method is deprecated bceause it has
> serious
> risks (see bellow)" and then list the actual risks at the end?
Good idea. That may attract the attention of the dogs among the readers.
Yours,
Laurenz Albe
will insist that *everything*
is encrypted, even your commit log (unencrypted log? everyone can
read the commits?).
Yours,
Laurenz Albe
backpatched down to 9.6 where the functions have been added.
Yours,
Laurenz Albe
From 4e9655a24a8f86b020c50431eba2376f624a3def Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 7 Mar 2019 20:50:05 +0100
Subject: [PATCH] Fix documentation of pageinspect function signatures
---
doc/src/sgm
Michael Paquier wrote:
> On Thu, Mar 07, 2019 at 09:00:24PM +0100, Laurenz Albe wrote:
> > This should be backpatched down to 9.6 where the functions have been
> > added.
>
> Thanks, applied. The second argument name of heap_page_item_attrs is
> actually "page&quo
to avoid that, since they
> should rely on the base tables rather than on the views.
This may make things easier for those who are confused by a negative
entry, but it will obfuscate matters for those who are not.
I don't think that is a win, particularly since the semantics are
explained in great detail in the documentation of "pg_stats".
So I am -1 on that one.
Yours,
Laurenz Albe
antor
just because he has been superuser at some time in the past
(and doesn't hold the privilege himself).
So I'd say the behavior is fine as it is, but it would not harm to
document it better (or at all).
Yours,
Laurenz Albe
Peter Eisentraut wrote:
> On 2019-05-08 16:49, Laurenz Albe wrote:
> > I believe we should have both:
> >
> > - Identity columns should only use sequences with an INTERNAL dependency,
> > as in Peter's patch.
>
> I have committed this.
Thanks!
> >
Peter Eisentraut wrote:
> On 2019-05-08 16:49, Laurenz Albe wrote:
> > I believe we should have both:
> >
> > - Identity columns should only use sequences with an INTERNAL dependency,
> > as in Peter's patch.
>
> I have committed this.
Since this is
able, and tuple locks
are *not* maintained there, but in the "xmax" of the row itself.
To see all tuple locks in pg_locks would require a sequential
scan of all tables which have certain locks on them, which is not
going to happen.
Yours,
Laurenz Albe
[CC to -hackers]
Dave Cramer wrote:
> On Mon, 26 Aug 2019 at 13:43,
Laurenz Albe
> wrote:
> > Dave Cramer wrote:
>
> > As I said, I'd entertain a connection parameter that switched the
>
> > CALL to call procedures but ideally you'd complain to the serv
ack.
If you feel that you have enough buy-in, you can add the patch to the next
commitfest. The ultimate test is then if you can attract reviewers that
examine your patch and committers that are willing to spend time to
commit it.
I am aware that this process can be quite tiresome and discouraging, but
any patch that makes it through will be much improved by it.
Yours,
Laurenz Albe
Geoff Winkless wrote:
> Can we not just say "ctrl-D to quit" instead of \q? Doesn't that work
> everywhere?
Not on Windows, as far as I know.
Yours,
Laurenz Albe
elete all replication slots.
Yours,
Laurenz Albe
use it.
Having said all that, I can imagine that having \desc and \describe as an
alternative to \d would help beginners who come e.g. from Oracle,
but that would mean a change of the current behavior:
test=> \describe
List of foreign servers
Name | Owner | Foreign-data wrapper
+--+--
oracle | postgres | oracle_fdw
(1 row)
This is because \des lists foreign servers, and the rest of the command is
ignored.
Yours,
Laurenz Albe
ansaction snapshot, so the function
could see no tuples older than the statement's snapshot.
So VACUUM could remove tuples that were visible when the transaction
started, but are not visible in the current statement's snapshot.
Of course a C function could completely ignore MVCC and access any
old tuple, but do we want to cater for that?
Yours,
Laurenz Albe
urns in the patch, but after I
removed them, it applied fine.
Yours,
Laurenz Albe
, but there is still the need to run
ALTER INDEX on all affected indexes to keep PostgreSQL from nagging.
Perhaps the situation could be improved with a pg_upgrade option
--i-know-my-indexes-are-fine that causes a result like #2.
Together with a bold note in the release notes, this may relieve
the pain.
Yours,
Laurenz Albe
hat table.
I think that is an unpleasant surprise. I'd expect that if I drop a database
and restore it from a dump, it should be as it was before. This change would
break that assumption.
What are the use cases of a dump with foreign table data?
Unless I misunderstood something there, -1.
Yours,
Laurenz Albe
n Windows?
A quick web search seems to indicate that Windows has no statfs(2).
What's more is that the Linux man page says that statfs(2) is
Linux-specific.
I think that if we have such a feature (which I think would be useful)
should be available for all operating systems supported by PostgreSQL.
Yours,
Laurenz Albe
table.
Should I compose a doc patch, or is that too much of a corner case
to mention? I wanted to ask before I do the repetetive work.
Yours,
Laurenz Albe
On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > I realized only today that if role A is a member of role B,
> > A can ALTER and DROP objects owned by B.
> > I don't have a problem with that, but the documentation seems to
> > suggest o
On Fri, 2019-11-15 at 13:41 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote:
> > > It might be worth clarifying this point in section 5.7,
> > > https://www.postgresql.org/docs/devel/ddl-priv.html
> > > but l
with more than 500, tuples are candidates for an
> autovacuum before they would with current default values.
I think this is unnecessary.
Usually you have problems only with a few tables, and it is no problem
to set autovacuum parameters on these individually.
Yours,
Laurenz Albe
On Tue, 2019-11-19 at 13:21 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Fri, 2019-11-15 at 13:41 -0500, Tom Lane wrote:
> > > Laurenz Albe writes:
> > > > On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote:
> > > > > It might be worth clarifyi
ot;dropuser"
explicitly connect to the "postgres" database rather than using
"connectMaintenanceDatabase()" like the other scripts, which would try
the database "postgres" first and fall back to "template1".
This is unrelated to the patch, but low-hanging fruit for unified behavior.
Yours,
Laurenz Albe
xxx (cost=0.00..194.00 rows=60 width=4) (actual
> time=0.041..4.276 rows=11000 loops=1)
I think that this is asking for a planner support function:
https://www.postgresql.org/docs/current/xfunc-optimization.html
Yours,
Laurenz Albe
tovacuum
> runs on all the tables in the list.
That means that all partitions are vacuumed if only one of them needs it,
right? This will result in way more vacuuming than necessary.
Wouldn't it be an option to update the partitioned table's statistics
whenever one of the partitions is vacuumed?
Yours,
Laurenz Albe
overflowing, so just
> comparing the cost suffices.
Doesn't that rely on a specific implementation of double precision (IEEE)?
I thought that we don't want to limit ourselves to platforms with IEEE floats.
Yours,
Laurenz Albe
u a lot. Another nice aspect is that this is an activity that can easily
be adjusted to span three months; if you embark on a new feature, the
three months may pass without your patch getting accepted.
Yours,
Laurenz Albe
call it
"read-only" if it is allowed on a streaming replication standby?
The first would be more correct, but the second may be more convenient.
Yours,
Laurenz Albe
urrently say "it is recommended to use pg_dumpall
from the newer version". They don't say "is is not supported".
Yours,
Laurenz Albe
an identity column.
I think this should be backpatched.
Yours,
Laurenz Albe
From ab536da87fa8ffc70469d3dbdaf3e1b84b0ef793 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sun, 14 Apr 2019 17:37:03 +0200
Subject: [PATCH] Make sure identity columns own only a single sequence
If an identity column o
without forbidding anything, since normal OWNED BY dependencies are "auto".
What do you think?
Yours,
Laurenz Albe
a foreign table if the FDW
implements BeginForeignInsert. The attached patch implements that.
I think this should be backpatched to v11.
Yours,
Laurenz Albe
From c4b0e871658c757124dad992578da0b60fccf962 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sat, 20 Apr 2019 13:36:56 +0200
Subject: [PATCH
On Mon, 2019-04-22 at 21:45 +0900, Etsuro Fujita wrote:
Thanks for looking into this!
> (2019/04/20 20:53), Laurenz Albe wrote:
> > On Fri, 2018-04-06 at 23:24 +, Robert Haas wrote:
> > > Allow insert and update tuple routing and COPY for foreign tables.
> > >
On Mon, 2019-04-22 at 16:24 -0400, Robert Haas wrote:
> On Mon, Apr 22, 2019 at 3:37 PM Laurenz Albe wrote:
> > Sure, it is not hard to modify a FDW to continue working with v11.
> >
> > My point is that this should not be necessary.
>
> I'm not sure whether t
On Mon, 2019-04-22 at 13:27 -0700, Andres Freund wrote:
> On 2019-04-22 21:37:25 +0200, Laurenz Albe wrote:
> > Commit 3d956d956a introduced support for foreign tables as partitions
> > and COPY FROM on foreign tables.
> >
> > If a foreign data wrapper supports data mo
FDWs. I think this
> ship simply has sailed.
I can accept that (having fixed my own FDW), but I am worried that it will
cause problems for FDW users. Well, I guess they can always avoid COPY if
they don't want FDWs to crash.
Yours,
Laurenz Albe
mation.
That may wall be a bug in oracle_fdw, since I have no reports of
anybody running it on that operating system.
Maybe you should open an oracle_fdw issue, but I don't know how
much I can help you, since this is the first time I have heard
of SmartOS.
Yours,
Laurenz Albe
broken by that API change as well
if it hasn't been patched.
At the very least, this should have been mentioned in the list of
incompatible changes for v11.
Yours,
Laurenz Albe
y
Multicorn FDW with write support is currently broken.
As Andres has argued above, it is too late to do anything more about
it than to document this and warn FDW authors as good as we can.
Yours,
Laurenz Albe
the problem
> without forbidding anything, since normal OWNED BY dependencies are "auto".
>
> What do you think?
Here is a patch that illustrates the second approach.
I'll add this thread to the next commitfest.
Yours,
Laurenz Albe
From 7f7bae5315b7770f1327a80eb192bb098
t.
>
> These seem a bit redundant to me [...]
>
> OK, how about something like the attached? I reworded this a bit, though.
I like your patch better than my wording.
Thanks for the effort!
Yours,
Laurenz Albe
On Thu, 2019-04-25 at 09:55 +0900, Michael Paquier wrote:
> On Sun, Apr 14, 2019 at 05:51:47PM +0200, Laurenz Albe wrote:
> > test=> INSERT INTO ser (id) VALUES (DEFAULT);
> > ERROR: more than one owned sequence found
>
> Yes this should never be user-triggerable, so
h more intuitive from
the user's perspective.
Correct me if I am wrong, but the sequence behind identity columns
should be an implementation detail that the user doesn't have to know about.
So the error message about "owned sequences" is likely to confuse users.
I have had a report by a confused user, so I think the problem is real.
Yours,
Laurenz Albe
On Sat, 2019-04-27 at 14:16 +0200, Peter Eisentraut wrote:
> On 2019-04-26 15:37, Laurenz Albe wrote:
> > What do you think of the patch I just posted on this thread to
> > remove ownership automatically when the default is dropped, as Michael
> > suggested? I think that w
nfinity',
and adding one to infinity does not change the value.
I propose the attached patch which fixes the problem.
Yours,
Laurenz Albe
I wrote:
> I propose the attached patch which fixes the problem.
I forgot to attach the patch. Here it is.
Yours,
Laurenz Albe
From 6bbad0acf3baae3a08d1f911b7017642c8a8afe9 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 2 May 2019 14:32:27 +0200
Subject: [PATCH] Don't cano
On Thu, 2019-05-02 at 22:43 +0200, Peter Eisentraut wrote:
> On 2019-04-29 18:28, Laurenz Albe wrote:
> > I still think thatthat there is merit to Michael's idea of removing
> > sequence "ownership" (which is just a dependency) when the DEFAULT
> > on the col
On Tue, 2019-05-07 at 13:06 +0900, Michael Paquier wrote:
> On Fri, May 03, 2019 at 08:14:35AM +0200, Laurenz Albe wrote:
> > On Thu, 2019-05-02 at 22:43 +0200, Peter Eisentraut wrote:
> >> I think the proper way to address this would be to create some kind of
> >> depe
emote logins
with that user.
But for your application users LDAP authentication is a fine thing, and not
hard to set up if you know a little bit about LDAP.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
Haribabu Kommi wrote:
> On Thu, Jul 19, 2018 at 10:59 PM Haribabu Kommi
> wrote:
> > On Wed, Jul 18, 2018 at 10:53 PM Robert Haas wrote:
> > > On Wed, Jul 4, 2018 at 9:14 AM, Laurenz Albe
> > > wrote:
> > > > What about keeping the first successful
Michael Paquier wrote:
> On Thu, Sep 20, 2018 at 09:45:09PM +0200, Laurenz Albe wrote:
> > That message is wrong, because "rel" and not "pkrel" is the partitioned
> > table.
> > I think it should be
> >
> > ereport(ERROR,
&
ttached. Thoughts?
I'm fine with it.
"cannot use ONLY for foreign key on partitioned table" has a funny ring
to it (after all, ONLY was used for the table, not the foreign key), but
since I could not come up with anything better, I guess there is just
no entirely satisfactory way to phrase it tersely.
Yours,
Laurenz Albe
e verbose if that avoids confusion.
Yours,
Laurenz Albe
From a5de6f9893e049bf97810e41530907e237f909d7 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Mon, 8 Oct 2018 17:59:37 +0200
Subject: [PATCH] Add pg_promote() to promote standby servers
---
doc/src/sgml/func.sgml | 20
, where I think a call to pg_promote should
> trigger an error. This is not handled in the patch.
So far I had returned "false" in the last case, but I am fine with
throwing an error in that case. Done.
> An other thing which has value is to implement a "wait" mode f
Ashwin Agrawal wrote:
> Just curious to know, is promotion via function only allowed for
> hot-standby or works for any standby?
Only for hot standby - how do you want to execute a function on a standby
server that doesn't allow connections?
Yours,
Laurenz Albe
s.
Ok, added as a new parameter "wait_seconds".
> Is the function marked as strict? Per the code it should be, I am not
> able to test now though.
Yes, it is.
> You are missing REVOKE EXECUTE ON FUNCTION pg_promote() in
> system_views.sql, or any users could t
I wrote:
> Fixed.
Here is another version, with a fix in pg_proc.dat, an improved comment
and "wait_seconds" exercised in the regression test.
Yours,
Laurenz Albe
From a2a7f9fd1b23ad102d11992b22158dab8b5451d5 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sat, 20 Oct 2018 0
eFile(promote_file))
> + ereport(ERROR,
> + (errcode_for_file_access(),
> +errmsg("could not write file \"%s\": %m",
> + PROMOTE_SIGNAL_FILE)));
>
> Maybe we should unlink PROMOTE_SIGNAL_FILE before erroring.
Yes, that cannot hurt.
Yours,
Laurenz Albe
to me; surely you wouldn't change the syntax in
postgresql.conf.
One good road to get into PostgreSQL development is by reviewing patches.
That allows you to learn from others and get to know parts of the code
you are not yet familiar with.
There is always a shortage of reviewers!
Yours,
Laurenz Albe
ing me than it would have taken you to write this yourself.
Yours,
Laurenz Albe
t.
> So, I wrote a prototype patch.
Thank you!
You should add this to the next commitfest:
https://commitfest.postgresql.org/20/
Please make sure to read the Developer FAQ if you haven't already done it:
https://wiki.postgresql.org/wiki/Developer_FAQ
Yours,
Laurenz Albe
MyungKyu LIM wrote:
> I saw this topic in todo list,
>
> so I implemented simple patch.
>
> https://www.postgresql.org/message-id/flat/1657809367.407321.1533027417725.JavaMail.jboss%40ep2ml404
For the archives' sake, please always reply on the original thread.
Yours,
Laurenz Albe
be right from the start.
>
> Attached is a patch to fix that. Any comments or objections?
Hmm, I should have noticed that.
I think that the question if pg_promote allows a parallel plan or not
is mostly academic, but the two definitions should be kept in sync.
Yours,
Laurenz Albe
Michael Paquier wrote:
> On Mon, Oct 29, 2018 at 09:41:08AM +0100, Laurenz Albe wrote:
> > I think that the question if pg_promote allows a parallel plan or not
> > is mostly academic, but the two definitions should be kept in sync.
>
> It seems to me that the presence of the
e.
He who is tempted to run his application with a superuser for
simplicitly's sake will not be the person to set a connection limit
for superusers.
I concur with Tom that this will do more harm than good.
Yours,
Laurenz Albe
involved in having the relcache call
> cost_qual_eval.
That was my impression too when I had a closer look at this feature.
What about an option "hot_update_check" with values "off" (default),
"on" and "always"?
Yours,
Laurenz Albe
Haribabu Kommi wrote:
> Added comments along the lines that you mentioned. And also try
> to update some more comments.
Looks ok to me, I'll mark it as "ready for committer".
Yours,
Laurenz Albe
Tom Lane wrote:
> Laurenz Albe writes:
> > Haribabu Kommi wrote:
> > > Added comments along the lines that you mentioned. And also try
> > > to update some more comments.
> > Looks ok to me, I'll mark it as "ready for committer".
>
> I don&#
so important to do it at the end of the relation?
If the answer is "just because we can do it easily", then I think it would be
ok to disable the feature in cases where it causes problems.
Yours,
Laurenz Albe
your hosts list when
> you want prefer-slave.
If you know which is which, certainly.
But in a setup with automated failover you cannot be certain which is which.
That's what the proposed feature targets.
Yours,
Laurenz Albe
uot;? Of course that opens
another way to corrupt your database (by starting it from a backup
without first creating "recovery.conf"), but we could add another
big warning.
I'd say that the people who ignore such a warning are the same
people that happily remove "backup_label" when they see the following
message upon starting a cluster from a backup without recovery:
If you are not restoring from a backup, try removing the file "backup_label".
Yours,
Laurenz Albe
it? That sure wouldn't be unsafe.
If somebody prefers a simpler backup method at the price of having to
manually restart the server after a crash, what's wrong with that?
Why not give them the choice?
I'd say that one could write a server start script that just removes
"backup_label", but I am sure someone will argue that then somebody
will restore a backup and then restart the server without first
recovering the database...
Yours,
Laurenz Albe
t’s a good API while
> ignoring
> the issues that it has doesn’t change that.
I don't think I'm ignoring the issues, I just think there is a valid use case
for
the exclusive backup API, with all its caveats.
Of course I'm not arguing on behalf of organizations running lots of databases
for whom manual intervention after a crash is unacceptable.
I'm arguing on behalf of users that run a few databases, want a simple backup
solution and are ready to deal with the shortcomings.
But I will gladly accept defeat in this matter, I just needed to vent my
opinion.
Yours,
Laurenz Albe
formation, but it sure is
> > inconvenient. Simplicity is good in backup solutions, because complicated
> > things tend to break more easily.
>
> Not sure what communication is necessary here..? The data needed for the
> backup
> label file comes from pg_stop_backup in a non-exclusive backup.
Right, and pg_stop_backup has to be run from the "pre-backup" script.
Yours,
Laurenz Albe
tunately it is not simple to come up with one that doesn't exhibit
the problems of the existing exclusive backup.
Perhaps it's theoretically impossible. The goal is to disambiguate what a file
system backup sees in backup mode and what the startup process sees after a
crash
in backup mode, and I can't see how that could be done.
Yours,
Laurenz Albe
e nonetheless, write into the release notes that certain indexes
have to be rebuilt after upgrade.
Of course, there is no problem to mark pg_config as stable, because
there is little chance it will be used in an index anyway.
Yours,
Laurenz Albe
functions IMMUTABLE
even if they might change owing to bug fixes, I didn't make it clear that
each such occurrence would necessitate a fat warning in the release notes
that indexes using them have to be rebuilt.
Yours,
Laurenz Albe
uld not open relation with OID 24836
If not, what could be done about it?
Yours,
Laurenz AlbeFrom 57e42f0a32be39eea541808979a41ab6feac6b73 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Mon, 19 Feb 2018 12:17:59 +0100
Subject: [PATCH] Add support for NEXT VALUE FOR
NEXT VALUE FOR is the stand
Tom Lane wrote:
> Laurenz Albe writes:
> > The SQL standard has the expression "NEXT VALUE FOR asequence" to do
> > what we traditionally do with "nextval('asequence')".
> > This is an attempt to implement this on top of the recently introduced
101 - 200 of 852 matches
Mail list logo
