Re: [BUGS] BUG #3983: pgxs files still missing in win32 install (8.3.1)

2008-04-15 Thread Magnus Hagander
Joe Conway wrote:
> Magnus Hagander wrote:
> > Could this be somethingl ike missing PGDLLIMPORT specifications in
> > your addon module or something like that? Try checking the names of
> > the functions that are actually exported using "depends" or a
> > similar tool.
> 
> Ah, that sounds likely, since I have never had to worry about
> explicit exports with PL/R before. Can you point me to an example or
> cheat sheet on what I need to do?

Stick a PGDLLIMPORT where needed :-)

Though now that I think of it, you only need that for variables. We use
the (broken, really, but that's what we do) method of exporting every
single function we can find in the binaries... You should have the same
issue with pl/pgsql, and it doesn't add PGDLLIMPORT so you should be
good there.

So it shouldn't be that problem, really.


> >> ERROR:  could not load library "C:/Program 
> >> Files/PostgreSQL/8.3/lib/plr.dll": The specified procedure could
> >> not be found.
> > 
> > Actually, this looks like perhaps the backend is unable to load a
> > DLL that plr.dll depends on. Again, the "depends" tool can
> > hopefully show you what's missing there.
> 
> That's what I was originally thinking (R.dll), but now I suspect the 
> exported functions is probably the issue. I'll check this out when I
> get home tonight.

I hold this much more likely. It may be R.dll, it may be something that
R.dll depends on, or another direct dependency.


//Magnus

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


[BUGS] BUG #4108: PgInstaller Update modify install paths in Registry

2008-04-15 Thread Gildas PRIME

The following bug has been logged online:

Bug reference:  4108
Logged by:  Gildas PRIME
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system:   XP Professionnal
Description:PgInstaller Update modify install paths in Registry
Details: 

On the update of an existing PostGreSQL install 8.3.1 to 8.3.1 version
causes some bad modifications in the  Windows registry.

To reproduce this bug : 
1 - install PostGreSQL 8.3.1 into a directory different from the default
directory (by example : C:\Program Files\My Install\My PostGreSQL Install).I
insatll it with command line to have a slient install.
2 - Check in
HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\{B823632F-3B72-4514-886
1-B961CE263224}\
the keys "Base Directory" and "Data Directory" and in
HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Services\pgsql-8.3
the key Data Directory the Directories must be the path where you install
the PostGreSQL
3 - Launch the update.bat file present in the PostGreSQL installer archive
4 - Check again the different Keys, the values have changed to the "by
default" directory of PostGreSQL installation (C:\Program
Files\PostgreSQL\8.3\)...

PC : XP Professional French SP2 - Pentium 4 3.2Ghz - 1,5 Go RAM

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


[BUGS] domains missing some default castings

2008-04-15 Thread Pavel Stehule
Hello

When I derive domain from some type I expect same castings rules.
Minimally for literals. But it's not true:

CREATE DOMAIN sixc AS char(6) NOT NULL;

CREATE OR REPLACE FUNCTION fxx(sixc)
RETURNS sixc AS $$
SELECT 'abcdef'; -- Actual return type is unknown.
$$ LANGUAGE SQL;
SELECT fxx('abcdef');

-- ok
CREATE OR REPLACE FUNCTION fxx(sixc)
RETURNS char(6) AS $$
SELECT 'abcdef';
$$ LANGUAGE SQL;

Regards
Pavel Stehule

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