Re: question about access custom enum type from C
Hi David
as you suggested
create type first_type as enum ('red', 'green', 'brown', 'yellow', 'blue');
SELECT oid,typname,typlen,typtype from pg_type where typname='first_type'
returns everything I was looking for
thanks again, I think I’m all set
dm
> On Sep 1, 2022, at 12:49 AM, David Rowley wrote:
>
> (I think this is a better question for the general mailing list)
>
> On Thu, 1 Sept 2022 at 16:28, Dmitry Markman wrote:
>>
>> Hi, when I’m trying to access values of my custom enum type I created with
>>
>> create type colors as enum ('red', 'green', 'brown', 'yellow', 'blue');
>>
>> I’m getting oid as 16387 and I can see it stored as a chars
>
> You might see the names if you query the table, but all that's stored
> in the table is the numerical value.
>
> https://www.postgresql.org/docs/current/datatype-enum.html states "An
> enum value occupies four bytes on disk.".
>
>> is number 16387 is always OID for enum type?
>
> I'm not sure where you got that number from. Perhaps it's the oid for
> the pg_type record? The following would show it.
>
> select oid,typname from pg_type where typname = 'colors';
>
>> if not how I can get information about type of the result if it’s custom
>> enum type
>
> I'm not sure what you mean by "the result". Maybe pg_typeof(column)
> might be what you want? You can do: SELECT pg_typeof(myenumcol) FROM
> mytable;
>
> David
Re: question about access custom enum type from C
Hi David, thanks a lot for your answer
I got that number from
PQparamtype
I already see that 16387 is not a ‘constant’, if I have few custom types I got
different numbers for them
thanks
dm
> On Sep 1, 2022, at 12:49 AM, David Rowley wrote:
>
> (I think this is a better question for the general mailing list)
>
> On Thu, 1 Sept 2022 at 16:28, Dmitry Markman wrote:
>>
>> Hi, when I’m trying to access values of my custom enum type I created with
>>
>> create type colors as enum ('red', 'green', 'brown', 'yellow', 'blue');
>>
>> I’m getting oid as 16387 and I can see it stored as a chars
>
> You might see the names if you query the table, but all that's stored
> in the table is the numerical value.
>
> https://www.postgresql.org/docs/current/datatype-enum.html states "An
> enum value occupies four bytes on disk.".
>
>> is number 16387 is always OID for enum type?
>
> I'm not sure where you got that number from. Perhaps it's the oid for
> the pg_type record? The following would show it.
>
> select oid,typname from pg_type where typname = 'colors';
>
>> if not how I can get information about type of the result if it’s custom
>> enum type
>
> I'm not sure what you mean by "the result". Maybe pg_typeof(column)
> might be what you want? You can do: SELECT pg_typeof(myenumcol) FROM
> mytable;
>
> David
question about access custom enum type from C
Hi, when I’m trying to access values of my custom enum type I created with
create type colors as enum ('red', 'green', 'brown', 'yellow', 'blue');
I’m getting oid as 16387 and I can see it stored as a chars
is number 16387 is always OID for enum type?
if not how I can get information about type of the result if it’s custom enum
type
thanks in advance
dm
Re: how to find log
Thanks Tom, Andrew
I’ll try out logging_collector facility
thanks again
dm
> On Dec 20, 2020, at 12:04 PM, Andrew Dunstan wrote:
>
>
> On 12/20/20 11:31 AM, Tom Lane wrote:
>> Dmitry Markman writes:
>>> suppose I started the server with the following command
>>> pg_ctl -D . . . start -l
>>> is there a way to get later by sending some query to the
>>> server or
>> No, the server has no way to know where its stdout/stderr were
>> pointed to. You might want to enable the syslogger output method
>> (see logging_collector) to have something a bit more featureful.
>>
>> https://www.postgresql.org/docs/current/runtime-config-logging.html
>>
>>
>
>
>
> Alternatively, asking the OS in many cases will work, e.g. on my linux
> machine:
>
>
> ls -l /proc/{postmasterpid}/fd/1
>
>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
how to find log
Hi all suppose I started the server with the following command pg_ctl -D . . . start -l is there a way to get later by sending some query to the server or reading some configuration file (for example I can get data directory with the query “show data_directory”) thanks in advance Dimitry Markman
Re: windows config.pl question
cl -help works the same on z: or on c: and it’s equivalent to the output of cl /? from c: Z:\>cat cl_out.txt | grep favor /O1 maximum optimizations (favor space) /O2 maximum optimizations (favor speed) /Os favor code space/Ot favor code speed /Ox optimizations (favor speed) /favor: select processor to optimize for, one of: where cl_out.txt is result cl -help > cl_out.txt > On Jul 31, 2020, at 10:58 PM, Michael Paquier wrote: > > On Fri, Jul 31, 2020 at 10:41:46PM -0400, Dmitry Markman wrote: >> but if I issue that command if the current folder is on z: >> >> Z:\>cl /? >> Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27042 for x64 >> Copyright (C) Microsoft Corporation. All rights reserved. >> >> usage: cl [ option... ] filename... [ /link linkoption... ] >> >> from other hand > > Interesting. We rely on the presence of "favor:" in the output to > determine which platform to use, aka x64 or Win32. > >> cl -help >> >> returns consistent answer from c: or from z: >> >> so platform wasn’t identified properly if build started from z: > > What's the output of cl -help on "z:" in this case? Is the exact same > output as "cl /?" or "cl -help" on c: generated? I have to admit that > I don't really know why things would behave this way, but Windows is a > platform full of undiscovered mysteries, and I have never seen the > output of cl being an issue even for some of my company work, which > uses stuff much more fancy than the normal way of compiling on > Windows, requiring me to patch a bit the scripts of src/tools/msvc/ in > a different way. > -- > Michael
Re: windows config.pl question
Hi Michael, I found the problem
command
cl /?
gives different answer if you start that command from c: or from z: (where z:
is mapped drive)
if current directory is on c:
then cl /? returns
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional>cl /?
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27042 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
C/C++ COMPILER OPTIONS
-OPTIMIZATION-
/O1 maximum optimizations (favor space) /O2 maximum optimizations (favor speed)
/Ob inline expansion (default n=0) /Od disable optimizations (default)
/Og enable global optimization /Oi[-] enable intrinsic functions
/Os favor code space/Ot favor code speed
/Ox optimizations (favor speed)
/favor: select processor to optimize for, one of:
blend - a combination of optimizations for several different x64 processors
AMD64 - 64-bit AMD processors
INTEL64 - Intel(R)64 architecture processors
ATOM - Intel(R) Atom(TM) processors
-CODE GENERATION-
/Gu[-] ensure distinct functions have distinct addresses
/Gw[-] separate global variables for linker
/GF enable read-only string pooling /Gm[-] enable minimal rebuild
/Gy[-] separate functions for linker/GS[-] enable security checks
/GR[-] enable C++ RTTI /GX[-] enable C++ EH (same as /EHsc)
. . . . . . . . . . . . . . .
but if I issue that command if the current folder is on z:
Z:\>cl /?
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27042 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
from other hand
cl -help
returns consisten answer from c: or from z:
so platform wasn’t identified properly if build started from z:
after I changed cl /? to cl -help
build and install went successfully
all but one test (tablespace) finished successfully.
that one failure also related to network drive, because
after build finished I copied whole directory that contain PostgreSQL distro to
c: and run tests everything went smoothly
thanks
dm
> On Jul 31, 2020, at 5:43 AM, Michael Paquier wrote:
>
> On Thu, Jul 30, 2020 at 11:16:01PM -0400, Dmitry Markman wrote:
>> sorry I meant file src/tools/msvc/Solution.pm
>>
>> routine sub GetOpenSSLVersion
>>
>> has the follwing line:
>>
>> qq("$self->{options}->{openssl}\\bin\\openssl.exe" version 2>&1);
>>
>> in our distribution openssl.exe isn’t in the
>> $self->{options}->{openssl}\bin\ location
>
> No idea what you are using as OpenSSL installation , so I cannot say
> for sure. FWIW, the scripts in the code tree are made compatible with
> what we suggest in the documentation here:
> https://www.postgresql.org/docs/current/install-windows-full.html#id-1.6.4.8.8
> --
> Michael
Re: windows config.pl question
sorry I meant file src/tools/msvc/Solution.pm
routine sub GetOpenSSLVersion
has the follwing line:
qq("$self->{options}->{openssl}\\bin\\openssl.exe" version 2>&1);
in our distribution openssl.exe isn’t in the $self->{options}->{openssl}\bin\
location
dm
> On Jul 30, 2020, at 10:25 PM, Dmitry Markman wrote:
>
> Hi Michael, thanks a lot
>
> I figured it out, UNC works indeed
>
> however I found at least 2 problems (at least in our 3p harness)
>
> 1. in our configuration openssl executable went to lib (I don’t know why), so
> I had to change line in Configure script
> and point to openssl.exe file. Sure I probably can change our makefile to
> create bin directory and put openssl.exe there
> but it’s not my file, maybe later
>
> 2. if PostgreSQL is situated on network drive that mapped to say disk z:,
> then build script failed:
>
> Z:\3p\derived\win64\PostgreSQL\source\src\tools\msvc>build
> Detected hardware platform: Win32
> Generating win32ver.rc for src/backend
> Generating win32ver.rc for src/timezone
> Generating win32ver.rc for src/backend/snowball
> Generating win32ver.rc for src/pl/plpgsql/src
> Generating win32ver.rc for src/backend/replication/libpqwalreceiver
> Generating win32ver.rc for src/backend/replication/pgoutput
> Generating win32ver.rc for src/interfaces/ecpg/pgtypeslib
>
> . . . . . . . . . . . .
>
> Building the projects in this solution one at a time. To enable parallel
> build, please add the "/m" switch.
> Build started 7/30/2020 5:52:12 PM.
> Project "Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln" on node 1 (default
> targets).
> Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln.metaproj : error MSB4126: The
> specified solution configuration "Release
> |x64" is invalid. Please specify a valid solution configuration using the
> Configuration and Platform properties (e.g. M
> SBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or
> leave those properties blank to use the defaul
> t solution configuration. [Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln]
> Done Building Project "Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln"
> (default targets) -- FAILED.
>
>
> Build FAILED.
>
> "Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln" (default target) (1) ->
> (ValidateSolutionConfiguration target) ->
> Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln.metaproj : error MSB4126:
> The specified solution configuration "Relea
> se|x64" is invalid. Please specify a valid solution configuration using the
> Configuration and Platform properties (e.g.
> MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or
> leave those properties blank to use the defa
> ult solution configuration. [Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln]
>
>0 Warning(s)
>1 Error(s)
>
>
> Time Elapsed 00:00:00.37
>
> Z:\3p\derived\win64\PostgreSQL\source\src\tools\msvc>
>
>
> the same works just fine if it’s on c: drive
>
> all PostgreSQL distribution is in the Z:\3p\derived\win64\PostgreSQL\source
> folder
>
>
>
> network UNC path is mapped to Z:
>
> thanks again for your help
>
> dm
>
>
>
>> On Jul 30, 2020, at 9:59 PM, Michael Paquier wrote:
>>
>> On Thu, Jul 30, 2020 at 06:55:28AM -0400, Dmitry Markman wrote:
>>> icu => ,
>>>
>>> is it correct?
>>
>> Exactly.
>>
>>> if it’s correct does build support UNC paths?
>>
>> Yes, these work. One take to be aware of is that the quoting of the
>> paths can be annoying. FWIW, I just use single quotes with normal
>> slashes as that's a no-brainer, say:
>> openssl => 'C:/OpenSSL-hoge/',
>>
>> If you are able to break the scripts with a given path, this would
>> likely be a bug we should address. For example, we had lately
>> complains about the build scripts breaking once you inserted spaces in
>> the python or OpenSSL paths (see beb2516 and ad7595b).
>> --
>> Michael
>
Re: windows config.pl question
Hi Michael, thanks a lot I figured it out, UNC works indeed however I found at least 2 problems (at least in our 3p harness) 1. in our configuration openssl executable went to lib (I don’t know why), so I had to change line in Configure script and point to openssl.exe file. Sure I probably can change our makefile to create bin directory and put openssl.exe there but it’s not my file, maybe later 2. if PostgreSQL is situated on network drive that mapped to say disk z:, then build script failed: Z:\3p\derived\win64\PostgreSQL\source\src\tools\msvc>build Detected hardware platform: Win32 Generating win32ver.rc for src/backend Generating win32ver.rc for src/timezone Generating win32ver.rc for src/backend/snowball Generating win32ver.rc for src/pl/plpgsql/src Generating win32ver.rc for src/backend/replication/libpqwalreceiver Generating win32ver.rc for src/backend/replication/pgoutput Generating win32ver.rc for src/interfaces/ecpg/pgtypeslib . . . . . . . . . . . . Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch. Build started 7/30/2020 5:52:12 PM. Project "Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln" on node 1 (default targets). Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln.metaproj : error MSB4126: The specified solution configuration "Release |x64" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. M SBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the defaul t solution configuration. [Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln] Done Building Project "Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln" (default targets) -- FAILED. Build FAILED. "Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln" (default target) (1) -> (ValidateSolutionConfiguration target) -> Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln.metaproj : error MSB4126: The specified solution configuration "Relea se|x64" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the defa ult solution configuration. [Z:\3p\derived\win64\PostgreSQL\source\pgsql.sln] 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.37 Z:\3p\derived\win64\PostgreSQL\source\src\tools\msvc> the same works just fine if it’s on c: drive all PostgreSQL distribution is in the Z:\3p\derived\win64\PostgreSQL\source folder network UNC path is mapped to Z: thanks again for your help dm > On Jul 30, 2020, at 9:59 PM, Michael Paquier wrote: > > On Thu, Jul 30, 2020 at 06:55:28AM -0400, Dmitry Markman wrote: >> icu => , >> >> is it correct? > > Exactly. > >> if it’s correct does build support UNC paths? > > Yes, these work. One take to be aware of is that the quoting of the > paths can be annoying. FWIW, I just use single quotes with normal > slashes as that's a no-brainer, say: > openssl => 'C:/OpenSSL-hoge/', > > If you are able to break the scripts with a given path, this would > likely be a bug we should address. For example, we had lately > complains about the build scripts breaking once you inserted spaces in > the python or OpenSSL paths (see beb2516 and ad7595b). > -- > Michael
windows config.pl question
Hi I’d like to add icu/openssl support to my postgresql build on windows documentation says that I have to modify config.pl file, however it's not clear what exactly I have to do config-default.pl for example has the following line icu => undef,# --with-icu= so, if I want to add icu support what exactly should I do? should I replace undef with path? icu => , is it correct? if it’s correct does build support UNC paths? thanks in advance Dimitry Markman Dmitry Markman
