Re: [GENERAL] Client Authentication

[Klint Gore]

Stefan Sturm wrote:

Hello,

I set up a PostgreSQL 8.3.1 Server on my Webserver( located somewhere 
in the web ).
On my local Server I use the trust method to access the server. But on 
my Webserver I want to use an user with password to access the Server.

So I did the following:

I created a user( as superuser ) with:
createuser -P username


Then I add a new line to the pg_hba.conf file:
hostall username  0.0.0.0 
   md5


I want to access all databases from all IP-Adresses with this user.

But this fails :-(

WHere is my Error? I hope some can help me.

try adding a subnet mask
  host all username 0.0.0.0  0.0.0.0 md5
or a cidr mask
  host all username 0.0.0.0/0 md5

klint.

--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350

Ph: 02 6773 3789  
Fax: 02 6773 3266

EMail: [EMAIL PROTECTED]


--
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] Client Authentication

[A. Kretschmer]

am  Fri, dem 18.04.2008, um  8:41:17 +0200 mailte Stefan Sturm folgendes:
> Hello,
> 
> I set up a PostgreSQL 8.3.1 Server on my Webserver( located somewhere in the
> web ).
> On my local Server I use the trust method to access the server. But on my
> Webserver I want to use an user with password to access the Server.
> So I did the following:
> 
> I created a user( as superuser ) with:
> createuser -P username
> 
> 
> Then I add a new line to the pg_hba.conf file:
> hostall username  0.0.0.0   md5
~~~

This should be an CIDR, but it's only a IP.



> 
> I want to access all databases from all IP-Adresses with this user.
> 
> But this fails :-(
> 
> WHere is my Error? I hope some can help me.

Where ist the error-message?


Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

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

[GENERAL] Client Authentication

[Stefan Sturm]

Hello,

I set up a PostgreSQL 8.3.1 Server on my Webserver( located somewhere in the
web ).
On my local Server I use the trust method to access the server. But on my
Webserver I want to use an user with password to access the Server.
So I did the following:

I created a user( as superuser ) with:
createuser -P username


Then I add a new line to the pg_hba.conf file:
hostall username  0.0.0.0   md5

I want to access all databases from all IP-Adresses with this user.

But this fails :-(

WHere is my Error? I hope some can help me.

Thanks and greetings,
Stefan Sturm

Re: [GENERAL] In the belly of the beast (MySQLCon)

[Joshua D. Drake]

On Thu, 17 Apr 2008 16:43:04 -0400
Geoffrey <[EMAIL PROTECTED]> wrote:

> Joshua D. Drake wrote:
> > Hello,
> > 
> > I am currently chilling at MySQLCon. If any other Elephant riders
> > who are doing a little Dolphin hunting are about... I am in
> > Ballroom E about to give a talk on what Mysql can learn from
> > PostgreSQL.
> 
> Check the room for barrels of tar and feathers before you start your 
> presentation...

O.k. the presentation can not be found on planet...
www.planetpostgresql.org .

Joshua D. Drake 

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director |  PostgreSQL political pundit



signature.asc
Description: PGP signature

Re: [GENERAL] In the belly of the beast (MySQLCon)

[Joshua D. Drake]

On Thu, 17 Apr 2008 22:19:23 -0500
Josh Trutwin <[EMAIL PROTECTED]> wrote:
 
> Is your presentation available online at all?

Blogging the bad boy up right now Will be available soon.

Joshua D. Drake



-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director |  PostgreSQL political pundit



signature.asc
Description: PGP signature

Re: [GENERAL] In the belly of the beast (MySQLCon)

[Josh Trutwin]

On Thu, 17 Apr 2008 11:29:56 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> I am currently chilling at MySQLCon. If any other Elephant riders
> who are doing a little Dolphin hunting are about... I am in
> Ballroom E about to give a talk on what Mysql can learn from
> PostgreSQL.

Is your presentation available online at all?

Hope it goes well,

Josh

-- 
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] Duplicate Symbols - Compiler Warnings

[Terry Lee Tucker]

On Thursday 17 April 2008 19:32, Tom Lane wrote:
> Terry Lee Tucker <[EMAIL PROTECTED]> writes:
> > Didn't get any nibbles on this one. Can anybody provide any insight on
> > this?
>
> You're complaining in the wrong place ... I dunno what perlAPI.c is, but
> it's not part of Postgres.
>
> FWIW, plperl.c seems to work around the issue this way:
>
> #include "postgres.h"
> /* Defined by Perl */
> #undef _
>
> // include Perl headers here
>
> I'm not sure that's entirely the right solution, because Perl's _ macro
> is 100% useless in any project that considers ANSI C a prerequisite,
> whereas ours could be useful ... but right now plperl doesn't have any
> localization so it doesn't need the _ macro anyway.
>
>regards, tom lane

Tom,

Thanks for the reply. I've implemented your suggestion and the warning goes 
away. perlAPI.c is our own source file of functions which allows access to 
the Perl interpreter which is linked in with the application. We use this to 
access various Perl hashes that configure and control the system. We'll do 
some serious testing to see if I've broken anything.

As usual, thanks for your invaluable assistance...

-- 
Terry Lee Tucker
Turbo's IT Manager
Turbo, division of Ozburn-Hessey Logistics
2251 Jesse Jewell Pkwy NE
Gainesville, GA 30501
Tel: (336) 372-6812  Fax: (336) 372-6812  Cell: (336) 404-6987
[EMAIL PROTECTED]
www.turbocorp.com

-- 
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] Duplicate Symbols - Compiler Warnings

[Tom Lane]

Terry Lee Tucker <[EMAIL PROTECTED]> writes:
> Didn't get any nibbles on this one. Can anybody provide any insight on this?

You're complaining in the wrong place ... I dunno what perlAPI.c is, but
it's not part of Postgres.

FWIW, plperl.c seems to work around the issue this way:

#include "postgres.h"
/* Defined by Perl */
#undef _

// include Perl headers here

I'm not sure that's entirely the right solution, because Perl's _ macro
is 100% useless in any project that considers ANSI C a prerequisite,
whereas ours could be useful ... but right now plperl doesn't have any
localization so it doesn't need the _ macro anyway.

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] In the belly of the beast (MySQLCon)

[Aaron Glenn]

On Thu, Apr 17, 2008 at 11:29 AM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> Hello,
>
>  I am currently chilling at MySQLCon. If any other Elephant riders who
>  are doing a little Dolphin hunting are about... I am in Ballroom E
>  about to give a talk on what Mysql can learn from PostgreSQL.

is there a live video feed those of us not attending can watch?
I've got my popcorn in the microwave already...

-- 
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] Duplicate Symbols - Compiler Warnings

[Terry Lee Tucker]

Didn't get any nibbles on this one. Can anybody provide any insight on this?

Thanks...

On Thursday 17 April 2008 10:03, Terry Lee Tucker wrote:
> Greetings:
>
> We are converting from 7.4.19 to 8.3. While compiling our application using
> version 8.3, I have noticed the following warning from the compiler when
> compiling perlAPI.c:
>
> gcc -ggdb -Wall -Wmissing-prototypes -Wmissing-declarations -fforce-addr
> -DUNIX-DSTDERR_MSG  -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
> -fno-strict-aliasing -pipe-I/usr/local/include -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
> -I/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE  -I/usr/X11R6/include
> -I/usr/local/pg83/include -I/usr/local/pg83/include/server
> -I/esc/logpro/4.0/pgrnd/prog -c utility/perlAPI.c
> In file included
> from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/perl.h:37,
>  from /esc/logpro/4.0/pgrnd/prog/utility/perlAPI.h:10,
>  from utility/perlAPI.c:11:
> /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/config.h:2183:1: warning:
> "_"redefined
> In file included from
> /usr/local/pg83/include/postgresql/server/postgres.h:48, from
> /esc/logpro/4.0/pgrnd/prog/logpro.h:35,
>  from /esc/logpro/4.0/pgrnd/prog/utility/perlAPI.h:8,
>  from utility/perlAPI.c:11:
> /usr/local/pg83/include/postgresql/server/c.h:94:1: warning: this is the
> location of the previous definition
>
> In config.h, the symbol in question on line 2183 is:
> #define _(args) args
>
> In c.h (postgres) the offending symbol on line 94 is:
> #define _(x) gettext((x))
>
> I expect this to cause random core dumps when putting the application into
> production and it concerns me greatly. So, my question is, do you see this
> as a serious problem and, if so, what shall I do to resolve it? By the way,
> this problem does not exist when compiling with 7.4.19.
>
> TIA
> --
> Terry Lee Tucker
> Turbo's IT Manager
> Turbo, division of Ozburn-Hessey Logistics
> 2251 Jesse Jewell Pkwy NE
> Gainesville, GA 30501
> Tel: (336) 372-6812  Fax: (336) 372-6812  Cell: (336) 404-6987
> [EMAIL PROTECTED]
> www.turbocorp.com

-- 
Terry Lee Tucker
Turbo's IT Manager
Turbo, division of Ozburn-Hessey Logistics
2251 Jesse Jewell Pkwy NE
Gainesville, GA 30501
Tel: (336) 372-6812  Fax: (336) 372-6812  Cell: (336) 404-6987
[EMAIL PROTECTED]
www.turbocorp.com

-- 
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] In the belly of the beast (MySQLCon)

[Geoffrey]

Joshua D. Drake wrote:

Hello,

I am currently chilling at MySQLCon. If any other Elephant riders who
are doing a little Dolphin hunting are about... I am in Ballroom E
about to give a talk on what Mysql can learn from PostgreSQL.


Check the room for barrels of tar and feathers before you start your 
presentation...


--
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] In the belly of the beast (MySQLCon)

[Erik Jones]

Dude, you have got to let us know how that goes...

On Apr 17, 2008, at 1:29 PM, Joshua D. Drake wrote:

Hello,

I am currently chilling at MySQLCon. If any other Elephant riders who
are doing a little Dolphin hunting are about... I am in Ballroom E
about to give a talk on what Mysql can learn from PostgreSQL.

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director |  PostgreSQL political pundit



Erik Jones

DBA | Emma®
[EMAIL PROTECTED]
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com




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

[GENERAL] In the belly of the beast (MySQLCon)

[Joshua D. Drake]

Hello,

I am currently chilling at MySQLCon. If any other Elephant riders who
are doing a little Dolphin hunting are about... I am in Ballroom E
about to give a talk on what Mysql can learn from PostgreSQL.

Sincerely,

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director |  PostgreSQL political pundit



signature.asc
Description: PGP signature

Re: [GENERAL] Using meta-data for foreign key?

[David Wilson]

On Thu, Apr 17, 2008 at 1:55 PM, Roberts, Jon <[EMAIL PROTECTED]> wrote:
>  Using the term "metadata" is misleading in your example.  Metadata is
>  data about data and in your example, you just have data.  It is fine to
>  join tables in an RDBMS.
>

I believe you missed the OP's actual goal. He's not interested in
linking printing options to specific rows of the foo table; he wants
each column of the foo table to have a single entry in the printing
options table; that is, he wants a foreign key reference to the system
catalog giving the columns of entity foo. He does, in fact, appear to
be interested in a foreign key reference to a table's metadata.

-- 
- David T. Wilson
[EMAIL PROTECTED]

-- 
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] Using meta-data for foreign key?

[Roberts, Jon]

> I have an existing table in an app, along the lines of:
> >>
> >> CREATE TABLE foo (
> >>  name text,
> >>  address text,
> >>  some_numeric_info integer,
> >>  
> >> );
> >>
> 
> 
> I essentially need another table
> 
> CREATE TABLE foo_printing_options (
>   field_name text,
>   print_order int not null,
>   suppress boolean not null,
>   
> );
> 
> 
> The values of field_name in foo_printing_options would be the
individual
> field names in foo (i.e. name, address, etc).   foo_printing_options
> would be available to the user via the app to allow them to specify
> report layout.
> 
> My question, then, is if it considered acceptable practice to, instead
> of having field_name in the secondary table, have a foreign key
> reference back to the field definition in the meta-data.  This would
> allow the app to be less sensitive to schema changes (fairly common).
> 

Yes, of course you want to normalize your data in an operational
application and when doing so, you will want to use primary and foreign
keys.

CREATE TABLE foo (
id integer primary key not null,
name text,
address text,
some_numeric_info integer,
);


CREATE TABLE foo_printing_options (
id integer primary key not null,
foo_id integer not null,
field_name text,
print_order int not null,
suppress boolean not null,

> );

alter table foo_printing_options 
add foreign key (foo_id) references foo (id);


I can also see you adding a field_name table, a unique key on
printing_options.id and printing_options.print_order.  Name and address
in foo makes me think you should probably have a customer table (or is
foo the customer)?  What if your customer can have multiple addresses?
You'll need just an address table in that case.  A State table is likely
needed with maybe zip codes or cities.  

> Is linking to the metadata from the app tables directly bad?  Unsafe?
Ok?
> 

Using the term "metadata" is misleading in your example.  Metadata is
data about data and in your example, you just have data.  It is fine to
join tables in an RDBMS.



Jon

-- 
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] table as log (multiple writers and readers)

[Chris Browne]

[EMAIL PROTECTED] (Andrew Sullivan) writes:
> Oh, one other thing
>
> On Thu, Apr 17, 2008 at 12:44:51PM +0800, Craig Ringer wrote:
>  
>> > One way I can think of doing it is to write a seen_log that notes what the
>> > client has already seen with a timestamp of (say) 1 minute.  Then you can
>> > say "go forward from this time excluding ids (ids here)".
>> 
>> It won't work with multiple concurrent writers. There is no guarantee
>> that an INSERT with a timestamp older than the one you just saw isn't
>> waiting to commit.
>
> Yeah, I spoke imprecisely.  The idea is, "Start at timestamp _t_, but don't
> re-process these ones, which I've seen."  The trick is to set your start _t_
> far enough back in time that it's incompatible with your business logic that
> anything could still be pending from then.  This is nasty and prone to bugs,
> but it can be coded up.

The alternative pattern is to put a trigger on the table that collects
the primary key ID in a "queue" table.

If some updates were "still in flight" when the queue processor runs,
then it can catch them next time.

Curiously enough, I have had *two* meetings today where this was germaine ;-).
-- 
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/wp.html
Do not worry  about the bullet that  has got your name on  it. It will
hit you and it will kill  you, no questions asked. The rounds to worry
about are the ones marked: TO WHOM IT MAY CONCERN.

-- 
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] problem with tsearch and utf-8 on postgresql 8.1

[Pavel Stehule]

Hello

UTF8 is supported from 8.2 version

Regards
Pavel Stehule

On 17/04/2008, Ottavio Campana <[EMAIL PROTECTED]> wrote:
> I created a database with locale [EMAIL PROTECTED], and I'm facing a weird 
> problem
> with tsearch. Let me show it:
>
>  tmptest=# SELECT * from pg_ts_cfg;
>  ts_name | prs_name |locale
>  -+--+--
>   default_russian | default  | ru_RU.KOI8-R
>   simple  | default  |
>   default | default  | [EMAIL PROTECTED]
>  (3 righe)
>
>  tmptest=# SELECT to_tsvector ('ciao mamma');
>  ERROR:  could not find tsearch config by locale
>  tmptest=# UPDATE pg_ts_cfg set locale = '[EMAIL PROTECTED]' where ts_name =
> 'default';
>  UPDATE 1
>  tmptest=# SELECT to_tsvector ('ciao mamma');
> to_tsvector
>  
>   'ciao':1 'mamma':2
>  (1 riga)
>
>  tmptest=# UPDATE pg_ts_cfg set locale = '[EMAIL PROTECTED]' where ts_name =
> 'default';
>  UPDATE 1
>  tmptest=# SELECT to_tsvector ('ciao mamma');
> to_tsvector
>  
>   'ciao':1 'mamma':2
>  (1 riga)
>
>  tmptest=# \q
>
>  So at first tsearch does not work. If I change it to [EMAIL PROTECTED] it 
> works
> and if I switch back to [EMAIL PROTECTED] it then works even with that locale.
>  I cannot understand the reason why it happens. By disconnecting from the db
> and connecting again the problem is still there. Do you have any idea why it
> happens?
>
>  I don't know if it matters, on the systems I have LANG="[EMAIL PROTECTED]" 
> and
> LANGUAGE="it_IT"
>
>  Thanks,
>
>  Ottavio
>
>  PS: Im running a backport of postgresql 8.1 on debian sarge.
>
>  --
>  Non c'e' piu' forza nella normalita', c'e' solo monotonia.
>
>
>

-- 
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] Using meta-data for foreign key?

[Tom Lane]

Mike Blackwell <[EMAIL PROTECTED]> writes:
> My question, then, is if it considered acceptable practice to, instead
> of having field_name in the secondary table, have a foreign key
> reference back to the field definition in the meta-data.

If you mean a foreign key reference into the system catalogs, we don't
support that :-(

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] Using meta-data for foreign key?

[Mike Blackwell]

More detail, as suggested.

I have an existing table in an app, along the lines of:
>>
>> CREATE TABLE foo (
>>  name text,
>>  address text,
>>  some_numeric_info integer,
>>  
>> );
>>


I essentially need another table

CREATE TABLE foo_printing_options (
  field_name text,
  print_order int not null,
  suppress boolean not null,
  
);


The values of field_name in foo_printing_options would be the individual
field names in foo (i.e. name, address, etc).   foo_printing_options
would be available to the user via the app to allow them to specify
report layout. 

My question, then, is if it considered acceptable practice to, instead
of having field_name in the secondary table, have a foreign key
reference back to the field definition in the meta-data.  This would
allow the app to be less sensitive to schema changes (fairly common).

Is linking to the metadata from the app tables directly bad?  Unsafe?  Ok?


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

[GENERAL] problem with tsearch and utf-8 on postgresql 8.1

[Ottavio Campana]

I created a database with locale [EMAIL PROTECTED], and I'm facing a weird 
problem with tsearch. Let me show it:


tmptest=# SELECT * from pg_ts_cfg;
 ts_name | prs_name |locale
-+--+--
 default_russian | default  | ru_RU.KOI8-R
 simple  | default  |
 default | default  | [EMAIL PROTECTED]
(3 righe)

tmptest=# SELECT to_tsvector ('ciao mamma');
ERROR:  could not find tsearch config by locale
tmptest=# UPDATE pg_ts_cfg set locale = '[EMAIL PROTECTED]' where ts_name = 
'default';

UPDATE 1
tmptest=# SELECT to_tsvector ('ciao mamma');
to_tsvector

 'ciao':1 'mamma':2
(1 riga)

tmptest=# UPDATE pg_ts_cfg set locale = '[EMAIL PROTECTED]' where ts_name = 
'default';

UPDATE 1
tmptest=# SELECT to_tsvector ('ciao mamma');
to_tsvector

 'ciao':1 'mamma':2
(1 riga)

tmptest=# \q

So at first tsearch does not work. If I change it to [EMAIL PROTECTED] it works 
and if I switch back to [EMAIL PROTECTED] it then works even with that locale.
I cannot understand the reason why it happens. By disconnecting from the 
db and connecting again the problem is still there. Do you have any idea 
why it happens?


I don't know if it matters, on the systems I have LANG="[EMAIL PROTECTED]" and 
 LANGUAGE="it_IT"


Thanks,

Ottavio

PS: Im running a backport of postgresql 8.1 on debian sarge.

--
Non c'e' piu' forza nella normalita', c'e' solo monotonia.



signature.asc
Description: OpenPGP digital signature

Re: [GENERAL] Using meta-data for foreign key?

[Erik Jones]

On Apr 17, 2008, at 10:23 AM, Mike Blackwell wrote:

I have an existing table in an app, along the lines of:

CREATE TABLE foo (
 name text,
 address text,
 some_numeric_info integer,
 
);

I now need to be able to associate additional information (e.g.  
printing

order) with each field.  Is it a bad idea to use the (fully qualified)
field name as a foreign key to link back to the table meta-data?  Is
there a better way?


You're going to have to be *much* more specific about what you're  
trying to do/talk about.  A complete example would be best.


Erik Jones

DBA | Emma®
[EMAIL PROTECTED]
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com




--
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] Problems running PostGreSQL silent install

[Jesus Becerra]

Un saludo a todos. Pueden probar el siguiente script, el cual me funcionó
perfectamente bien para una "silent install" del PostgreSQL 8.1.10:


msiexec.exe /i postgresql-8.1-int.msi /log resultado.txt /qr
INTERNALLAUNCH=1 ADDLOCAL=server,psql,pgadmin,psqlodbc BASEDIR="c:\postgres"
CREATESERVICEUSER=1 SERVICEDOMAIN="%COMPUTERNAME%" SERVICEACCOUNT="postgres"
SERVICEPASSWORD="test" SUPERUSER="algun_usuario"
SUPERPASSWORD="alguna_contrasena"

Repito: me funcionó muy bien!!!.

Tengan en cuenta que en la sección ADDLOCAL no pude agregar los "docs", ya
que obtenía el mensaje "silent installation of 8.3 fails with error code
2711", y en el archivo LOG que se genera se obtuvo la siguiente descripción
del error:

DEBUG: Error 2711:  The specified Feature name ('docs') not found in Feature
Table.
DEBUG: Error 2867:  The error dialog property is not set
The installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 2867. The
arguments are: , ,
The installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 2711. The
arguments are: docs, ,
MSI (c) (CC:A8) [11:54:11:343]: Product: PostgreSQL 8.1 -- The installer has
encountered an unexpected error installing this package. This may indicate a
problem with this package. The error code is 2711. The arguments are: docs,
,

Pueden probar con otras opciones para ver si les sigue funcionando, pero les
aseguro que con estas líneas me funcionó muy bien!. En tal caso que no les
funciones con SERVICEACCOUNT="postgres" y SERVICEPASSWORD="test", prueben
con: SERVICEACCOUNT="postgres3" SERVICEPASSWORD="test3", es decir, con un
número al final de dichos valores.

Un agradecimiento a los usuarios Greg Quinn y Magnus Hagander, de quienes
obtuve ideas para hacer funcionar este script. Saludos!.

[GENERAL] Using meta-data for foreign key?

[Mike Blackwell]

I have an existing table in an app, along the lines of:

CREATE TABLE foo (
  name text,
  address text,
  some_numeric_info integer,
  
);

I now need to be able to associate additional information (e.g. printing
order) with each field.  Is it a bad idea to use the (fully qualified)
field name as a foreign key to link back to the table meta-data?  Is
there a better way?


-- 
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] Unable to add a new column to a table named "in" (look like a bug ...)

[David Gagnon]

Forget about what I said .. I can see the IN and in table in pgadmin III ..
IN is the first one... sorry about that:-)

David



-- 
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] Unable to add a new column to a table named "in" (look like a bug ...)

[David Gagnon]

Hi Adam,

Yes your right .. here is the output.  The only thing is that in PGadminIII
I just see the "in" table

Thanks for your help anyway!

Have a good day
David

Welcome to psql 8.3.0, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
   \h for help with SQL commands
   \? for help with psql commands
   \g or terminate with semicolon to execute query
   \q to quit

Warning: Console code page (437) differs from Windows code page (1252)
 8-bit characters might not work correctly. See psql reference
 page "Notes for Windows users" for details.

postgres=# \?
General
  \c[onnect] [DBNAME|- USER|- HOST|- PORT|-]
 connect to new database (currently "postgres")
  \cd [DIR]  change the current working directory
  \copyright show PostgreSQL usage and distribution terms
  \encoding [ENCODING]
 show or set client encoding
  \h [NAME]  help on syntax of SQL commands, * for all commands
  \q quit psql
  \set [NAME [VALUE]]
 set internal variable, or list all if no parameters
  \timingtoggle timing of commands (currently off)
  \unset NAMEunset (delete) internal variable
  \prompt [TEXT] NAME
 prompt user to set internal variable
  \! [COMMAND]   execute command in shell or start interactive shell

Query Buffer
  \e [FILE]  edit the query buffer (or file) with external editor
  \g [FILE]  send query buffer to server (and results to file or |pipe)
  \p show the contents of the query buffer
  \r reset (clear) the query buffer
  \w FILEwrite query buffer to file

^Cpostgres=# \c reference
You are now connected to database "reference".
reference=# \d "IN"
   Table "public.IN"
 Column  |Type |   Modifiers
-+-+
 innum   | character varying(10)   | not null
 ts  | timestamp without time zone | not null default now()
 indescs | character varying[] |
 descs   | character varying[] |

reference=# \d "in"
 Table "public.in"
   Column   |Type |   Modifiers
+-+
 innum  | character varying(10)   | not null
 indesc_pri | character varying(100)  |
 indesc_sec | character varying(100)  |
 ts | timestamp without time zone | not null default now()
 indescs| character varying[] |
Indexes:
"in_pk" PRIMARY KEY, btree (innum)

reference=#

-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Adam Rich
Envoyé : Thursday, April 17, 2008 10:33 AM
À : 'David Gagnon'; pgsql-general@postgresql.org
Objet : Re: [GENERAL] Unable to add a new column to a table named "in" (look
like a bug ...)

> 
>   It worked Thanks!! But there is definitly something wrong with the
> error
> message I got (right?):
> 
> reference=# alter table "IN" add column INDESCS VARCHAR[];
> ERROR:  column "indescs" of relation "IN" already exists
> 

I don't know, what do you see when you \d "IN" ?

When you use double-quotes, capitalization is significant,
So "in" and "IN" and "In" are all different tables.  This error
message means you already have an upper-case "IN" table and it
already has a column INDESCS.



-- 
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] Unable to add a new column to a table named "in" (look like a bug ...)

[Adam Rich]

> 
>   It worked Thanks!! But there is definitly something wrong with the
> error
> message I got (right?):
> 
> reference=# alter table "IN" add column INDESCS VARCHAR[];
> ERROR:  column "indescs" of relation "IN" already exists
> 

I don't know, what do you see when you \d "IN" ?

When you use double-quotes, capitalization is significant,
So "in" and "IN" and "In" are all different tables.  This error
message means you already have an upper-case "IN" table and it
already has a column INDESCS.



-- 
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] Unable to add a new column to a table named "in" (look like a bug ...)

[Rodrigo Gonzalez]

Are you sure?

\d "IN"

Let us know if you have OTHER table called IN.

When you use quotes you are making them case sensitive, so "in" != "IN" 
!= "In" etc, etc


David Gagnon escribió:

Hi Adam,

  It worked Thanks!! But there is definitly something wrong with the error
message I got (right?):

reference=# alter table "IN" add column INDESCS VARCHAR[];
ERROR:  column "indescs" of relation "IN" already exists

Anyway I can workaround with what you gave me.

Thanks again
David



-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Adam Rich
Envoyé : Thursday, April 17, 2008 10:15 AM
À : 'David Gagnon'; pgsql-general@postgresql.org
Objet : Re: [GENERAL] Unable to add a new column to a table named "in" (look
like a bug ...)

  

Could you just have a look to the output below?  I try to add a column
to a
table named "in" (I know "in" is a reserved keyword but the table
exists and
I cannot change it).  Postgresql complains that the column already
exist but
it didn't.  Am I doing something wrong ?



Try:  ALTER TABLE "in" add column INDESCS VARCHAR[];

(note the double quotes and lower-case "in")



  





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GENERAL] PostgresSQL on a networked drive with multiple users

[Geoffrey]

J Ottery wrote:

Thanks Craig for making me look like an idiot. I feel bad now.


You don't look like an idiot, you look like someone who has just learned 
something.  If we don't learn from our mistakes, then we are idiots... ;)


--
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] Unable to add a new column to a table named "in" (look like a bug ...)

[David Gagnon]

Hi Adam,

  It worked Thanks!! But there is definitly something wrong with the error
message I got (right?):

reference=# alter table "IN" add column INDESCS VARCHAR[];
ERROR:  column "indescs" of relation "IN" already exists

Anyway I can workaround with what you gave me.

Thanks again
David



-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Adam Rich
Envoyé : Thursday, April 17, 2008 10:15 AM
À : 'David Gagnon'; pgsql-general@postgresql.org
Objet : Re: [GENERAL] Unable to add a new column to a table named "in" (look
like a bug ...)

> Could you just have a look to the output below?  I try to add a column
> to a
> table named "in" (I know "in" is a reserved keyword but the table
> exists and
> I cannot change it).  Postgresql complains that the column already
> exist but
> it didn't.  Am I doing something wrong ?

Try:  ALTER TABLE "in" add column INDESCS VARCHAR[];

(note the double quotes and lower-case "in")



-- 
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] Unable to add a new column to a table named "in" (look like a bug ...)

[Adam Rich]

> Could you just have a look to the output below?  I try to add a column
> to a
> table named "in" (I know "in" is a reserved keyword but the table
> exists and
> I cannot change it).  Postgresql complains that the column already
> exist but
> it didn't.  Am I doing something wrong ?

Try:  ALTER TABLE "in" add column INDESCS VARCHAR[];

(note the double quotes and lower-case "in")



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

[GENERAL] Unable to add a new column to a table named "in" (look like a bug ...)

[David Gagnon]

I all,

Could you just have a look to the output below?  I try to add a column to a
table named "in" (I know "in" is a reserved keyword but the table exists and
I cannot change it).  Postgresql complains that the column already exist but
it didn't.  Am I doing something wrong ?

Thanks to point me my error or to give me any advice to add the column I
need.

Regards
David





Welcome to psql 8.3.0, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
   \h for help with SQL commands
   \? for help with psql commands
   \g or terminate with semicolon to execute query
   \q to quit

Warning: Console code page (437) differs from Windows code page (1252)
 8-bit characters might not work correctly. See psql reference
 page "Notes for Windows users" for details.


postgres=# \c reference
You are now connected to database "reference".
reference=# \d "in"
 Table "public.in"
   Column   |Type |   Modifiers
+-+
 innum  | character varying(10)   | not null
 indesc_pri | character varying(100)  |
 indesc_sec | character varying(100)  |
 ts | timestamp without time zone | not null default now()
Indexes:
"in_pk" PRIMARY KEY, btree (innum)

reference=# alter table 'IN' add column INDESCS VARCHAR[];
ERROR:  syntax error at or near "'IN'"
LINE 1: alter table 'IN' add column INDESCS VARCHAR[];
^
reference=# alter table "IN" add column INDESCS VARCHAR[];
ERROR:  column "indescs" of relation "IN" already exists
reference=# \d "in"
 Table "public.in"
   Column   |Type |   Modifiers
+-+
 innum  | character varying(10)   | not null
 indesc_pri | character varying(100)  |
 indesc_sec | character varying(100)  |
 ts | timestamp without time zone | not null default now()
Indexes:
"in_pk" PRIMARY KEY, btree (innum)

reference=# alter table "IN" add column DESCS VARCHAR[];
ALTER TABLE
reference=# \d "in"
 Table "public.in"
   Column   |Type |   Modifiers
+-+
 innum  | character varying(10)   | not null
 indesc_pri | character varying(100)  |
 indesc_sec | character varying(100)  |
 ts | timestamp without time zone | not null default now()
Indexes:
"in_pk" PRIMARY KEY, btree (innum)

reference=#

 




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

[GENERAL] Duplicate Symbols - Compiler Warnings

[Terry Lee Tucker]

Greetings:

We are converting from 7.4.19 to 8.3. While compiling our application using 
version 8.3, I have noticed the following warning from the compiler when 
compiling perlAPI.c:

gcc -ggdb -Wall -Wmissing-prototypes -Wmissing-declarations -fforce-addr 
-DUNIX-DSTDERR_MSG  -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING 
-fno-strict-aliasing -pipe-I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm  
-I/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE  -I/usr/X11R6/include 
-I/usr/local/pg83/include -I/usr/local/pg83/include/server 
-I/esc/logpro/4.0/pgrnd/prog -c utility/perlAPI.c
In file included 
from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/perl.h:37,
 from /esc/logpro/4.0/pgrnd/prog/utility/perlAPI.h:10,
 from utility/perlAPI.c:11:
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/config.h:2183:1: warning: 
"_"redefined
In file included from /usr/local/pg83/include/postgresql/server/postgres.h:48,
 from /esc/logpro/4.0/pgrnd/prog/logpro.h:35,
 from /esc/logpro/4.0/pgrnd/prog/utility/perlAPI.h:8,
 from utility/perlAPI.c:11:
/usr/local/pg83/include/postgresql/server/c.h:94:1: warning: this is the 
location of the previous definition

In config.h, the symbol in question on line 2183 is:
#define _(args) args

In c.h (postgres) the offending symbol on line 94 is:
#define _(x) gettext((x))

I expect this to cause random core dumps when putting the application into 
production and it concerns me greatly. So, my question is, do you see this as 
a serious problem and, if so, what shall I do to resolve it? By the way, this 
problem does not exist when compiling with 7.4.19.

TIA
-- 
Terry Lee Tucker
Turbo's IT Manager
Turbo, division of Ozburn-Hessey Logistics
2251 Jesse Jewell Pkwy NE
Gainesville, GA 30501
Tel: (336) 372-6812  Fax: (336) 372-6812  Cell: (336) 404-6987
[EMAIL PROTECTED]
www.turbocorp.com

-- 
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] Master-master replication with PostgreSQL

[Rob Collins]

Thanks everyone for your very helpful comments. I'm setting up some spikes
to check performance and functionality of various alternatives.

Rob

On 16/04/2008, Greg Smith <[EMAIL PROTECTED]> wrote:
>
> On Wed, 16 Apr 2008, Rob Collins wrote:
>
>  My client has a flawed MS SQL Server system
> >
>
> There's another kind?
>
>  From what I've read, Slony-I does only master-slave replication and
> > Slony-II is not being actively developed. Is this right? Are there any
> > viable master-master replication tools for PostgreSQL.
> >
>
> Your later comments suggest you specifically need an asynchronous
> multi-master system, which rules out several suggestions.
>
> I've been collecting information on this topic at
> http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connection_Poolingwhich
>  you might find useful.  Nothing jumps out at me as being more
> appropriate for the situation you describe than Bucardo.
>
> --
> * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
>

Re: [GENERAL] String concat issues in 8.3.1 (8.3.1 bug?)

[A. Kretschmer]

am  Thu, dem 17.04.2008, um  3:05:14 -0600 mailte kevin kempter folgendes:
> However in the 8.3.1 cluster I get this (Both clusters have the same  
> data set - via a pg_dump):
> 
> # select customer_srcid || segment_srcid from test_dim;
> ERROR:  operator does not exist: bigint || bigint
> LINE 1: select customer_srcid || segment_srcid from sl_segment_dim;
>   ^
> HINT:  No operator matches the given name and argument type(s). You  
> might need to add explicit type casts.
> 
> 
> 
> 
> Thoughts ?

You have to cast int-values to text, untested:

select customer_srcid::text || segment_srcid::text ...



Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

-- 
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] String concat issues in 8.3.1 (8.3.1 bug?)

[Richard Huxton]

kevin kempter wrote:

I have a table as follows:

\d test_dim
 Table "public.test_dim"
 Column  |Type |   Modifiers
-+-+
 customer_srcid  | bigint  | not null
 segment_srcid  | bigint  | not null
 show_name   | character varying(500)  | not null
 create_dt   | timestamp without time zone | not null default now()


I have this table in a db on an 8.2.6 cluster and in another db on an 
8.3.1 cluster.


In both clusters I can do the following:


# select customer_srcid,  segment_srcid from test_dim;
 customer_srcid | segment_srcid
+---
  1 | 1
  1 | 2
  1 | 3
  1 |
  1 |
  1 |


Are you sure the definition has "not null" on it?


In version 8.2.6 I can do this:

# select customer_srcid || segment_srcid from test_dim;
 ?column?
--
 11
 12
 13


However in the 8.3.1 cluster I get this (Both clusters have the same 
data set - via a pg_dump):


# select customer_srcid || segment_srcid from test_dim;
ERROR:  operator does not exist: bigint || bigint
LINE 1: select customer_srcid || segment_srcid from sl_segment_dim;
  ^
HINT:  No operator matches the given name and argument type(s). You 
might need to add explicit type casts.


Some of the implicit typecasting has been tightened up in 8.3 - try 
casting to text first.


SELECT customer_srcid::text || segment_srcid::text ...

--
  Richard Huxton
  Archonet Ltd

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

[GENERAL] String concat issues in 8.3.1 (8.3.1 bug?)

[kevin kempter]

I have a table as follows:

\d test_dim
 Table "public.test_dim"
 Column  |Type |   Modifiers
-+-+
 customer_srcid  | bigint  | not null
 segment_srcid  | bigint  | not null
 show_name   | character varying(500)  | not null
 create_dt   | timestamp without time zone | not null default now()


I have this table in a db on an 8.2.6 cluster and in another db on an  
8.3.1 cluster.


In both clusters I can do the following:


# select customer_srcid,  segment_srcid from test_dim;
 customer_srcid | segment_srcid
+---
  1 | 1
  1 | 2
  1 | 3
  1 |
  1 |
  1 |
  1 | 1
  1 | 2
  1 | 3
  1 |
  1 |
  1 |
  1 | 1
  1 | 2
  1 | 3
  1 |
  1 |
  1 |
  1 | 1
  1 | 2
  1 | 3
  1 |
  1 |
  1 |
(24 rows)



In version 8.2.6 I can do this:

# select customer_srcid || segment_srcid from test_dim;
 ?column?
--
 11
 12
 13



 11
 12
 13



 11
 12
 13



 11
 12
 13



(24 rows)




However in the 8.3.1 cluster I get this (Both clusters have the same  
data set - via a pg_dump):


# select customer_srcid || segment_srcid from test_dim;
ERROR:  operator does not exist: bigint || bigint
LINE 1: select customer_srcid || segment_srcid from sl_segment_dim;
  ^
HINT:  No operator matches the given name and argument type(s). You  
might need to add explicit type casts.





Thoughts ?



Thanks in advance


/Kevin




--
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] Storing and accessing GeoData( Latitude and Longitude ) in PostgreSQL 8.3

[Stefan Sturm]

Hello,

thanks for your ansers.

PgSphere (http://pgfoundry.org/projects/pgsphere)
>

I think this look most promising. Is here someone using it and can give me
some tipps?

Thanks and greetings,
Stefan Sturm

Re: [GENERAL] ALTER TABLE DDL Triggers?

[Simon Riggs]

On Wed, 2008-04-16 at 17:49 -0400, Chris Browne wrote:

> It would presumably not be _completely_ implausible to run a trigger
> when a table was ALTERed; the trouble would be in evaluating the
> semantics what OLD.* and NEW.* ought to contain, _if anything_.

Agreed.

If there was a simple use case and some fairly straightforward
definition of what is needed, that would help move things forward.

For example, would it be useful if the trigger only had access to the
text of the DDL statement? Which DDL statements would it apply to? As
Chris points out, saying "we need everything" just becomes a blocker to
progress.

So if somebody listening would like to research, detail and *justify* a
useful set of additional behaviour then it may be possible to add it.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


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

[GENERAL] pg 8.3.0 unexpected sending network packet?

[Klint Gore]

My local firewall came up with a warning about postgres wanting to send 
a network packet and I'm wondering if anyone can shed some light on its 
trying to do?


The only line in pg_hba.conf that's not commented is
hostall all 127.0.0.1/32  trust

According to netstat -a, its only listening on 127.0.0.1:5432

The sender details matches to my computer.
129.180.49.84 is just another machine on the local network (not dhcp 
server/dns server/wins server/default gateway)


- firewall message --
Parent Process :C:\Program Files\PostgreSQL\8.3\bin\postgres.exe
Parent Version :8.3.0.831
Parent Description :PostgreSQL Server
Parent Process ID :0xB8 (Heximal) 184 (Decimal)


File Version :8.3.0.831
File Description :PostgreSQL Server (postgres.exe)
File Path :C:\Program Files\PostgreSQL\8.3\bin\postgres.exe
Process ID :0xBA4 (Heximal) 2980 (Decimal)

Connection origin :local initiated
Protocol :Raw Ethernet
Local Address : 0.0.0.0
Local Port :0
Remote Name :   
Remote Address :0.0.0.0

Remote Port : 0

Ethernet packet details:
Ethernet II (Packet Length: 56)
   Destination: ff-ff-ff-ff-ff-ff
   Source: 00-12-3f-e9-e8-49
Type: ARP (0x0806)
Address Resolution Protocol (ARP)
   Hardware type: Ethernet (0x0001)
   Protocol type: IP (0x0800)
   Hardware size: 6
   Protocol size: 4
   Opcode: Request
   Sender hardware address: 00-12-3f-e9-e8-49
   Sender IP address: 129.180.49.116
   Target hardware address: 00-00-00-00-00-00
   Target IP address: 129.180.49.84

Binary dump of the packet:
:  FF FF FF FF FF FF 00 12 : 3F E9 E8 49 08 06 00 01 | ?..I
0010:  08 00 06 04 00 01 00 12 : 3F E9 E8 49 81 B4 31 74 | ?..I..1t
0020:  00 00 00 00 00 00 81 B4 : 31 54 30 4C 02 01 00 04 | 1T0L
0030:  06 70 75 62 6C 69 63 A0 : | .public.   


--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350

Ph: 02 6773 3789  
Fax: 02 6773 3266

EMail: [EMAIL PROTECTED]


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