Em seg., 21 de fev. de 2022 às 13:13, Zheng Li
escreveu:
>
> 2. Table level
> Allows DDLs on the published tables to be replicated except for
> certain edge cases.
>
> Think how to handle triggers and functions with same name but different
purpose.
Publisher
create function public.audit() return
A question I always have, and I didn´t find anybody answering it. If it´s
possible
select * from MyDB.MySchema.MyTable;
And from user point of view ... all databases are accessible for the same
postgres instance, user just says connect to this or that database, why is
it not possible to do
select
>
> For example, if I define a variable called "relkind", then psql's \sv
> meta-command is broken because the query it performs can't distinguish
> between the column and the variable.
>
> If variables use : as prefix you´ll never have these conflicts.
select relkind from pg_class where relkind =
Postgres weekly came today with this interesting article:
https://hakibenita.com/sql-medium-text-performance
The problem it explains is when you have no one records being stored on
toast, even if they are toastable. That is because the size of that column
fits on toast_tuple_target size, so it doe
Em qua., 27 de out. de 2021 às 16:48, Marcos Pegoraro
escreveu:
> Postgres weekly came today with this interesting article:
> https://hakibenita.com/sql-medium-text-performance
>
> The problem it explains is when you have no one records being stored on
> toast, even if they are
Why this happens ?
create table t(i int);
CREATE TABLE
insert into t values(1);
INSERT 0 1
select (ctid::text::point)[1]::int, * from t;
ctid | i
--+---
1 | 1
(1 row)
update t set i = i;
UPDATE 1
select (ctid::text::point)[1]::int, * from t;
ctid | i
--+---
2 | 1
(1 row)
If noth
>
> Because it takes resources to determine that nothing changed. If you want
> to opt-in into that there is even an extension trigger that makes doing so
> fairly simple. But it's off by default because the typical case is that
> people don't frequently perform no-op updates so why eat the expen
>
> I get the idea of letting the server centralize logic like this - but
> frankly if the application is choosing to send all that data across the
> wire just to have the server throw it away the application is wasting
> network I/O. If it does manage its resources carefully then the server
> wil
>
> I suppose if the application side cannot be trusted to code to a
> specification without having the server side add validation and/or
> compensation code to catch the bugs then, yes, one option is to have the
> server side do extra work. There are other solutions, some of which are
> not even
>
> suppress_redundant_updates_trigger was created precisely because it's
> not always easy to create application code in such a way that it
> generates no redundant updates. However, there is a cost to using it,
> and the break even point can be surprisingly high. It should therefore
> be used wit
A publication for all tables was running fine, Master is a PostgreSQL
11.11. Replica was running version 13 (don´t remember minor version).
Then we tried to update only subscriber server, nothing was done on master
side.
Then we did ...
- installed postgresql-14.
- configured postgresql.conf to b
>
> The reason is after an upgrade, there won't be any data in
> pg_subscription_rel, and only when you tried to refresh it is trying
> to sync again which leads to the "duplicate key value ..." problem you
> are seeing.
>
> So, is pg_upgrade populating pg_subscription and not pg_subscription_rel ?
>
> AFAIU the main problem in your case is that you didn't block the write
> traffic on the publisher side. Let me try to understand the situation.
> After the upgrade is finished, there are some new tables with data on
> the publisher, and did old tables have any additional data?
>
Correct.
>
> A
>
> I think we don't want to make assumptions about the remote end being
> the same after the upgrade and we let users reactivate the
> subscriptions in a suitable way. See [1] (Start reading from "..When
> dumping logical replication subscriptions..") In your case, if you
> wouldn't have allowed n
>
> On thinking about this point again, it is not clear to me why that
> would matter for this particular use case? Basically, when you create
> a new subscription, it should copy the entire existing data from the
> table directly and then will decode changes from WAL. So, I think in
> your case al
>
> > 2138: Incremental Materialized View Maintenance
>
> I've responded to it in the following thread, and described the recent
> discussions,
> current status, summary of IVM feature and design, and past discussions.
>
IVM is a wonderful feature, but some features were omitted because of
its co
Sorry, I didn´t explain exactly what I was doing, I just wrote "This
replication is a auditing database" on my second email.
Atenciosamente,
Em seg., 29 de nov. de 2021 às 09:20, Amit Kapila
escreveu:
> On Mon, Nov 29, 2021 at 5:04 PM Marcos Pegoraro wrote:
> >>
>
>
> I think the reason why we can't update a materialized view directly is
> because
> it is basically a "view" and it should not contains any data irrelevant to
> its
> definition and underlying tables. If we would have a feature to update a
> materialized view direcly, maybe, it should behave as
Is enough from 1970 ?
How about if user wants to have an UUID of his birth date ?
regards
Marcos
Em qua., 24 de jan. de 2024 às 13:54, Andrey M. Borodin <
x4...@yandex-team.ru> escreveu:
>
>
> > On 24 Jan 2024, at 20:46, Aleksander Alekseev
> wrote:
> >
> > Only the
> > fact that timestamp fro
ua., 24 de jan. de 2024 às 14:51, Andrey Borodin
escreveu:
>
>
> > On 24 Jan 2024, at 22:00, Marcos Pegoraro wrote:
> >
> > Is enough from 1970 ?
> Per standard unix_ts_ms field is a number of milliseconds from UNIX start
> date 1970-01-01.
>
> > How about i
This is my first patch, so sorry if I miss something.
If I have a function which returns lots of columns and any of these columns
returns a wrong type it's not easy to see which one is that column because
it points me only to its position, not its name. So, this patch only adds
that column name, j
>
> I agree with your idea and try to implement it and will soon attach a
> patch with a solution.
>
Additionally, if those OR constants repeat you'll see ...
If all constants are the same value, fine
explain select * from x where ((ID = 1) OR (ID = 1) OR (ID = 1));
Index Only Scan using x_id on x
On a multi tenant server, with hundreds of schemas with same structure, I
have an audit table shared with all of them. When any record is deleted I
add on this table tenant, table and PK values, just that. Something like
this:
drop table if exists audit;
create table audit(id serial primary key,
c
Em dom., 29 de jan. de 2023 às 09:24, Dmitry Dolgov <9erthali...@gmail.com>
escreveu:
> > On Fri, Jan 27, 2023 at 08:15:29PM +0530, vignesh C wrote:
> > The patch does not apply on top of HEAD as in [1], please post a rebased
> patch:
>
> Thanks. I think this one should do the trick.
>
There is a
Em seg., 6 de fev. de 2023 às 10:59, Erik Wienhold
escreveu:
> > On 06/02/2023 12:20 CET Marcos Pegoraro wrote:
> >
> > I was just playing with some random timestamps for a week, for a month,
> > for a year ...
> >
> > select distinct current_date+((random():
>
> The years are converted to months and the fractional month is rounded half
>> up:
>>
>> 1.05 year = 12.6 month
>> => 1 year 0.6 month
>> => 1 year 1 month(after rounding)
>>
>> Compare that to 12.5 months to see when the rounding occurs:
>>
>> 12.5 month
Having a sup_user and a normal_user, login with sup_user
select session_user, current_user
sup_user, sup_user
set role normal_user;
select session_user, current_user
sup_user, normal_user
But then, when sup_user was running with normal_user grants an exception
occurs
select * from Some_Schema.Som
I don´t know how to create a patch, maybe someday, but for now I´m just
sending this little problem if somebody can solve it.
In a multi schema environment where several tables has same structure is a
little bit hard to know which one already has that primary key.
On log I see now on replica serv
"","Key (customer_id)=(530540) already
exists.""","logical replication worker",,6675519194010520265
2022-06-28 08:18:24.160 -03,,,2009,,62b35392.7d9,88469,,2022-06-22 14:38:26
-03,,0,LOG,0,"background worker ""logical replication work
I have to fix log files because its content is not properly formatted, I´m
using version 14.4 but that happened when I was using version 11 too. It
happens only when that statement is huge, or because it is a long sequence
of updates in a WITH or DO statements, or because i´m updating a bytea
field
it´s csvlog only
Atenciosamente,
Em dom., 7 de ago. de 2022 às 11:12, Tom Lane escreveu:
> Marcos Pegoraro writes:
> > I have to fix log files because its content is not properly formatted,
>
> What mechanism are you using to store the log? If syslog is involved,
> it
>
>
> How are you running postgres? If the logger process runs into trouble it
> might
> write to stderr.
>
> Is there a chance your huge statements would make you run out of space?
>
> Well, I don't think it is a out of space problem, because it
doesn´t stop logging, it just splits that message.
>
> What platform is this on? Is it possible that on some platform the chunk
> size we're using is not doing an atomic write?
>
Until last year we were Ubuntu 16.04 and Postgres 11 with the latest minor
update.
This January we changed to Ubuntu 20.04 and Postgres 14, now updated to
14.4.
But the
>
> OK, we really need a repeatable test if possible. Perhaps a pgbench run
> with lots of concurrent runs of a some very long query would do the trick.
>
OK, I can do it but ... strangely that error usually occurs at random
times, sometimes at 08:00, sometimes at 19:00, and it's busier between
10
Hi Hackers,
Alphabetical order of triggers sometimes makes me write a_Recalc or z_Calc
to be sure it´ll be the first or the last trigger with same event of that
table
Oracle and SQL Server have FOLLOWS and PRECEDES when defining trigger
execution order. Firebird has POSITION, which I like it more
This problem can raise ... there is a trigger foo using position 1, please
choose another
Atenciosamente,
Em qua., 15 de set. de 2021 às 07:59, Daniel Gustafsson
escreveu:
> > On 15 Sep 2021, at 12:28, Marcos Pegoraro wrote:
>
> > CREATE TRIGGER RECALC_THAT BEFORE UPDAT
This way would be interesting for those are migrating from these databases
too. But ok, I´ll forget it.
Em qua., 15 de set. de 2021 às 08:40, Tom Lane escreveu:
> Marcos Pegoraro writes:
> > Alphabetical order of triggers sometimes makes me write a_Recalc or
> z_Calc
> > t
PM, Tom Lane wrote:
> > Marcos Pegoraro writes:
> >> Alphabetical order of triggers sometimes makes me write a_Recalc or
> z_Calc
> >> to be sure it´ll be the first or the last trigger with same event of
> that
> >> table
> >
> >> Oracle and S
usually trigger names
have same names as their functions, so for this table I have to have a
different name just to be fired first.
Em qua., 15 de set. de 2021 às 10:51, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> On 2021-Sep-15, Marcos Pegoraro wrote:
>
> > This problem c
We can run triggers using position only, this way we don´t have these few
cycles to determine ordering.
On creation time we populate position, even if it's not set, so for the
first time position will match trigger names. When user changes a trigger
position we sum 1 to the followers.
regards,
Mar
One thing is needed and is not solved yet is delayed replication on logical
replication. Would be interesting to document it on Restrictions page,
right ?
regards,
Marcos
No, I´m talking about that configuration you can have on standby servers
recovery_min_apply_delay = '8h'
Atenciosamente,
Em seg., 20 de set. de 2021 às 23:44, Amit Kapila
escreveu:
> On Mon, Sep 20, 2021 at 9:47 PM Marcos Pegoraro wrote:
> >
> > One thing is needed
>
> oh okay, I think this can be useful in some cases where we want to avoid
> data loss similar to its use for physical standby. For example, if the user
> has by mistake truncated the table (or deleted some required data) on the
> publisher, we can always it from the subscriber if we have such a
>
> No, I´m talking about that configuration you can have on standby servers
> recovery_min_apply_delay = '8h'
>
>
> oh okay, I think this can be useful in some cases where we want to avoid
> data loss similar to its use for physical standby. For example, if the user
> has by mistake truncated the
>
> What kind of reasons do you see where users prefer to delay except to
> avoid data loss in the case where users unintentionally removed some
> data from the primary?
>
>
> Debugging. Suppose I have a problem, but that problem occurs once a week
or a month. When this problem occurs again a moni
Page explaining progress reporting views, for all versions, have "The
tables" expression several times when it points to a single table. So,
singular expressions should be used, right ?
"The tables below describe the information that will be reported and
provide information about how to interpret
>
>
> Page explaining progress reporting views, for all versions, have "The
>> tables" expression several times when it points to a single table. So,
>> singular expressions should be used, right ?
>>
>> "The tables below describe the information that will be reported and
>> provide information abo
> *Table 27.32. pg_stat_progress_analyze View*
> and
> *Table 27.33. ANALYZE phases*
>
you´re right, I didn´t see that always have a phases table later. sorry ...
Can you remove or just ignore double ; too ?
postgres=# do $$
declare var_x integer;
begin
var_x = 99;;
delete from x where x = var_x;
end; $$;
ERROR: syntax error at or near ";"
LINE 1: do $$ declare var_x integer; begin var_x = 99;; delete from ...
Atenciosamente,
Em dom., 16 de jun. d
Em dom., 16 de jun. de 2024 às 11:37, Pavel Stehule
escreveu:
>
> What is the expected benefit? Generally PL/pgSQL has very strict syntax -
> and using double semicolons makes no sense.
>
> exactly, makes no sense. That is because it should be ignored, right ?
But ok, if this is a different issue
Em dom., 16 de jun. de 2024 às 12:11, Pavel Stehule
escreveu:
> I don't follow this idea - when it does not make sense, then why do you
> use it? It can be a signal of some issue in your code.
>
>>
I don't use it, but sometimes it occurs, and there are lots of languages
which ignore it, so it wo
create event trigger ... on login is now available but it is not shown on
DOCs or is it in another page ?
https://www.postgresql.org/docs/devel/event-trigger-matrix.html
doesn't have it, should be there ?
regards
Marcos
This page has 3 items that are between parentheses, there is an explanation
why they are used this way ?
https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-TABLE
Each syntax element is described below in more detail.
*context_item*, *path_expression* [ AS *json_path_name
While seeing changes and new features of
https://www.postgresql.org/docs/devel/release-17.html
I see that there are too little links to other DOC pages, which would be
useful.
There are links to
"logical-replication", "sql-merge", "plpgsql", "libpq" and
"pgstatstatements"
But no one link is avail
-
Rename SLRU columns in system view pg_stat_slru (Alvaro Herrera)
The column names accepted by pg_stat_slru_rest() are also changed.
Is pg_stat_slru_rest() correct ?
>
> I started this time around from the newest of my patches in those
> threads, but the implementation has changed considerably from what's
> there.
>
I don´t know exactly what will be the scope of this process you're working
on, but there is a gap on foreign key constraint too.
It is possible to
Em seg., 19 de ago. de 2024 às 19:10, Bruce Momjian
escreveu:
> Should I work on this?
>
> Well, a process which does this automatically would be cool, but a
modified version of release notes for version 17 was done manually and
seems fine.
So, why not commit this version and later for version 18
Em qui., 22 de ago. de 2024 às 14:27, Tom Lane escreveu:
>
> I'd prefer to see this implemented in the website based on our
> existing markup practices. That way it would work for quite a
> few years' worth of existing release notes, not only future ones.
>
> I understand your point, and agree w
Em sex., 6 de set. de 2024 às 23:13, jian he
escreveu:
> I didn't manually click each git commit url to test it though.
Checked, all commit links are working and matching with their
regards
Marcos
Some days ago Tom Lane said ...
SELECT events & 4 != 0 AS can_upd, events & 8 != 0 AS can_ins, events & 16
!= 0 AS can_del FROM
pg_catalog.pg_relation_is_updatable('_pessoa'::regclass, false) t(events);
Well, I didn't find that function on DOCs and then I thought, are there
other functions which
Em sáb., 7 de set. de 2024 às 17:18, Tom Lane escreveu
Functions that are primarily meant to implement operators are normally not
documented separately: we feel it would bloat the
docs without adding a lot
Those two functions, elem_contained_by_range and pg_relation_is_updatable
were only example
Em sex., 13 de set. de 2024 às 13:39, Bruce Momjian
escreveu:
> I changed the patch to use the section symbol "§" instead of showing
> the hashes. The hashes seemed too detailed. Does anyone see a better
> symbol to use from here?
>
Robert and others liked commit hashes because you can do "git
Em seg., 16 de set. de 2024 às 15:15, Bruce Momjian
escreveu:
> > > I changed the patch to use the section symbol "§" instead of showing
> > > the hashes. The hashes seemed too detailed. Does anyone see a better
> > > symbol to use from here
Well, I think section symbol is not a good choice f
Em ter., 17 de set. de 2024 às 05:12, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> Add backend support for injection points (Michael Paquier) [commit 1] [2]
> [3] [4]
>
I think this way would be fine.
And it would be good to have a
target="_blank"
on commit links so a new window or tab w
Using version 16, seems strange when toast needs to be created. Tested with
domain being numeric or varchar(10) with the same results.
And If that domain is integer then no toast is created.
I think none of these tables should have a toast, right ?
postgres=# create domain mynum as numeric(15,2)
I'm now using version 14 and planning to update to 17 as soon as it comes
available. Then looking carefully to release notes to see exactly what I'll
get when updated I see lots of unexplained features. Just because release
notes does not explain exactly what that change does. And I don't have a
wa
Em sex., 26 de jul. de 2024 às 09:45, Daniel Gustafsson
escreveu:
>
> There is a way, but it's not exactly visible from reading the release
> notes.
>
Cool, didn't know that.
But why is that just a hidden comment and not a visible link for us ?
regards
Marcos
Em sex., 26 de jul. de 2024 às 10:11, Daniel Gustafsson
escreveu:
>
> That's likely the wrong level of detail for the overwhelming majority of
> release notes readers. I have a feeling this was discussed not too long
> ago
> but (if so) I fail to find that discussion now.
Wrong level ? Where i
Em sex., 26 de jul. de 2024 às 13:01, Masahiko Sawada
escreveu:
>
> +1. I've been asked a lot of times how to find the associated commit
> IDs from release note items. These links would help users know the
> details of the changes, and I believe many users would like to do
> that.
Yes, this way
Em seg., 5 de ago. de 2024 às 07:54, jian he
escreveu:
>
> [commitId_link1, commitId_link2]: Change functions to use a safe
> search_path during maintenance operations (Jeff Davis)
>
I don't like that prefix dirtying each item.
I think having just a link after every item would be better.
Firstly
Em ter., 6 de ago. de 2024 às 04:30, jian he
escreveu:
>
> you can also preview the attached screenshot to see the rendered effect.
>
Loved, except that the commit id does not help too much, so I don't think
we need it.
I think a numbered link would be better.
- Change functions to use a saf
Em qui., 8 de ago. de 2024 às 00:11, jian he
escreveu:
>
> adding the following line to postgres.sgml saved me.
> +https://postgr.es/c/";>
>
Comma at end of line of these should be removed
[165d581f1] ,
[6dbb49026] ,
Maybe those items which have lots of commits would be strange
A space before
Em qui., 8 de ago. de 2024 às 21:57, jian he
escreveu:
>
> please check attached.
>
I still think this way would be better
+ Sawada, John Naylor). [
+ ee1b30f12,
+ 30e144287,
+ 667e65aac,
+ 6dbb49026]
instead of this
+ Sawada, John Naylor).
+[ee1b30f12]
Em seg., 12 de ago. de 2024 às 06:21, jian he
escreveu:
>
> as your wish.
>
Looks good.
regards
Marcos
Em qua., 9 de out. de 2024 às 18:23, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
>
> Replaceable means the user is expected to substitute an expression in that
> location. One cannot specify a function name using an expression.
>
Sorry, I thought function parameters but said names.
Exponentiation, Square root and Cube root operators are not formatted with
tag like others.
https://www.postgresql.org/docs/current/functions-math.html
regards
Marcos
patch.diff
Description: Binary data
Em qua., 9 de out. de 2024 às 16:16, Marcos Pegoraro
escreveu:
> Exponentiation, Square root and Cube root operators are not formatted with
> tag like others.
>
Paying more attention, there is no standard on any of those Comparison,
String, Math, Date/Time and so on functions and
Em ter., 29 de out. de 2024 às 09:01, Aleksander Alekseev <
aleksan...@timescale.com> escreveu:
> The proposed patch renames trim_array() to array_trim().
>
That Array Functions list on func.sgml is an ordered list, so the right
place for it should be before array_upper, right ?
regards
Marcos
Em seg., 28 de out. de 2024 às 14:06, Aleksander Alekseev <
aleksan...@timescale.com> escreveu:
> =# select '[1,2,3]' :: jsonb :: int[];
>
I think would be useful, cast int[] to json is not hard
select to_json('{1,5,9,12}'::int[]);
but json array to int[] is not that easy.
select js,
js
Em sex., 20 de set. de 2024 às 18:34, Jonah H. Harris <
jonah.har...@gmail.com> escreveu:
> Seems to me this has already been answered well multiple times by multiple
> people; I’m not sure why this is such an issue, or one that warrants
> continued discussion.
>
No, I do not want to continue a d
Em sáb., 21 de set. de 2024 às 18:42, Bruce Momjian
escreveu:
> I suggest you explain what changes would make the docs better (meaing
> more useful).
>
Well, I think I already did this in this discussion.
Tom said that some functions were copied from Oracle, so it is ok to
mention them. I don't
Em dom., 22 de set. de 2024 às 12:49, Roberto Mello
escreveu:
> If you're volunteering to add a MySQL, SQL Server, Mongo, etc porting to
> the docs, I'm sure it could be a
> nice addition.
>
And if we create a page like https://www.postgresql.org/about/featurematrix/
But instead of Postgres vers
Why PostgreSQL DOCs needs to show or compare the Oracle way of doing things
?
I understand that on page Porting from Oracle PL/SQL is ok to mention
Oracle, but there are other places where it's not needed. Or, if it's ok to
mention, why not mention SQL Server or MySQL or any other ?
Bug Reporting
Em sex., 20 de set. de 2024 às 15:11, Tomas Vondra
escreveu:
> IMHO it's quite reasonable to say "we do X, but this other product
> (which is what we try to mimic) does Y".
>
Ok, for Data Type Formatting Functions is fine, if they were really copied
from, but the others ...
Bug Reporting Guideli
Em sex., 20 de set. de 2024 às 12:53, Tom Lane escreveu:
> As far as the mentions in "Data Type Formatting Functions" go, those
> are there because those functions are not in the SQL standard; we
> stole the API definitions for them from Oracle, lock stock and barrel.
> (Except for the discrepanc
Em sex., 20 de set. de 2024 às 11:56, Tomas Vondra
escreveu:
> It's not quite clear to me whether your suggestion is to not mention any
> other databases ever, or to always mention every existing one. ;-)
>
My suggestion is: Postgres DOCs are written and have to be read by Postgres
users, just t
Em sex., 20 de set. de 2024 às 13:18, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> It would be a boon to the community if someone were to put together a
> web/wiki page or mini-app that details this kind of information and, if
> considered accurate and relevant enough by the communi
Em qua., 18 de set. de 2024 às 06:02, Peter Eisentraut
escreveu:
> Maybe this shouldn't be done between RC1 and GA. This is clearly a more
> complex topic that should go through a proper review and testing cycle.
>
I think this is just a question of decision, not reviewing or testing.
And I'm s
Em qui., 17 de out. de 2024 às 13:31, Bruce Momjian
escreveu:
> Oh, okay, but I think we need to say JSON null so we are clear --- patch
>
But true, false and null are all JSON, since you cannot do
select jsonb_path_query('{}'::jsonb,'$.track.segments[*].HR > 130') = true;
So, it would be bette
There are lots of strange things related to this (... rows)
First, (0 rows) are completely useless. If no one record is shown, why do
we need that list ?
We could change (0 rows), like this one on dblink.sgml
SELECT * FROM dblink_get_notify();
notify_name | be_pid | extra
-++-
Em ter., 19 de nov. de 2024 às 13:27, Peter Eisentraut
escreveu:
> 3. Some documentation updates to explain some of the differences between
> NO ACTION and RESTRICT better.
>
There is a typo on your commit "doc: Improve description of referential
actions"
There is also a noticeable difference b
Em sex., 29 de nov. de 2024 às 15:49, Masahiko Sawada
escreveu:
> uuidv7 () uuid
>
Wouldn't it be better to change this to
uuidv7 ([interval]) uuid
But it would be good to have this patch applied to all supported versions,
as soon as nothing was changed on that pg_dump option, no ?
regards
Marcos
Em seg., 18 de nov. de 2024 às 18:30, Bruce Momjian
escreveu:
> On Tue, Nov 5, 2024 at 10:12:20AM +0100, Álvaro Herrera wrote:
> > On 2024-Nov-0
Em qua., 20 de nov. de 2024 às 10:52, Pavel Stehule
escreveu:
> COMMIT can be a little bit messy. TRANSACTION END is more intuitive, I
> think.
>
>>
Exactly to be not messy I would just ON COMMIT for all, and DOCs can
explain that this option is ignored for temp objects and do the same at the
end
Em ter., 19 de nov. de 2024 às 16:15, Pavel Stehule
escreveu:
> I wrote POC of VARIABLE(varname) syntax support
>
Not related with POC of VARIABLE but seeing your patches ...
Wouldn't it be better to use just one syntax and message for what to do ON
COMMIT ?
When creating a new variable you us
If I try to set client_min_messages with a wrong value it raises an error
and its hint is
"Available values: debug5, debug4, debug3, debug2, debug1, log, notice,
warning, error."
Why is not INFO option on this hint ?
regards
Marcos
Em dom., 24 de nov. de 2024 às 13:57, Tom Lane escreveu:
> Yeah. You can set it to INFO if you like, but the behavior is not
> different from setting it to NOTICE.
No, I don't think they have the same behavior.
If you set client_min_messages to Error then notice will not be sent, info
will wil
Em dom., 24 de nov. de 2024 às 18:54, David Rowley
escreveu:
> > SELECT format('|%10s|', 'foo');
This example you said returns one value, so I think it is ok.
I'm talking about lists with multiple fields or multiple lines. In [1] we
have both modes.
I don't think that "(2 rows)" is useful
sele
Em seg., 9 de dez. de 2024 às 13:31, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> I'm OK with adding more cross-references (links or just brief comparative
> verbiage like the above) to non-SQL null value treatment but this document,
> for this patch, is going to focus solely on SQL
The word below is commonly used on DOCs, but I didn't find it as a link.
Wouldn't it be better to write what you are linking to, instead of the word
below ?
(See Null-Valued Operands for
more explanation.)
instead of
(See below for more explanation.)
Multi-Element
Comparisons.
instead of
noted be
1 - 100 of 134 matches
Mail list logo
