date:20080409

[GENERAL] include PostgreSQL utilities into 3rd party program package

2008-04-09 Thread Michael Raven

Hello everybody.

I've got some kind of PostgreSQL copyright related question.

Our company is developing an commercial product for PostgreSQL administration.
We want to include some utilities (i.e. pg_dump.exe, pg_restore.exe etc)
from PostgreSQL for Windows installation package to installation package
of our product and use these utilities within our program.

Can we make it freely? Whether there are any special conditions for
this purpose?
What legal aspects of it exist?

Best regards,
Michael Raven.

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

Re: [GENERAL] select statement fails

2008-04-09 Thread Francisco Figueiredo Jr.

On Wed, Apr 9, 2008 at 1:31 PM, Francisco Figueiredo Jr.
<[EMAIL PROTECTED]> wrote:
> > >
>  > >
>  >
>  >  Ask the .npgsql mailing lists. They'll be able to tell you. There must be 
> a
>  > way of handling "non-standard" types in any case.
>  >
>
>  Hi all!
>
>  We are already working on that. The cast problem is indeed a bug in
>  Npgsql. We already have a one line fix for it.
>
>  Check it out here:
>
>  http://pgfoundry.org/forum/message.php?msg_id=1003377
>
>  I hope it helps.
>

Patch applied!

Please, grab latest cvs code and give it a try. Note that you still
will receive an string when working with char columns. But you will be
able to assign char values to NpgsqlParameters without any problem.

Please, let us know if you have any problems.

-- 
Regards,

Francisco Figueiredo Jr.
http://fxjr.blogspot.com
http://www.npgsql.org

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

[GENERAL] Write in file from postgres

2008-04-09 Thread Kevin Martins




--
From: "Kevin Martins" <[EMAIL PROTECTED]>
Sent: Thursday, April 10, 2008 12:03 AM
To: 
Subject: Re: [GENERAL] pain of postgres upgrade with extensions



Hello everybody,
First off all I am new in postgres but allready got some questions. It's 
possible to wirte in a file from postgres?

Kevin Martins
--
From: "Dave Potts" <[EMAIL PROTECTED]>
Sent: Wednesday, March 12, 2008 8:46 PM
To: 
Subject: Re: [GENERAL] pain of postgres upgrade with extensions


Greg Sabino Mullane wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160




- dump version N database
- create empty version N+1 database
- install N+1's version of each needed contrib module into new database
- restore dump, ignoring "object already exists" errors

There is a TODO to figure out some cleaner way of handling this sort
of thing ...



I think I smell a GSOC project



I think there  is a slight misunderstanding here,  I was refering to
extensions items such as postgis, plr, pgperl, etc.  These have a slight
different foot print to the projects in the contrib directory.

Dave

- --
Greg Sabino Mullane [EMAIL PROTECTED]
End Point Corporation
PGP Key: 0x14964AC8 200803121533
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAkfYMBMACgkQvJuQZxSWSsjmmwCg1JvB0G2py5jSbJdSZpWR8YyV
D4YAoLg2ZinEEGoNEU7S2mcL3bqhmNIh
=7pvA
-END PGP SIGNATURE-













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



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

Re: [GENERAL] pain of postgres upgrade with extensions

2008-04-09 Thread Kevin Martins



Hello everybody,
First off all I am new in postgres but allready got some questions. It's 
possible to wirte in a file from postgres?

Kevin Martins
--
From: "Dave Potts" <[EMAIL PROTECTED]>
Sent: Wednesday, March 12, 2008 8:46 PM
To: 
Subject: Re: [GENERAL] pain of postgres upgrade with extensions


Greg Sabino Mullane wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160




- dump version N database
- create empty version N+1 database
- install N+1's version of each needed contrib module into new database
- restore dump, ignoring "object already exists" errors

There is a TODO to figure out some cleaner way of handling this sort
of thing ...



I think I smell a GSOC project



I think there  is a slight misunderstanding here,  I was refering to
extensions items such as postgis, plr, pgperl, etc.  These have a slight
different foot print to the projects in the contrib directory.

Dave

- --
Greg Sabino Mullane [EMAIL PROTECTED]
End Point Corporation
PGP Key: 0x14964AC8 200803121533
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAkfYMBMACgkQvJuQZxSWSsjmmwCg1JvB0G2py5jSbJdSZpWR8YyV
D4YAoLg2ZinEEGoNEU7S2mcL3bqhmNIh
=7pvA
-END PGP SIGNATURE-













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



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

Re: [GENERAL] Disable Triggers

2008-04-09 Thread Tom Lane

"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> You should be using ALTER TABLE and not worry about changing tgenabled
> yourself, in case it wasn't obvious.

Yeah.  I had imagined Terry was hacking some backend code to do this,
in which case invoking CacheInvalidateRelcache directly might be
reasonable.  But updating tgenabled directly from client code is Just A
Bad Idea.

regards, tom lane

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

Re: [GENERAL] Disable Triggers

2008-04-09 Thread Geoffrey


Terry Lee Tucker wrote:

Greetings:

We have been working diligently toward integrating Slony into our production 
databases. We've been having trouble with various tables, although being 
replicated perfectly in the initial replication stage, afterwards, getting 
out of sync.


I have finally figured out what the problem is. We have a Perl process that 
continually updates certain columns across all databases. That Perl process 
calls a function we have written called disable_triggers which updates 
pg_class, setting reltriggers to 0 for the given table, and then later, after 
the work is complete, resetting reltriggers to the original value. 
Unfortunately, during this process, the Slony trigger is disabled as well 
which is causing our problem.


My questions is this: how would I go about changing my function so that all 
the triggers EXCEPT the Slony trigger would be disabled? Any ideas?


Version:
PostgreSQL 7.4.19 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.4.6 
20060404 (Red Hat 3.4.6-9)


Me thinks you forgot to mention that you are working on implementing 
this on Postgresql 8.3.1.



--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
 - Benjamin Franklin

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

Re: [GENERAL] connecting VB to postgreSQL

2008-04-09 Thread Francisco Figueiredo Jr.

On Wed, Apr 9, 2008 at 7:20 AM, leoabhi <[EMAIL PROTECTED]> wrote:
>
>   Hello,
>
Hello Abhi!

>   I wish to connect Visual Studio 2008(VB) to PostgreSQL..
>

Have you tried Npgsql?

http://www.npgsql.org
http://project.npgsql.org
http://documentation.npgsql.org

I hope it helps.


-- 
Regards,

Francisco Figueiredo Jr.
fxjr.blogspot.com
www.npgsql.org

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

Re: [GENERAL] Disable Triggers

2008-04-09 Thread Geoffrey


Greg Sabino Mullane wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160



I see the following in the documentation for pg_trigger related
to tgenabled: "Controls in which session_replication_role modes the
trigger fires. O = trigger fires in "origin" and "local" modes,
D = trigger is disabled, R = trigger fires in "replica" mode, A =
trigger fires always."



My question is: When tgenabled is set to "D", how does that setting
interact with session_replication_role and, is there a way to use
tgenabled with a setting of "D" to prevent a particular trigger
from firing. Using ALTER TABLE to disable the trigger won't work
because the whole table is locked during the transaction and I only
want the disabled trigger to apply to the current transaction in the
current session.


If you simply want to ignore all triggers, just use a 'replica' role.
When done, switch it back to 'origin' (or your default, which should
be origin).

If you want to fire only a single trigger, set it to 'always' mode and
switch to 'replica'. If you want to fire all triggers *except* a
certain trigger, set that trigger to replica mode and leave the
session_replication_mode unchanged (default/origin).

You should be using ALTER TABLE and not worry about changing tgenabled
yourself, in case it wasn't obvious. You should be able to make permanent
changes and then just use session_replication_role to control how it acts
in a particular transaction.


The issue at hand (I work with the OP), is that our current application 
disables all triggers quite often.  Enter Slony, we want to replicate. 
So, what we need to do is, disable ALL triggers EXCEPT slony triggers.


--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
 - Benjamin Franklin

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

Re: [GENERAL] Disable Triggers

2008-04-09 Thread Greg Sabino Mullane


-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


> I see the following in the documentation for pg_trigger related
> to tgenabled: "Controls in which session_replication_role modes the
> trigger fires. O = trigger fires in "origin" and "local" modes,
> D = trigger is disabled, R = trigger fires in "replica" mode, A =
> trigger fires always."

> My question is: When tgenabled is set to "D", how does that setting
> interact with session_replication_role and, is there a way to use
> tgenabled with a setting of "D" to prevent a particular trigger
> from firing. Using ALTER TABLE to disable the trigger won't work
> because the whole table is locked during the transaction and I only
> want the disabled trigger to apply to the current transaction in the
> current session.

If you simply want to ignore all triggers, just use a 'replica' role.
When done, switch it back to 'origin' (or your default, which should
be origin).

If you want to fire only a single trigger, set it to 'always' mode and
switch to 'replica'. If you want to fire all triggers *except* a
certain trigger, set that trigger to replica mode and leave the
session_replication_mode unchanged (default/origin).

You should be using ALTER TABLE and not worry about changing tgenabled
yourself, in case it wasn't obvious. You should be able to make permanent
changes and then just use session_replication_role to control how it acts
in a particular transaction.

Here's a quick example:

SET client_min_messages = 'ERROR';
DROP SCHEMA IF EXISTS triggertest CASCADE;
SET client_min_messages = 'NOTICE';

CREATE SCHEMA triggertest;

SET SEARCH_PATH = triggertest;

CREATE TABLE foo(a int);

INSERT INTO foo VALUES (1);

CREATE FUNCTION trig1()
RETURNS TRIGGER
LANGUAGE plpgsql
AS $_$
 BEGIN
 RAISE NOTICE 'I am trigger one';
 RETURN NULL;
 END;
$_$;

CREATE FUNCTION trig2()
RETURNS TRIGGER
LANGUAGE plpgsql
AS $_$
 BEGIN
 RAISE NOTICE 'I am trigger two';
 RETURN NULL;
 END;
$_$;

CREATE FUNCTION trig3()
RETURNS TRIGGER
LANGUAGE plpgsql
AS $_$
 BEGIN
 RAISE NOTICE 'I am trigger three';
 RETURN NULL;
 END;
$_$;

CREATE TRIGGER t1 AFTER UPDATE on foo
FOR EACH ROW EXECUTE PROCEDURE trig1();

CREATE TRIGGER t2 AFTER UPDATE on foo
FOR EACH ROW EXECUTE PROCEDURE trig2();

CREATE TRIGGER t3 AFTER UPDATE on foo
FOR EACH ROW EXECUTE PROCEDURE trig3();

UPDATE foo SET a=a; -- all three fire

ALTER TABLE foo ENABLE ALWAYS TRIGGER t1;

ALTER TABLE foo ENABLE REPLICA TRIGGER t2;

UPDATE foo SET a=a; -- two does not fire

SET session_replication_role TO 'replica';

UPDATE foo SET a=a; -- three does not fire

SET session_replication_role TO DEFAULT;

UPDATE foo SET a=a; -- two does not fire

The output of the above yields:

CREATE TRIGGER
psql:trig.example:53: NOTICE:  I am trigger one
psql:trig.example:53: NOTICE:  I am trigger two
psql:trig.example:53: NOTICE:  I am trigger three
UPDATE 1
ALTER TABLE
ALTER TABLE
psql:trig.example:59: NOTICE:  I am trigger one
psql:trig.example:59: NOTICE:  I am trigger three
UPDATE 1
SET
psql:trig.example:63: NOTICE:  I am trigger one
psql:trig.example:63: NOTICE:  I am trigger two
UPDATE 1
SET
psql:trig.example:67: NOTICE:  I am trigger one
psql:trig.example:67: NOTICE:  I am trigger three
UPDATE 1


- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200804091452
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAkf9EUUACgkQvJuQZxSWSsgrQwCg7Q6ZBLBzzfy5fntxXPI17i8l
VTUAoNK++VH2lVj42tstfXM49P7NtCa+
=ex6Z
-END PGP SIGNATURE-



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

Re: [GENERAL] Quoting table/column names vs performance

2008-04-09 Thread Ivan Sergio Borgonovo

On Wed, 9 Apr 2008 19:11:57 +0200
Alban Hertroys <[EMAIL PROTECTED]> wrote:

> On Apr 9, 2008, at 5:27 PM, Jozef Ševčík wrote:
> > In MSSQL I had something like:
> > SELECT Column1,Column2 from MyTable
> >
> > In PgSQL I write:
> > SELECT “Column1”, “Column2” from “MyTable”
> >
> > Which is fine and working, I have no doubt about it. I’m just  
> > guessing if this does not affect performance
> > in any way.
> 
> What are you trying to fix that you don't just write SELECT  
> Column1,Column2 from MyTable ?
> Postgres understands that fine, why do you want to quote those  
> identifiers? Maybe your application code is case-sensitive with  
> regards to column (and maybe table) names?

There are a couple of small gotcha.

eg.

- PHP actually is case sensitive so:

$row['MyRow'] != $row['myrow']

If you used camel case in pg without quotes it will be a pain.

- Some pg functions aren't case-proof eg. pg_get_serial_sequence

I'm thinking to write a script to quote all identifiers... but I'm
worried it will look to much as a parser rather than a simple sed
script since I got trapped by the above too.


-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it


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

Re: [GENERAL] connecting VB to postgreSQL

2008-04-09 Thread Craig Ringer

Abhishek MANDHANA wrote:

Did 30 seconds search worked ? for me its didnt ?

Please just dont test the connection, the applet shows Connection successful
, Are you able to create it and see it under Server Explorer?

I mostly use Linux. I'm on Vista right now, but I have never used Visual
Basic and have none of the tools for it. I have Visual Studio for C++
installed, but not for Visual Basic .NET. So I can't test it, and I'm
afraid I'm not going to install VB.net to test it. As such, I'm working
from information available on the 'net, such as the PostgreSQL OLE DB
provider documentation (which, by the way, is hard to find - I landed up
digging it out of ViewCVS). You, however, will have a copy of the file
that came with your copy of the OLE DB provider.

This is the README file. I strongly suggest having a look:

http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/oledb/oledb/README?rev=1.7&content-type=text/x-cvsweb-markup

In any case, it's obvious in your screenshot that you left the "server"
and "location" fields blank in the connection setup form. This is most
likely the cause of your problem. Try putting "localhost" in the
"server" box, and the name of your database in the "location" box. If
you have not created a database yet, you will need to do so. See the
PostgreSQL documentation on how to do that.

As for the error message, it basically means "oops, it didn't work and I
don't know why". The PostgreSQL OLE DB provider README explains how to
get more detailed error information.

--
Craig Ringer

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

95 matches

Mail list logo