Re: New "function tables" in V13 documentation
On 11/8/20 1:57 PM, Thomas Kellerer wrote: In case someone is interested: there is a little discussion going on on Reddit whether the new format of presenting functions in V13 is a step backwards: https://www.reddit.com/r/PostgreSQL/comments/jpi0rp/does_anyone_else_feel_like_the_v13_docs_are_a/ Yeah, I would agree with the mobile first design comments. Then again that plague is hitting most sites these days. My 2 cents is it is a step backwards. You can cover more ground quickly and digest it faster in the old format. Thomas -- Adrian Klaver adrian.kla...@aklaver.com
New "function tables" in V13 documentation
In case someone is interested: there is a little discussion going on on Reddit whether the new format of presenting functions in V13 is a step backwards: https://www.reddit.com/r/PostgreSQL/comments/jpi0rp/does_anyone_else_feel_like_the_v13_docs_are_a/ Thomas
Re: Different bitness
Thx, Tom. On Sun, Nov 8, 2020 at 2:21 PM Tom Lane wrote: > > Igor Korot writes: > > ld: fatal: file ../postgresql/src/interfaces/libpq/libpq.so: wrong ELF > > class: ELFCLASS32 > > That path doesn't seem to quite agree with this one: > > > igor@solaris:~/dbhandlerSol/libpq/src/interfaces/libpq$ file libpq.so > > > regards, tom lane
Re: Foreign Data Wrapper Handler
On 11/8/20 11:09 AM, Susan Hurst wrote: The first pass thru https://www.postgresql.org/docs/12/fdwhandler.html does not tell me what I think I need to know, but I will digest this more thoroughly. Maybe I need to understand more of the lingo re: foreign data wrappers. I do understand that all fdw names must be unique within a database so if I want to connect to more than one foreign db, I need a different name for each connection. I cannot name each fdw postgres_fdw. I would like to name the fdws something like: dbname_to_foreigndbname. For example, here are 2 possible fdws: create foreign data wrapper stp_to_geo; create foreign data wrapper stp_to_metrics; Aren't you looking for?: https://www.postgresql.org/docs/12/sql-createserver.html " A foreign server typically encapsulates connection information that a foreign-data wrapper uses to access an external data resource. Additional user-specific connection information may be specified by means of user mappings. The server name must be unique within the database. " That syntax creates the fdw and I can create user mappings but I cannot import any foreign schemas into my database. The error message says that there is no handler for the fdw. That's where I'm stuck. BTW, I did try using postgres_fdw as a handler... create foreign data wrapper stp_to_geo handler postgres_fdw; ...but then I got these errors: ERROR: function postgres_fdw() does not exist ERROR: foreign-data wrapper "stp_to_geo" does not exist Looks like I need to study a bit more. Sue --- Susan E Hurst Principal Consultant Brookhurst Data LLC Email: susan.hu...@brookhurstdata.com Mobile: 314-486-3261 On 2020-11-07 14:51, Adrian Klaver wrote: On 11/7/20 12:44 PM, Susan Hurst wrote: Can anyone recommend a good online resource for learning how to set up a foreign data wrapper using a custom fdw name? It seems the trick is to use a handler to make it work but so far the search results have been elusive for creating a fdw with a successful outcome. Have you gone through this?: https://www.postgresql.org/docs/12/fdwhandler.html Also can we get a definition of 'custom fdw name'? I'm using 'PostgreSQL 11.8 on amd64-portbld-freebsd12.1, compiled by FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1), 64-bit' Thanks for your help! Sue -- Adrian Klaver adrian.kla...@aklaver.com
Re: Different bitness
Igor Korot writes: > ld: fatal: file ../postgresql/src/interfaces/libpq/libpq.so: wrong ELF > class: ELFCLASS32 That path doesn't seem to quite agree with this one: > igor@solaris:~/dbhandlerSol/libpq/src/interfaces/libpq$ file libpq.so regards, tom lane
Different bitness
Hi, ALL, [code] CC -m64 -std=c++11 -o dist/Debug/OracleDeveloperStudio-Solaris-x86/liblibpostgres.so build/Debug/OracleDeveloperStudio-Solaris-x86/database_postgres.o -L../postgresql/src/interfaces/libpq -lpq -m64 -std=c++11 -G -KPIC -norunpath -h liblibpostgres.so ld: fatal: file ../postgresql/src/interfaces/libpq/libpq.so: wrong ELF class: ELFCLASS32 *** Error code 2 [/code] However testing the library reveals: [code] igor@solaris:~/dbhandlerSol/libpq/src/interfaces/libpq$ file libpq.so libpq.so: ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE2 SSE], dynamically linked, not stripped [/code] What is wrong here? I did do the clean the default 32-bit build and then rebuild with: [code] CFLAGS="-m64" LDFLAGS="-m64" ./configure && cd src/interface/libpq && gmake [/code] What am I missing? Thank you.
Re: Building for 64-bit platform
Thx. On Sun, Nov 8, 2020 at 12:15 AM Tom Lane wrote: > > Igor Korot writes: > > I build libpq with the standard configure/dmake. > > Now I realize I need t build it for a 64-bit platform. > > > My questions are: > > Is it enough to ust do > > Do "make distclean" at the top level, then re-configure with the > new options and re-make. > > Maybe you can get away with a partial rebuild, but there is no way > that it's worth your time to experiment. On any machine built in > the last two decades, you could have already finished a full rebuild > in the time it took me to type this. On the other hand, if you do > a partial rebuild and it turns out to be broken, you could waste > many hours figuring that out. > > regards, tom lane
Re: Foreign Data Wrapper Handler
The first pass thru https://www.postgresql.org/docs/12/fdwhandler.html does not tell me what I think I need to know, but I will digest this more thoroughly. Maybe I need to understand more of the lingo re: foreign data wrappers. I do understand that all fdw names must be unique within a database so if I want to connect to more than one foreign db, I need a different name for each connection. I cannot name each fdw postgres_fdw. I would like to name the fdws something like: dbname_to_foreigndbname. For example, here are 2 possible fdws: create foreign data wrapper stp_to_geo; create foreign data wrapper stp_to_metrics; That syntax creates the fdw and I can create user mappings but I cannot import any foreign schemas into my database. The error message says that there is no handler for the fdw. That's where I'm stuck. BTW, I did try using postgres_fdw as a handler... create foreign data wrapper stp_to_geo handler postgres_fdw; ...but then I got these errors: ERROR: function postgres_fdw() does not exist ERROR: foreign-data wrapper "stp_to_geo" does not exist Looks like I need to study a bit more. Sue --- Susan E Hurst Principal Consultant Brookhurst Data LLC Email: susan.hu...@brookhurstdata.com Mobile: 314-486-3261 On 2020-11-07 14:51, Adrian Klaver wrote: On 11/7/20 12:44 PM, Susan Hurst wrote: Can anyone recommend a good online resource for learning how to set up a foreign data wrapper using a custom fdw name? It seems the trick is to use a handler to make it work but so far the search results have been elusive for creating a fdw with a successful outcome. Have you gone through this?: https://www.postgresql.org/docs/12/fdwhandler.html Also can we get a definition of 'custom fdw name'? I'm using 'PostgreSQL 11.8 on amd64-portbld-freebsd12.1, compiled by FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1), 64-bit' Thanks for your help! Sue
Re: Not able to set pgaudit.log with pgaudit 1.3.2 in PostgreSQL 11.9
Hi Brad Thank you for pointing this out, my bad I was looking at the wrong version readme file. It's working after removing misc_set. On Sun, 8 Nov 2020 at 01:38, Brad Nicholson wrote: > Dhinakaran R wrote on 2020/11/07 02:03:22 > PM: > > > > > I had installed PostgreSQL 11.9 and pgaudit 1.3.2. updated > > > shared_preload_libraries, restarted PostgreSQL, created an extension > for > > > pgaudit and set parameters for pgaudit in postgresql.conf. But > > > surprisingly pgaudit.log is not getting picked up and neither able to > > > set it manually. > > > > > pgaudit.log = 'write, role, ddl, misc_set' > > misc_set was added in pgAudit 1.4, if you remove that it will likely work. > > pgAudit should probably log when it has an invalid parameter. > > Brad. > >
