Re: [HACKERS] [GENERAL] C++ port of Postgres

[dandl]

> > From my particular perspective it would be enough if all the
> internal
> > headers (that one needs to use in writing server-side extensions)
> were
> > completely usable in C++.
> 
> That should already be the case.  There's even a dirty hack^WWscript
> that checks that that remains the case
> (src/tools/pginclude/cpluspluscheck).

The source code for my project is here:
https://github.com/davidandl/Andl/tree/master/plandl
https://github.com/davidandl/Andl/blob/master/plandl/plandl.c

I was not able to get this file to compile correctly in C++, and my
recollection is that at the time I asked on this list and that was the
advice. 

Sorry, I don't remember the error but it seemed to be too deeply embedded to
worry about. I just wrote the C code and moved on.

Since the Windows COM in the other part is C++ only, I finished up with a
mixed build. It works fine, but is not the ideal outcome.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org







-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] C++ port of Postgres

[dandl]

> Well, getting so that we can at least compile in both systems would
> certainly increase the chances of somebody being willing to work on
> such a design.  

>From my particular perspective it would be enough if all the internal headers 
>(that one needs to use in writing server-side extensions) were completely 
>usable in C++. It's not so much hacking on the internals, it's more about 
>being to build an extension DLL in C++ that makes extensive use of calls to 
>internals without having to write shim layers. That looks like a lot less work 
>than a full C++ port.

And if nobody ever does, then at least people who want
> to fork and do research projects based on PostgreSQL will have
> slightly less work to do when they want to hack it up.  PostgreSQL
> seems to be a very popular starting point for research work, but a
> paper I read recently complained about the antiquity of our code base.
> I prefer to call that backward-compatibility, but at some point people
> stop thinking of you as backward-compatible and instead think of you
> as simply backward.

Certainly the positive arguments for sticking with pure C are diminishing over 
time, perhaps faster in perception than in fact.

> > A lot of the other things people have muttered about, such as
> heavier
> > use of inline functions instead of macros, don't particularly need
> C++
> > at all.

My point is only that C++ can be used to provide better type safety, with 
little of any effect on performance.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org









-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SPI_exec ERROR in pl/r of R 3.2.4 on PostgreSQL on Windows 7

[dandl]

Windows 7 vs 10 makes no odds here. What matters is whether your Postgres or R 
installations are x64 or x86.

 

Any x64 Windows can run x64 or x86 software perfectly happily, but you can’t 
mix a DLL with an EXE of a different flavour. They have to match.

 

Regards

David M Bennett FACS

  _  

Andl - A New Database Language - andl.org

 

 

From: pgsql-hackers-ow...@postgresql.org 
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Dave Cramer
Sent: Tuesday, 3 May 2016 11:55 PM
To: Andre Mikulec 
Cc: Joe Conway ; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] SPI_exec ERROR in pl/r of R 3.2.4 on PostgreSQL on 
Windows 7

 

Does anyone else have a Windows 7 installation we can test this on ?

 

This 
https://github.com/postgres-plr/plr/files/191013/plr-8.3.0.16-pg9.5-win32.zip 
is actually a 64 bit version built on windows 10. I've had one confirmation 
that it works.

 

Dave




Dave Cramer

da...@postgresintl.com  

www.postgresintl.com  

 

On 30 April 2016 at 12:39, Andre Mikulec mailto:andre_miku...@hotmail.com> > wrote:

Joe,

"
Who did the compiling? Did you compile everything yourself, or use
binary installers for some of it? If so, which ones?
"

This is really a continuation of the experience I had with Dave Cramer in here.

Postgresql 9.5 support #1
https://github.com/postgres-plr/plr/issues/1


To try to figure out the problem, ( and perhaps? eliminate Microsoft from the 
problem),
I compiled a PostgreSQL [debug] version myself.

C:\Users\AnonymousUser\Desktop\PostgreSQL.9.5.1\App\PgSQL>chcp 1252 > nul && 
"%PGSQL%\bin\psql.exe"
psql (9.5.1)
Type "help" for help.

postgres=# select version();
  version

 PostgreSQL 9.5.1 on i686-pc-mingw32, compiled by gcc.exe 
(x86_64-posix-seh-rev0, Built by MinGW-W64 project) 5.3.0, 64-bit
(1 row)

I also built a non-debug plr.dll/plr myself too.
I modified ( mostly simplified ) 
https://github.com/jconway/plr/blob/master/Makefile
in the Makefile, I eliminated ( by much trial and error ) the OS non_window 
stuff, the pkg-config stuff, and the  PGXS stuff .

Then I did,
AnonymousUser@ANONYMOUSX /c/Users/AnonymousUser/postgresql-9.4.1/contrib
$ make -C plr clean

AnonymousUser@ANONYMOUSX /c/Users/AnonymousUser/postgresql-9.4.1/contrib
$  make -C plr all

So now I have my own plr.dll.

Then, I followed the instructions ( INSTALL.txt ) found in here.
http://www.joeconway.com/plr/plr-8.3.0.16-pg9.4-win64.zip

However, I used my own plr.dll/plr
Seems, that in the destination, I had to copy plr.dll to plr, but that seems to 
work fine.

Later, after I finish following "create extension plr;" found in 
http://www.joeconway.com/plr/doc/plr-install.html

I do

postgres=# select plr_version();
 plr_version
-
 08.03.00.16
(1 row)

postgres=#   select plr_environ();

 (PGDATA,C:/Users/AnonymousUser/Desktop/PostgreSQL.9.5.1/Data/data)
 (PGDATABASE,postgres)
 
(PGLOCALEDIR,"C:\\Users\\AnonymousUser\\Desktop\\PostgreSQL.9.5.1\\App\\PgSQL\\share\\")
 (PGLOG,"C:\\Users\\AnonymousUser\\Desktop\\PostgreSQL.9.5.1\\Data\\log.txt")
 (PGSQL,"C:\\Users\\AnonymousUser\\Desktop\\PostgreSQL.9.5.1\\App\\PgSQL")
 (PGSYSCONFDIR,C:/Users/AnonymousUser/Desktop/PostgreSQL.9.5.1/App/PgSQL/etc)
 (PGUSER,postgres)

 (R_ARCH,/x64)
 (R_HOME,C:/Users/AnonymousUser/Desktop/R-3.2.4)
 (R_KEEP_PKG_SOURCE,yes)
 (R_LIBS_USER,"C:\\Users\\AnonymousUser\\Documents/R/win-library/3.2")
 (R_USER,"C:\\Users\\AnonymousUser\\Documents")

NOTE: The directory structure is from Postgre 9.4 Portable,  I just use ONLY 
the directory structure.
The one and ONLY file I use is the pgsql.cmd batch startup file ( I did my 
'environment' and 'user friendly modifications.' )

postgres=#

I do this, I get no results, and no error.

postgres=# SELECT * FROM pg_catalog.pg_class WHERE relname = 'plr_modules' AND 
relnamespace = 2200;
 relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode 
| reltablespace | relpages
-+--+-+---+--+---+-+---+--
(0 rows)

But, then this ( R language code ) strangely works.

postgres=# select r_version(); # THIS IS THE 'R LANGUAGE' ( IF THE EXTENSION 
'works' )
r_version
-
 (platform,x86_64-w64-mingw32)
 (arch,x86_64)
 (os,mingw32)
 (system,"x86_64, mingw32")
 (status,"")
 (major,3)
 (minor,2.4)
 (year,2016)
 (month,03)
 (day,10)
 ("svn rev",70301)
 (language,R)
 (version.string,"R version 3.2.4 (2016-03-10)")
 (nickname,"Very Secure Dishes")
(14 rows)

This does not work.
postgres=# select upper(typname) || 'OID' as typename, oid from 
pg_catalog.pg_type where typtype = 'b' order by typname;
ERROR:  could not open file "base/12373/1247": No such file or direc

Re: [HACKERS] About subxact and xact nesting level...

[dandl]

> ow...@postgresql.org] On Behalf Of Tom Lane
> > Are there specific requirements or things to do/avoid in order to use
> > subtransactions (at the PL API level)?
> 
> There isn't, currently, any very hard-and-fast rule about what APIs
> extensions should use or not use.  My advice is to borrow freely from
> existing PLs, particularly pl/pgsql.  You might have to change your code
in
> future PG major versions, but that could happen anyway.

I guess you're right. It's not that big, and most of the interesting stuff
seems to be in just a couple of files. And after all, that should be the
gold standard for a PL!

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] About subxact and xact nesting level...

[dandl]

> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> >> The file xact.c contains references to sub-transactions (subxact) and
> >> transaction nesting level, but no obvious documentation about what
> >> these correspond to in SQL.
> 
> > Subtransactions are used to implement SAVEPOINT, and also BEGIN blocks
> > with EXCEPTION clauses in plpgsql.
> 
> Yeah.  The implementation is based on nested subtransactions, and that
> concept also applies pretty directly to, eg, BEGIN/EXCEPT blocks in
plpgsql.
> But what's exposed to SQL is SAVEPOINT/RELEASE SAVEPOINT/ ROLLBACK TO
> SAVEPOINT, because those operations are what the standard specifies.  If
you
> hold your head at the correct angle you can see those as nested
> subtransactions, but it's not exactly obvious --- mainly because RELEASE
and
> ROLLBACK can exit multiple levels of nested subtransaction in one command.

Yes, that answers the question.

What now concerns me is that access to these capability seems to require
calling these three 'internal' functions, for which it's hard to determine
the prerequisites. The SPI interface is well-documented and the conversion
functions I'm using are not stateful and look pretty safe. I've got the
process model figured out well enough, but the transaction model is not so
easy. State looks important; so does memory management.

Are there specific requirements or things to do/avoid in order to use
subtransactions (at the PL API level)?

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org







-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] About subxact and xact nesting level...

[dandl]

> From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com]

> > The file xact.c contains references to sub-transactions (subxact) and
> > transaction nesting level, but no obvious documentation about what
> > these correspond to in SQL. A search shows that plpython supports
> > something called “proper sub transactions”. There are random mentions
> > of subtransactions in the release notes, but nothing substantive that
> > I can find, and nothing about transaction nesting.
> >
> > Any pointers to docs or help to understand much appreciated.
> 
> Subtransactions are used to implement SAVEPOINT, and also BEGIN blocks with
> EXCEPTION clauses in plpgsql.
> 
> http://www.postgresql.org/docs/9.5/static/sql-savepoint.html
> http://www.postgresql.org/docs/9.5/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING

Thanks. I guess that explains the nesting level too. It seems there is an 
internal API based on:
* BeginInternalSubTransaction
* RollbackAndReleaseCurrentSubTransaction
* ReleaseCurrentSubTransaction

This looks like something I shall need to use. I have the plandl language 
handler all working, and understanding the transaction environment is turning 
out to be a major challenge. 

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org







-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers