Michael: Hello and welcome to Postgres FM, a show about all things

PostgreSQL.

I am Michael, founder of pgMustard and I'm joined as usual by

Nik, founder of PostgresAI.

Hey Nik!

Nikolay: Hi Michael, how are you?

Michael: I am doing okay, thank you.

How are you?

Nikolay: Recovering from some bad flu but all good.

Michael: Yeah, good to have you back.

And yeah, so what are we talking about today?

Nikolay: Let's talk about metadata and various meanings and including

like comments, maybe more, right?

Comments to database objects, comments inside queries, inside

PL/pgSQL, stored procedures and functions, just broadly.

What kind of metadata it makes sense to store and how?

Pros and cons, I don't know.

Michael: Yeah, I think so.

And also some side effects of having it in there or use cases.

I was actually quite surprised we hadn't talked about it already.

I saw a recent blog post by Markus Winand on Modern SQL about,

I think it was mostly actually about, it was called SQL comments,

but it was mostly about query.

I think so.

Nikolay: It doesn't have a date and by default I assume all the

posts are like very old somehow I think so, but yeah maybe it's

new stuff.

But it's very small post right?

Michael: Yeah but small but also it's 1 of those on Modern SQL

he has these like nice visualizations of which databases have

supported, which syntax from which dates, and I always enjoy

those when more

Nikolay: when also in Postgres, but practically, I'm, I rarely

leave the ecosystem of Postgres.

So it's just okay, good to know Postgres is good here as well

and here and here and that's it.

Michael: Occasionally you come across them where Postgres doesn't

support some syntax that another database does.

It's not common but I have been caught out a few times thinking

oh wow that's or not caught out but surprised thinking oh it's

interesting there are somewhere Oracle or SQL Server have some

new syntax that's even in the standard that we don't yet have.

So it isn't often, and it is really nice to see the especially

the dark green ticks it's like fully compliant tick not no no

little subtext on the and how it deviates from the standard or

anything else yeah but that was about query level comments so

so single line and multi-line comments

Nikolay: yeah in the main like SQL runtime like usually there

is a standard minus comment style.

And it's interesting to see that MySQL and MariaDB, they have

issues there if you, there's a
requirement to have whitespace

after 2 hyphens.

Yeah.

Okay.

But yeah, Postgres supports that
because it's standard and also

it supports C-style comments.

Exactly.

/* ... */

Michael: Yeah.

Which crucially can be, yeah, they're
good for multi-line comments,

aren't they?

So you can have the first slash
star, and then start writing.

Yeah, and also,

Nikolay: I try to use them all
the time because they are predictable.

If you use SQL standard comments,
you might have issues when,

for example, in some cases your
query, line endings are stripped

from your query.

In this case it's quite a messed
up situation because everything

becomes a comment.

Michael: Yeah that's a really good
point and I wasn't going to

bring this up till later because
it felt like a really minor

detail, but I was relatively surprised
to read that psql strips

out the single line, the standard
comments before even sending

them to the server, whereas it
doesn't for multi-line.

So yeah, exactly client side.

So when they're used, for example,
if you want that information

server-side for some reason, it
needs to be 1 of the C style

comments.

Nikolay: Yeah.

And we do have situations where
we appreciate comments, for example,

coming to pg_stat_statements.

Let's start with pg_stat_activity,
first of all.

Comments for queries can be super
useful to pass some, I don't

know, like trace ID, like origin,
even URL sometimes.

Like you can indicate which part
of your application generated

this query or participated in generation, right?

There are some libraries for different
languages.

I remember 1 for Ruby on Rails.

It's called marginalia.

I don't know.

Michael: It would be margin, because
it's from the, from, I think

the, yeah, from the margins, like
when you, in a book, if you

write some little notes about it.

Yeah.

Nikolay: Yeah.

So it's very useful.

It can bring automatically generated
comments to your queries

which are coming from Ruby on Rails
ORM and it's helpful to trace,

to analyze and quickly find where
this query is coming from and

also how like we obviously can
see them in pg_stat_activity.

The downside obviously that it
increases the size of the query

and by default pg_stat_activity the
query column it has only 1024

characters.

track_activity_query_size setting.

We usually recommend to bump it
like 10x.

Yeah.

Because we have memory for it,
let's do it.

Because queries tend to be bigger
and bigger over years, right?

So 1000 is not enough.

And of course, this comment is
put in front of the query and

you might not be able to see, unfortunately,
how SQL is written.

It starts with SELECT.

And sometimes ORMs, they put a
lot of columns there.

And with comment plus column list,
you might see that it's truncated

and you don't see the FROM clause
at all.

To see the FROM clause is super
essential.

There are opinions that SQL, like
SELECT, is the wrong way around.

Reorganized starting FROM, because
this is where things start

to be executed.

But It is what it is.

And yeah, so it's if you have a
huge helpful comment, it might

bite you here because you might
have your query trimmed faster

and you don't see it.

But it is what it is, right?

So my recommendation is comments
are super helpful here, like

from this library or you can write
your own or something, just

to trace the origin of the query
and so on.

And you just need to bump your
track_activity_query_size to have

bigger.

Unfortunately, it requires a restart.

That's the downside of that change.

Michael: I actually don't know
for sure, but I was looking at

the marginalia documentation briefly
just before this and noticed

that the comments were going at
the end of the query.

So it might be that they've deliberately
done that.

Nikolay: In this case you don't
see it in pg_stat_activity

maybe, right?

Michael: Yeah, good point.

Maybe it's even worse, yeah.

Nikolay: And what would be great
actually to, I don't know, this

is strange, but I recently implemented
in our monitoring, I was

hearing it's difficult, but then
I just took Claude Code and implemented

it, and it was quite successful.

So I implemented the approach I
saw in other systems.

So We have a mode in our dashboards
in Grafana, we basically

switch.

You can see the whole query or
you can see the query with stripped

less important parts.

I consider the column list as less
important part and I just

replace it with not dot dot dot
but a single symbol.

There is a unique triple dot.

And in this case you have more useful information and comments

I think are also stripped in this case.

Right?

Makes sense.

But yeah, depending on the situation, comments can be helpful

for various observability activities to connect some dots.

And it's interesting how comments in queries, for example, coming

in front of...

Oh, by the way, a big downside of having a comment in front of

a query is also that in our old checkup we had analysis so-called

mid-level.

We had high level, it's just the whole workload, all metrics

for the whole workload.

According to like from pg_stat_statements, of course it's not the

whole, usually it's only 5000 by default queries, normalized

queries.

But the lowest level it's individual normalized query, right?

Mid-level is when we call it so-called first word analysis.

So we just, which word is the first?

Okay, SELECT.

Or is it UPDATE?

There is a trick with, because with can combine multiple things

in 1 query.

But usually it's quite helpful to understand how many of queries

in terms of calls or overall timing, some metric, how many of

them are SELECTs versus UPDATEs and DELETEs.

You can get stats for writes from tuple statistics, but to analyze

at query level, it's not like straightforward.

So this is what we did.

And then I remember having comments destroy this analysis.

Of course, this is a method, like, it's easy to fix, right?

You can just ignore comments.

But this is interesting.

So bringing some observability helpers, you might destroy some

observability tools sometimes.

Michael: Yeah.

The other thing I wanted to make sure we mentioned in this area

was how pg_stat_statements works

Nikolay: because it

Michael: does denormalize.

So yeah, so comments, I think it's a quite good trade-off actually.

I think I quite like the decision they've made so they denormalize

So you if you have the same?

Query, but with 2 different comments, they will count as the

same query.

You'll get the same query ID They'll be grouped together, But

only the first 1 that gets stored under that query ID

Nikolay: What?

Unchanged

Michael: it's so it's not unchanged
with the comment exactly

Nikolay: For example, imagine we
have a simple select with blah

blah blah where I don't know like
email equals some value or

lower of email equals some value.

And you decide to put this email
as a comment.

This is how your PII leaks to pg_stat_statements,
but only the

first occurrence.

That's weird.

So.

Yeah.

Michael: I don't know if I've seen
P, have you seen PII in comments?

Nikolay: That's interesting.

Imaginary situation, it's possible,
right?

Michael: Sure.

Nikolay: Yeah, it's definitely
possible.

For example, we might, we can say,
okay, this is user with email,

this is acting here.

And we have, it's leaked to pg_stat_statements, everything else

is stripped, so like it's normalized,
we don't see parameters,

but comments we see only first
occurrence.

This is weird.

Michael: Yeah.

It's weird but I quite like, imagine,
I was thinking what's the

alternative?

Either they don't show comments
at all, or they have to store

loads of copies.

Nikolay: Yeah, there are pros and
cons here.

What I would like to see, it's
an unresolved problem still.

I would like to have ability to
pass comments as maybe key value

pairs, comma separated or white
space separated.

For example, you say, okay, application
ID this or application

component, component ID this, like
correlation ID, many things,

URL.

And then to be able to have aggregated
metrics based on those

dimensions.

So for example, I know my application
consists of various components,

I pass this component ID to comments,
and then I want to see

how many calls overall for this
query particularly, how many

calls are coming from that component
ID versus different component

ID.

And this type of analysis would
be super powerful, basically

custom dimensions for pg_stat_statements.

I know it was discussed for pg_stat_kcache And the consensus was

it should be in pg_stat_statements,
and I don't, it was many years

ago and I don't know how it ended.

But definitely there is like desire
to have some kind of analysis,

but I imagine it can be quite expensive
if implemented not in

a good way.

But yeah, this is what people want.

They come with questions like, okay, how to identify, we have

like many parts of, we have monolith, first of all, in terms

of code.

We have many teams working on different parts.

How to identify which part is most expensive in terms of CPU

usage for example.

Or time spent by Database to process this.

And here is where such kind of analysis would be super helpful.

Michael: Do you see people doing it, like you could for example

have them connect with different roles and that would then be

logged?

Nikolay: Yes, this is 1 way, this is indirect, like you could

just downgrade this, like I just pictured very good, flexible

approach that you could do many dimensions, but you can downgrade

and let your different parts of applications speak using different

users and use the fact that pg_stat_statements has user ID.

The downside of this approach would be you need to think how

to manage pools in PgBouncer, for example, because different

users means you need to set different quotas, pool sizes, right?

This can be quite inflexible.

If you want to have a single quota for all users, how?

Maybe it's a question to PgBouncer.

Maybe it's actually possible, maybe no.

It's another question, right?

So once I like to, this is, I think, good practice to separate

your workload to different segments and each segment works under

different DB users.

But there is also management overhead for maintaining various

limits and so on.

Michael: Yeah.

It's

Nikolay: all about, I forgot how.

So it's an interesting, maybe some of our listeners has a clear

picture.

What best practice would be here and please leave a comment somewhere.

Michael: Yeah.

Or even just what people are doing, what you're doing in practice,

it'd be good to hear what solutions people have come up with.

Nikolay: What's possible right now I think is if you, for example,

have quite high track activity query size, like 10k for example,

I see people even go further, even more, like 30k.

You use comments from marginalia or something, and you have

already started to appreciate performance insights or wait event

analysis.

We talked about it a lot, right?

In this case, you can start...

You can recognize different wait events and how many active sessions

and segment them by wait event type and wait event.

In this case, you can bring this knowledge about dimensions to

this analysis and start saying, okay, we have usually like this

amount of sessions spending on
I-O, and among them, like 90%

is coming from that part of our
application according to comments.

This is quite powerful.

And this you don't need to do anything
except like just to you

don't need to change pg_stat_statements
or how Postgres works.

It's possible right now already.

Michael: Yeah, as long as 2 parts
of your application aren't

doing the same query.

Yeah, that would be fun.

Nikolay: They can do the same query,
but they put different comments.

Michael: Yeah, but in pg_stat_statements.

Not in pg_stat_statements.

Nikolay: No, no, I'm talking about
wait event analysis.

Michael: Sorry.

Nikolay: And I'm talking actually
about, we call it lazy approach,

like sampling of pg_stat_activity.

Fine.

It cannot be super frequent because
there is overhead.

For example, every second or every
5 seconds you sample pg_stat_activity

activity and you have a raw query
from there, including comments

as is.

If you start using pg_wait_sampling,
which is great in terms of

sampling rate, 10 milliseconds,
every 10 milliseconds by default

it samples, but you lose this,
you lose the raw query and comments,

and you have the same problem as
pg_stat_statements.

These dimensions become not available
at pg_wait_sampling level.

So anyway, this is super interesting
observability topic, I think.

And what do you think about comments
which, I don't know, which

are put inside PL/pgSQL functions,
for example?

Michael: What for?

Is it to describe behavior like
almost like code comments?

Nikolay: Yeah it can be explanation
of this what this function

does and every piece like if you
for example look at Postgres

code it's very well commented.

Comments are very thorough right
they can be huge sometimes you

open some .c file and
a huge comment in the beginning

explaining what's happening here.

Yeah.

Is it a good idea to put this to
function bodies?

Michael: What's the downside?

I think I generally err on the
side of commenting things.

I like comments.

Although, you brought up AI already,
I do find some of the LLM

commenting excessive at times,
or like, maybe not excessive in

the sense that there's large comments,
it's more that there are

just comments, there are too many
comments, just comments at

too many stages.

I do like the Postgres style, but
they tend to be Huge comment

blocks describing a whole area
then loads of code not like comments

at each line of the code Describing
what each line is doing so

I like that style, but I tend to
find that people at least databases

I've seen over the years aren't
commented generally as well as

people's applications.

I see application code commented
better on average than database

code.

Maybe I'm looking at the wrong
projects, but personally, before

knowing the downsides, would think
it's a good idea.

Are there downsides I don't know
about though?

Nikolay: First of all, I agree
with you.

If comment just explains what next
line does, it's like, instead

of 4 ways, it's quite silly.

Like, stupid, how to say it better.

It's a low value comment, right?

But if it explains some knowledge
and decision making, how it

was made, some trade-offs which
were made, This is super valuable.

And right now I think comments
makes even more sense because

sometimes when we engineer something
and involve AI, we have

some roadmap and some intention
and maybe first version is not

final implementation of everything.

So having to-do comment, right?

To-do, fix me, right?

This is a meme comment, right?

But these days I think it's maybe...

I just feel the shift here because
it makes sense to comment

some future intentions more often
because next time we will revisit

this with AI as well.

We probably improve in the same
direction we wanted originally.

So preserving context now using
comments makes a lot of sense.

It's not always worth putting it
as a comment right inside function

body, because we might end up having
huge, like the plan inside

function body, and this doesn't
feel right, and it will consume

a lot of bytes stored.

So maybe some big comments should
go as a separate document adjacent

to the place, like in the same
place where we store function

in Git, for example.

Maybe it's better documented separately,
right?

But when you do something and you
say, okay, we do this, but

we plan to extend it to this and
this, I like these to-do comments

because they are in the same place
and next time AI or you reading

this like you you understand okay
this is what we planned here

and so to do fix me style makes
more sense now because well I

don't know explain it and we plan
to fix it later, why not?

Michael: But that was always true.

If you work in a team, if you work
in a style that's iterative,

like any kind of agile process,
any kind of extreme programming,

that kind of let's do the minimum
version and then let's iterate,

that's always been true hasn't
it?

Nikolay: But it's always also been
true that a lot of dead code

and a lot of such comments which
have very little chance to be

really improved.

So you say, to do, fix me, you
leave this comment, but you never

return because of the capacity.

Now it's much easier to return
and actually fix because we have

AI.

Michael: So

Nikolay: capacity changed, right?

And you think, okay, actually,
let's explain all the things like

in the comment right here and we
will, we know that we will revisit

it if this code survives and if
we don't drop it fully because

of some different like understanding
of like product or something.

We actually will improve.

I start believing into this, right?

Unlike pre-AI era when I knew nobody
will have capacity to work

on this because everyone is busy,
too much everything and so

on.

And this is great actually.

So comments are good.

If you don't leave comment, some
weird decision made, code is

hard to understand, like why it's
so, then we are in trouble.

And inline comment is great because
the AI won't miss it.

It's reading this part.

Comment is here, all clear.

But again, if it's some long document,
it's better to offload

it to some different part.

And We slowly move to the topic
we definitely wanted to discuss

is database object level comments.

Michael: Oh, before we do, can
I do 1 more for query level comments?

Nikolay: Yeah.

I just thought

Michael: it was, I'd forgotten
about this until recently, that

this is how pg_hint_plan puts hints
in.

And I think it's true for other
databases too, different not

just Postgres, how hints yeah it's
fascinating to me that's the

method we've chosen it makes sense
right If we don't have hints

at the database level, how else
could we get them in at the query

level other than Putting them in
a structured format inside a

comment and I didn't know I had
until reading the psql thing

I didn't know for sure why it was
in a multi-line comment other

than for readability But I found
it really interesting that it

uses that syntax probably because
it gets stripped less often.

So yeah, that seems to be another
like big use case for it for

query level comments.

Nikolay: PSQL doesn't strip C-like
comments?

Michael: Doesn't strip the C style.

Nikolay: That's interesting.

Michael: Yeah, so you can use pg_hint_plan
with psql without issues.

Nikolay: Yeah, so back to functions,
my approach is to have good

comments, explaining intentions,
context, plans maybe, but if

it's a huge document it should
be offloaded.

But we also have for each function
we can create a separate metadata

piece, we can say comment on function
name, comment on function

and function name.

Have you seen how many variations
comment on a statement has

in Postgres?

Michael: Yes, so I didn't realize,
and I think I might start

using this more, but for, I didn't
realize you could add comments

to indexes.

Yeah.

That's really cool in the sense
that sometimes you go to someone,

like sometimes someone shows you
they've got these 16 indexes

but they don't know like why certain
ones were added and wouldn't

it be cool if you could just check
the comments on as to what

you know.

Nikolay: On constraints, on sequences,
isn't it like fascinating?

Michael: I knew tables, I knew
columns, I knew like general objects

you could put comments on them
but I didn't know there were so

Nikolay: many options.

That's already hacking.

On access methods.

Too much, too deep.

Yeah so yeah, it's cool.

44 lines there.

And a funny thing, in 2005 or 6,
when we created first social

network, it was Postgres plus PHP.

And I, some time ago, not far ago,
not long ago, I stumbled upon

an email, first review of my code
from someone with experience

actually.

And big criticism was like lack
of comments at database object

level.

Can you imagine 20 plus years ago?

And I remember like actually how
I was like protective and defensive.

Michael: Oh wow.

Nikolay: Yeah.

Yeah.

But it's a good thing.

And my point right now is it always
has been a good thing to

have some approach in your project
and use comments because they

can, sometimes they become like
not valuable, right?

You can have a comment to a table
but also for each column yes

and I remember I tried to enforce
this in multiple teams I had

in different projects.

I tried to enforce this rule.

Let's do it.

Let's do it.

After that review, because I eventually
agreed it's a good thing

to have.

This is just a lot of metadata.

But I remember also seeing, okay,
column ID, this is our ID.

What comment can you put there
on this column?

I don't know.

Sometimes there is no like extra meaning, right?

Super simple column.

But right now I think it's valuable to think about, and this

is engineering level, this is what humans should think, maybe

brainstorming with AI, but what should we really document in

database object comments?

Right now it's so easy.

When we do something, there is no more excuse not to write tests

for CI, because this is what AI does quite well.

You just need to control it.

And not just coverage.

You should go deeper and say, okay, coverage is like a super

simple thing.

We have 80 plus percent, but what does it really mean?

We should cover edge cases, corner cases, really test things,

right?

And the same documentation.

And comments is our documentation.

This is a part of project documentation.

Database table should have some comments, functions should have

comments, columns as well.

But of course, if it's like nothing to say about some simple

column, okay, it can be skipped.

But there should be some rule, and AI should be helping to maintain

good comments so later when you try to add more features or do

refactoring, there is a great context and also when you work

with database, all like all those MCP Servers, APIs, like if

you work with database and it can describe itself, it's great

things to have, right?

Instead of guessing the meaning of column just on column name,

you have a comment.

That's great.

So now I think there's no excuse to avoid this powerful tool.

Yeah.

And have everything documented.

Michael: I think you raised some interesting things.

I do think that being strict about it on ID columns you make

a perfect point, there's no point.

But the place I've seen this super useful is reporting queries

so I think sometimes it can be quite complex to make sure you

are like summing the right columns or the column means what you

think it means.

Does this number, like what, this revenue number, what does it

include, what doesn't it include?

And that's like super relevant when you're trying to report stuff.

And maybe sometimes like just the data person knows that, but

if they can put it in comments on the schema then their future

if once they hire a team those people can know it and nowadays

even LLM is writing reporting queries they've got a better chance

of getting that right rather than pure mistake.

Exactly, exactly.

Nikolay: And the ideal schema, 2 columns, ID, column ID, and

it's of type UUID.

And we should have a comment, never put UUID version 4 here,

always UUID version 7.

And second column, data, JSONB.

It's a joke, just in case.

Michael: Yeah, yeah.

Sounds like Mongo.

Nikolay: And then the comment which you extend all the time,

extending schema of that JSONB, explaining what's inside.

Anyway, 1 of the interesting cases we discussed recently, it

was some project which was originally monolith but they split

the database into several pieces.

So when you do this, you need to abandon some foreign keys because

you cannot have foreign keys between 2 clusters, between 2 primaries,

right?

And I remember we discussed maybe we should maintain some fake

foreign keys, like imaginary foreign keys and define them in

the comments.

It was just an idea, right?

Because who will be enforcing the rule that nobody will ever

write those comments?

I don't know, but it's possible.

So you have a column in 1 cluster saying that it should, values

here should match values of that column in that cluster.

And periodically application or some additional tooling checks

this.

Anyway, tests and comments are super cheap to write these days.

There should be some like rule to enforce in every project to

make them rich.

Michael: Yeah, not only are they cheaper though, I think there's,

they've always been valuable.

I'm a big fan of tests, like I was, I love making changes to

things and knowing that we haven't introduced any regressions

like all the previous bugs that now have tests that mean that

we can't reintroduce them or reintroduce something similar.

So I'm a big fan of tests, I'm a big fan of comments but I think

their value might even be going up in this new world Like I think

it's not just that they just as valuable and cheaper to add,

but I think they might be even more valuable.

Like I would be super scared letting an AI make changes to an

application that doesn't have good test coverage these days.

Like just the value of tests for me is going up even higher because

I have less trust that people have properly reviewed things So

it's did you see where I'm coming from that actually these things

might be even more like comments quality.

I think so and Yeah checking obviously getting it to add these

things is 1 thing, but then checking that they, there is a reasonable

comment that it is documenting what you think that column is

or does.

Yeah, I can see that.

The 1 thing I was going to ask
you though is what do you think

about index comments?

Do you use them?

Honestly,

Nikolay: I don't remember I used
them ever.

But it makes sense to document
why we created this index, right?

Michael: I think so.

I even think maybe because we re-index,
right, sometimes for

maintenance, I was even thinking
like when we added it, who added

it, what for, there might be some
interesting metadata

Nikolay: in there.

That's interesting.

That's interesting.

And not only index, I think, yeah,
I remember cases when I thought,

oh damn, I wish we could establish
proper, like we could figure

out when something was really created
in Postgres.

Some table or index.

Michael: Function.

Nikolay: Yeah, if you, for example,
establish a rule that when

you create something or recreate,
rebuild index, you document

it in a comment, why not?

It's an interesting idea actually.

Probably I should borrow it for
our pg_index_pilot project, which

re-indexes automatically.

Michael: Yeah, so for a lot of
people using ORMs, they'll have

the source control of this, right?

Like they can look up when was
this first created and hopefully

that comes with a commit...

Nikolay: Or looking at logs.

Yeah Like not easy usually.

Michael: Looking at logs.

Nikolay: Logs, if you document
DDL.

Yeah, but how long do people store
those for?

If it's a serious project, usually
we have something like Elastic

and store it for quite long, not
forever.

I agree, it's a lot.

Yeah.

Michael: Indexes could easily have
been created years ago and

people wouldn't like it.

Nikolay: Yeah, and I remember,
well, actually this is also interesting.

I remember in pg_index_pilot,
we of course have a couple of

tables where we store such metadata
and all the history of rebuilding

and so on.

Nice.

Yeah, and this is interesting.

This is like to think pros and
cons of storing some metadata

in the comment versus you have
specific table and store it there.

Pros and cons are not obvious to
me, because of course, comment

is closer, right?

It's easier than to consume.

But you don't have history, for
example.

Only additional table, you need
to maintain it and so on.

Pros of storing some comments separately,
also permissions.

Sometimes you want to store some
data which you don't want regular

users to observe, for example.

It's very specific nuance for like
your goals, right?

But yeah.

Last thing we wanted to mention
is this blog post from Andrei

Lepikhov.

An interesting idea to use security
labels as metadata storage.

It's quite elegant, I think, and
we discussed before.

So the idea is that we need some
metadata storage, but instead

of creating a table and write it
there, in that case, it was,

I think, it was pgEdge, so it was
related to probably a multi-master

solution and logical replication,
bidirectional logical replication,

something.

So the idea was, let's use these
security labels coming from

integration with SE Linux security
stuff and benefit from the

fact that You can put anything
there and for different users,

unlike for example comment, which
is single comment for database

object, there you can have multiple
metadata pieces belonging

to specifically like to which user,
so it's one-to-many relationship,

so it's interesting.

And putting there some custom data,
why not actually?

Michael: Yeah, so it's called security
labels, but I guess you

could just think of them as labels?

Nikolay: Yeah, So it's interesting.

I never thought about this and
maybe there are different use

cases where you can benefit from
this.

If you need specific comments for
specific users for this particular

database object.

Michael: Yeah, many options.

Nikolay: Yeah, anyway, comments
should be used more in the AI

era.

Like table level, index level,
I like it a lot.

Never use but I'm going to think.

Michael: Yeah, and even if you're
somewhere that isn't using

AI stuff all the time, I don't
know how many of them there are

these days.

But just I think this is useful
anyway even for teams that are

collaborating like this comments
are good for communication generally.

Good.

Alright, nice one Nikolay.

Thanks so much for this and catch
you next time.

Nikolay: Have a great week, bye
bye.