Re: Building PostgreSQL extensions on Windows
Hi David, No pain with CMake. It's pretty easy to use it in Windows for PostgreSQL extensions. Example, https://github.com/dmitigr/pgnso On Fri, 12 Jun 2020, 01:43 David Rowley, wrote: > Hi, > > I've heard from a few people that building PostgreSQL extensions on > Windows is a bit of a pain. I've heard from these people that their > solution was to temporarily add their extension as a contrib module > and have the extension building code take care of creating and > building the Visual Studio project file. > > I also have to say, I do often use Visual Studio myself for PostgreSQL > development, but when it comes to testing something with an extension, > I've always avoided the problem and moved over to Linux. > > I thought about how we might improve this situation. The easiest way > I could think to do this was to just reuse the code that builds the > Visual Studio project files for contrib modules and write a Perl > script which calls those functions. Now, these functions, for those > who have never looked there before, they do use the PGXS compatible > Makefile as a source of truth and build the VS project file from that. > I've attached a very rough PoC patch which attempts to do this. > > The script just takes the directory of the Makefile as the first > argument, and optionally the path to pg_config.exe as the 2nd > argument. If that happens to be in the PATH environment variable then > that can be left out. > > You end up with: > > X:\pg_src\src\tools\msvc>perl extbuild.pl > X:\pg_src\contrib\auto_explain X:\pg\bin > Makefile dir = X:\pg_src\contrib\auto_explain > Postgres include dir = X:\pg\include > Building = Release > Detected hardware platform: x64 > > ... > > Build succeeded. > 0 Warning(s) > 0 Error(s) > > Time Elapsed 00:00:01.13 > > For now, I've only tested this on a few contrib modules. It does need > more work to properly build ones with a list of "MODULES" in the > Makefile. It seems to work ok on the MODULE_big ones that I tested. It > needs a bit more work to get the resource file paths working properly > for PROGRAM. > > Before I go and invest more time in this, I'd like to get community > feedback about the idea. Is this something that we'd want? Does it > seem maintainable enough to have in core? Is there a better way to do > it? > > David > >
Re: Is it memory leak or not?
On Mon, 10 Feb 2020, 18:59 Tom Lane, wrote: > Dmitry Igrishin writes: > > Maybe I'm wrong, but anychar_typmodin() of > > src/backend/utils/adt/varchar.c of PostgreSQL 12.1 does not pfree()s > > the memory allocated by ArrayGetIntegerTypmods(). Probably, I'm > > missing something. Could anybody please clarify on that? > > It is a leak, in the sense that the pointer is unreferenced once the > function returns. But we don't care, either here or in the probably > thousands of other similar cases, because we don't expect this function > to be run in a long-lived memory context. The general philosophy in > the backend is that it's cheaper and far less error-prone to rely on > memory context cleanup to reclaim (small amounts of) memory than to > rely on manual pfree calls. You can read more about that in > src/backend/utils/mmgr/README. > I see. Thank you very much!
Is it memory leak or not?
Hello, Maybe I'm wrong, but anychar_typmodin() of src/backend/utils/adt/varchar.c of PostgreSQL 12.1 does not pfree()s the memory allocated by ArrayGetIntegerTypmods(). Probably, I'm missing something. Could anybody please clarify on that? Thanks!
Re: Small patch to fix build on Windows
вт, 13 авг. 2019 г. в 06:19, Michael Paquier :
>
> On Fri, Aug 09, 2019 at 11:21:52AM +0300, Dmitry Igrishin wrote:
> > Personally I don't care. I used || notation only in order to be
> > consistent, since this notation is already used in Solution.pm. If
> > this consistency is not required let me provide a patch with {}
> > notation. What do you think?
>
> We are talking about one place in src/tools/msvc/ using qq on HEAD.
> So one or the other is fine by me as long as we remain in the
> acceptable ASCII ranks.
Okay. 5th version of patch is attached.
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index d1d0aed07e..67e9eede49 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -495,7 +495,7 @@ sub mkvcbuild
my $pythonprog = "import sys;print(sys.prefix);"
. "print(str(sys.version_info[0])+str(sys.version_info[1]))";
my $prefixcmd =
- $solution->{options}->{python} . "\\python -c \"$pythonprog\"";
+ qq{"$solution->{options}->{python}\\python" -c "$pythonprog"};
my $pyout = `$prefixcmd`;
die "Could not query for python version!\n" if $?;
my ($pyprefix, $pyver) = split(/\r?\n/, $pyout);
diff --git a/src/tools/msvc/Project.pm b/src/tools/msvc/Project.pm
index b5d1dc6e89..88e9e3187d 100644
--- a/src/tools/msvc/Project.pm
+++ b/src/tools/msvc/Project.pm
@@ -132,11 +132,6 @@ sub AddLibrary
{
my ($self, $lib, $dbgsuffix) = @_;
- if ($lib =~ m/\s/)
- {
- $lib = '' . $lib . "";
- }
-
push @{ $self->{libraries} }, $lib;
if ($dbgsuffix)
{
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 318594db5d..400c6706fb 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -126,7 +126,7 @@ sub GetOpenSSLVersion
# Attempt to get OpenSSL version and location. This assumes that
# openssl.exe is in the specified directory.
my $opensslcmd =
- $self->{options}->{openssl} . "\\bin\\openssl.exe version 2>&1";
+ qq{"$self->{options}->{openssl}\\bin\\openssl.exe" version 2>&1};
my $sslout = `$opensslcmd`;
$? >> 8 == 0
Re: Small patch to fix build on Windows
пт, 9 авг. 2019 г. в 10:23, Kyotaro Horiguchi :
>
> At Fri, 9 Aug 2019 09:56:27 +0300, Dmitry Igrishin wrote
> in
> > пт, 9 авг. 2019 г. в 05:45, Michael Paquier :
> > >
> > > On Thu, Aug 08, 2019 at 10:46:07PM +0300, Dmitry Igrishin wrote:
> > > > This looks nice for a Perl hacker :-). As for me, it looks unusual and
> > > > a bit confusing. I never
> > > > programmed in Perl, but I was able to quickly understand where the
> > > > problem lies due to the
> > > > style adopted in other languages, when the contents are enclosed in
> > > > quotation marks, and
> > > > the quotation marks are escaped if they are part of the contents.
> > > > So, should I fix it? Any thoughts?
> > >
> > > FWIW, I like Alvaro's suggestion about qq{} in this case, as it makes
> > > sure that double-quotes are correctly applied where they should.
> > The attached 4rd version of the patch uses qq||. I used qq|| instead
> > of qq{} for consistency because qq|| is already used in Solution.pm:
> >
> > return qq|VisualStudioVersion = $self->{VisualStudioVersion}
> > MinimumVisualStudioVersion = $self->{MinimumVisualStudioVersion}
> > |;
>
> Hmm. qq is nice but '|' make my eyes twitch (a bit). Couldn't we
> use other delimites like (), ##, or // ? (I like {} for use in
> this patch.)
>
> Any opinions?
Personally I don't care. I used || notation only in order to be
consistent, since this notation is already used in Solution.pm. If
this consistency is not required let me provide a patch with {}
notation. What do you think?
Re: Small patch to fix build on Windows
пт, 9 авг. 2019 г. в 05:45, Michael Paquier :
>
> On Thu, Aug 08, 2019 at 10:46:07PM +0300, Dmitry Igrishin wrote:
> > This looks nice for a Perl hacker :-). As for me, it looks unusual and
> > a bit confusing. I never
> > programmed in Perl, but I was able to quickly understand where the
> > problem lies due to the
> > style adopted in other languages, when the contents are enclosed in
> > quotation marks, and
> > the quotation marks are escaped if they are part of the contents.
> > So, should I fix it? Any thoughts?
>
> FWIW, I like Alvaro's suggestion about qq{} in this case, as it makes
> sure that double-quotes are correctly applied where they should.
The attached 4rd version of the patch uses qq||. I used qq|| instead
of qq{} for consistency because qq|| is already used in Solution.pm:
return qq|VisualStudioVersion = $self->{VisualStudioVersion}
MinimumVisualStudioVersion = $self->{MinimumVisualStudioVersion}
|;
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index d1d0aed07e..042879238e 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -495,7 +495,7 @@ sub mkvcbuild
my $pythonprog = "import sys;print(sys.prefix);"
. "print(str(sys.version_info[0])+str(sys.version_info[1]))";
my $prefixcmd =
- $solution->{options}->{python} . "\\python -c \"$pythonprog\"";
+ qq|"$solution->{options}->{python}\\python" -c "$pythonprog"|;
my $pyout = `$prefixcmd`;
die "Could not query for python version!\n" if $?;
my ($pyprefix, $pyver) = split(/\r?\n/, $pyout);
diff --git a/src/tools/msvc/Project.pm b/src/tools/msvc/Project.pm
index b5d1dc6e89..88e9e3187d 100644
--- a/src/tools/msvc/Project.pm
+++ b/src/tools/msvc/Project.pm
@@ -132,11 +132,6 @@ sub AddLibrary
{
my ($self, $lib, $dbgsuffix) = @_;
- if ($lib =~ m/\s/)
- {
- $lib = '' . $lib . "";
- }
-
push @{ $self->{libraries} }, $lib;
if ($dbgsuffix)
{
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 318594db5d..6406df6769 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -126,7 +126,7 @@ sub GetOpenSSLVersion
# Attempt to get OpenSSL version and location. This assumes that
# openssl.exe is in the specified directory.
my $opensslcmd =
- $self->{options}->{openssl} . "\\bin\\openssl.exe version 2>&1";
+ qq|"$self->{options}->{openssl}\\bin\\openssl.exe" version 2>&1|;
my $sslout = `$opensslcmd`;
$? >> 8 == 0
Re: Small patch to fix build on Windows
чт, 8 авг. 2019 г. в 20:07, Alvaro Herrera :
>
> On 2019-Aug-08, Dmitry Igrishin wrote:
>
> > my $prefixcmd =
> > - $solution->{options}->{python} . "\\python -c
> > \"$pythonprog\"";
> > + "\"$solution->{options}->{python}\\python\" -c
> > \"$pythonprog\"";
>
> I think you can make this prettier like this:
>
>my $prefixcmd = qq{"$solution->{options}->{python}\\python" -c
> "$pythonprog"};
This looks nice for a Perl hacker :-). As for me, it looks unusual and
a bit confusing. I never
programmed in Perl, but I was able to quickly understand where the
problem lies due to the
style adopted in other languages, when the contents are enclosed in
quotation marks, and
the quotation marks are escaped if they are part of the contents.
So, should I fix it? Any thoughts?
Re: Small patch to fix build on Windows
> > As for the replace comment, I'm not
> > sure it is needed since I think quoting is not the task for
> > AddLibrary/AddIncludeDir in the first place (and AddIncludeDir
> > doesn't have the same comment).
The attached 3rd version of the patch contains no comment in AddLibrary().
Sorry, forgot to attach the patch to the previous mail.
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index d1d0aed07e..76834f5188 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -495,7 +495,7 @@ sub mkvcbuild
my $pythonprog = "import sys;print(sys.prefix);"
. "print(str(sys.version_info[0])+str(sys.version_info[1]))";
my $prefixcmd =
- $solution->{options}->{python} . "\\python -c \"$pythonprog\"";
+ "\"$solution->{options}->{python}\\python\" -c \"$pythonprog\"";
my $pyout = `$prefixcmd`;
die "Could not query for python version!\n" if $?;
my ($pyprefix, $pyver) = split(/\r?\n/, $pyout);
diff --git a/src/tools/msvc/Project.pm b/src/tools/msvc/Project.pm
index b5d1dc6e89..88e9e3187d 100644
--- a/src/tools/msvc/Project.pm
+++ b/src/tools/msvc/Project.pm
@@ -132,11 +132,6 @@ sub AddLibrary
{
my ($self, $lib, $dbgsuffix) = @_;
- if ($lib =~ m/\s/)
- {
- $lib = '' . $lib . "";
- }
-
push @{ $self->{libraries} }, $lib;
if ($dbgsuffix)
{
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 318594db5d..327e556c53 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -126,7 +126,7 @@ sub GetOpenSSLVersion
# Attempt to get OpenSSL version and location. This assumes that
# openssl.exe is in the specified directory.
my $opensslcmd =
- $self->{options}->{openssl} . "\\bin\\openssl.exe version 2>&1";
+ "\"$self->{options}->{openssl}\\bin\\openssl.exe\" version 2>&1";
my $sslout = `$opensslcmd`;
$? >> 8 == 0
Re: Small patch to fix build on Windows
чт, 8 авг. 2019 г. в 06:18, Kyotaro Horiguchi :
>
> Hello.
>
> At Wed, 7 Aug 2019 12:14:48 +0300, Dmitry Igrishin wrote
> in
> > > -if ($lib =~ m/\s/)
> > > -{
> > > -$lib = '' . $lib . "";
> > > -}
> > > +# Since VC automatically quotes paths specified as the data of
> > > +# in VC project file, it's mistakably
> > > +# to quote them here. Thus, it's okay if $lib contains spaces.
> > >
> > > I'm not sure, but it's not likely that someone adds it without
> > > actually stumbling on space-containing paths with the ealier
> > > version. Anyway if we shouldn't touch this unless the existing
> > > code makes actual problem.
> > So, do you think a comment is not needed here?
>
> # Sorry the last phrase above is broken.
>
> I meant "if it ain't broke don't fix it".
>
> I doubt that some older versions of VC might need it. I confirmed
> that the extra actually harms at least VC2019 and the code
> removal in the patch works.
The code removal is required also to build on VC2017.
> As for the replace comment, I'm not
> sure it is needed since I think quoting is not the task for
> AddLibrary/AddIncludeDir in the first place (and AddIncludeDir
> doesn't have the same comment).
The attached 3rd version of the patch contains no comment in AddLibrary().
>
> Now I'm trying to install VS2015 into my alomost-filled-up disk..
Thank you!
Re: Small patch to fix build on Windows
ср, 7 авг. 2019 г. в 15:33, Juan José Santamaría Flecha
:
>
> On Wed, Aug 7, 2019 at 11:11 AM Dmitry Igrishin wrote:
> >
> > ср, 7 авг. 2019 г. в 11:29, Kyotaro Horiguchi :
> > >
> > > Solution.pm has the following line:
> > >
> > > > my $opensslcmd =
> > > > $self->{options}->{openssl} . "\\bin\\openssl.exe version 2>&1";
> > >
> > > AFAICS that's all.
> > Thank you! The attached 2nd version of the patch fixes this too.
> >
>
> At some point the propossed patch for opensslcmd was like:
>
> + my $opensslprog = '\bin\openssl.exe version 2>&1';
> + my $opensslcmd = '"' . $self->{options}->{openssl} . '"' . $opensslprog;
>
> It can be a question of taste, but I think the dot is easier to read.
Well, the style inconsistent anyway, for example, in file Project.pm
$self->{def} = "./__CFGNAME__/$self->{name}/$self->{name}.def";
$self->{implib} = "__CFGNAME__/$self->{name}/$libname";
So, I don't know what style is preferable. Personally, I don't care.
Re: Small patch to fix build on Windows
ср, 7 авг. 2019 г. в 11:29, Kyotaro Horiguchi :
>
> Hi,
>
> At Tue, 6 Aug 2019 22:50:14 +0300, Dmitry Igrishin wrote
> in
> > The attached self-documented patch fixes build on Windows in case when
> > path to Python has embedded spaces.
>
> - $solution->{options}->{python} . "\\python -c \"$pythonprog\"";
> + "\"$solution->{options}->{python}\\python\" -c \"$pythonprog\"";
>
> Solution.pm has the following line:
>
> > my $opensslcmd =
> > $self->{options}->{openssl} . "\\bin\\openssl.exe version 2>&1";
>
> AFAICS that's all.
Thank you! The attached 2nd version of the patch fixes this too.
>
>
> -if ($lib =~ m/\s/)
> -{
> -$lib = '' . $lib . "";
> -}
> +# Since VC automatically quotes paths specified as the data of
> +# in VC project file, it's mistakably
> +# to quote them here. Thus, it's okay if $lib contains spaces.
>
> I'm not sure, but it's not likely that someone adds it without
> actually stumbling on space-containing paths with the ealier
> version. Anyway if we shouldn't touch this unless the existing
> code makes actual problem.
So, do you think a comment is not needed here?
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index d1d0aed07e..76834f5188 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -495,7 +495,7 @@ sub mkvcbuild
my $pythonprog = "import sys;print(sys.prefix);"
. "print(str(sys.version_info[0])+str(sys.version_info[1]))";
my $prefixcmd =
- $solution->{options}->{python} . "\\python -c \"$pythonprog\"";
+ "\"$solution->{options}->{python}\\python\" -c \"$pythonprog\"";
my $pyout = `$prefixcmd`;
die "Could not query for python version!\n" if $?;
my ($pyprefix, $pyver) = split(/\r?\n/, $pyout);
diff --git a/src/tools/msvc/Project.pm b/src/tools/msvc/Project.pm
index b5d1dc6e89..28893f072d 100644
--- a/src/tools/msvc/Project.pm
+++ b/src/tools/msvc/Project.pm
@@ -132,10 +132,9 @@ sub AddLibrary
{
my ($self, $lib, $dbgsuffix) = @_;
- if ($lib =~ m/\s/)
- {
- $lib = '' . $lib . "";
- }
+ # Since VC automatically quotes paths specified as the data of
+ # in VC project file, it's mistakably
+ # to quote them here. Thus, it's okay if $lib contains spaces.
push @{ $self->{libraries} }, $lib;
if ($dbgsuffix)
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 318594db5d..327e556c53 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -126,7 +126,7 @@ sub GetOpenSSLVersion
# Attempt to get OpenSSL version and location. This assumes that
# openssl.exe is in the specified directory.
my $opensslcmd =
- $self->{options}->{openssl} . "\\bin\\openssl.exe version 2>&1";
+ "\"$self->{options}->{openssl}\\bin\\openssl.exe\" version 2>&1";
my $sslout = `$opensslcmd`;
$? >> 8 == 0
Small patch to fix build on Windows
Hi,
The attached self-documented patch fixes build on Windows in case when
path to Python has embedded spaces.
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index d1d0aed07e..76834f5188 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -495,7 +495,7 @@ sub mkvcbuild
my $pythonprog = "import sys;print(sys.prefix);"
. "print(str(sys.version_info[0])+str(sys.version_info[1]))";
my $prefixcmd =
- $solution->{options}->{python} . "\\python -c \"$pythonprog\"";
+ "\"$solution->{options}->{python}\\python\" -c \"$pythonprog\"";
my $pyout = `$prefixcmd`;
die "Could not query for python version!\n" if $?;
my ($pyprefix, $pyver) = split(/\r?\n/, $pyout);
diff --git a/src/tools/msvc/Project.pm b/src/tools/msvc/Project.pm
index b5d1dc6e89..28893f072d 100644
--- a/src/tools/msvc/Project.pm
+++ b/src/tools/msvc/Project.pm
@@ -132,10 +132,9 @@ sub AddLibrary
{
my ($self, $lib, $dbgsuffix) = @_;
- if ($lib =~ m/\s/)
- {
- $lib = '' . $lib . "";
- }
+ # Since VC automatically quotes paths specified as the data of
+ # in VC project file, it's mistakably
+ # to quote them here. Thus, it's okay if $lib contains spaces.
push @{ $self->{libraries} }, $lib;
if ($dbgsuffix)
Re: psql's meta command \d is broken as of 12 beta2.
пн, 5 авг. 2019 г. в 14:42, Pavel Stehule : > > Hi > > > po 5. 8. 2019 v 13:35 odesílatel Dmitry Igrishin napsal: >> >> Hi, >> >> Sorry if this report is duplicate but there is no column relhasoids in >> pg_catalog.pg_class required by the underlying query of the \d meta >> command of psql. > > > do you use psql from this release? > > The psql client should be higher or same like server. > > Pavel Oops, I'm wrong. When I looked at describe.c I understood my mistake. Sorry for noise and thank you!
psql's meta command \d is broken as of 12 beta2.
Hi, Sorry if this report is duplicate but there is no column relhasoids in pg_catalog.pg_class required by the underlying query of the \d meta command of psql.
Re: libpq environment variables in the server
пн, 21 янв. 2019 г. в 13:42, Peter Eisentraut : > > When libpq is loaded in the server (libpqwalreceiver, dblink, > postgres_fdw), it may use libpq environment variables set in the > postmaster environment for connection parameter defaults. I have > noticed that this has some confusing effects in our test suites. I > wonder if this is a good idea in general. > > For example, the TAP test infrastructure sets PGAPPNAME to allow > identifying clients in the server log. But this environment variable is > also inherited by temporary servers started with pg_ctl and is then in > turn used by libpqwalreceiver as the application_name for connecting to > remote servers where it then shows up in pg_stat_replication and is > relevant for things like synchronous_standby_names. > > Also, the pg_rewind tests appear to rely implicitly on PGHOST and PGPORT > being set in the server environment to find the other node via > primary_conninfo. That is easy to fix, but it shows that this kind of > thing can creep in unintentionally. > > I was thinking that maybe we should clear all libpq environment > variables in the server, or perhaps have a mode in libpq to ignore all > environment variables. Then again, maybe setting something like > PGSSLMODE globally in the server could be useful, so just removing > everything might not be the right answer. As an author of the C++ client API (Pgfe) that currently wraps libpq I would like to ignore all these environment variables that affects libpq's behavior, because libpq is an implementation detail and the Pgfe API hides it completely. So +1 from me for such a mode in libpq.
Re: proposal: plpgsql pragma statement
вт, 4 дек. 2018 г. в 20:13, Pavel Stehule :
>
> Hi
>
> I wrote plpgsql_check https://github.com/okbob/plpgsql_check.
>
> It is working well, but because it does static analyse only, sometimes it can
> produces false alarms or it should to stop a analyse, because there are not
> necessary data.
>
> https://github.com/okbob/plpgsql_check/issues/36
>
> I see one possible solution in introduction of pragma statement with syntax:
>
> PRAGMA keyword [content to semicolon];
>
> The pragma has a relation to following statement. So the issue 36 can be
> solved by pragma
>
> PRAGMA cmdtype CREATE;
> EXECUTE format('CREATE TABLE xxx ...
>
> The PRAGMA statement does nothing in runtime. It works only in compile time,
> and add a pair of key, value to next non pragma statement. This information
> can be used by some plpgsql extensions.
>
> What do you think about this proposal?
I think it's a good idea in common. But how about multiple PRAGMAs? Consider
PRAGMA cmdtype CREATE;
PRAGMA objtype TABLE;
EXECUTE format('CREATE TABLE');
Re: Usability fail with psql's \dp command
> > > What do people think of printing "Default" if the ACL is null? > > Alternatively, since the state with an empty ACL is certainly > the unusual case, maybe we should mark that specially, perhaps > by printing "None" or "No privileges". Old problem. +1.
