Nabble - PostgreSQL - interfaces

Re: ecpg & 8.3 -> 8.4 migration

2009-11-24T07:44:04Z

On Sat, Nov 21, 2009 at 12:49:33PM -0800, Mark Richardson wrote:
> I'm pretty sure the problem I found is related to this, but I found that ecpg
> doesn't process booleans correctly- this was in a old version of postgres (I
> think it was 7.4.2). I traced it down in the code, and there is a section
> that defines the values to be "yes" or "no", but then further processing
> looks for "true" or "false", so the end result is that a boolean is ALWAYS
> false, because the 2 filters don't match.

Is this a bug that you saw back then in 7 something, or a bug you still see?

> If you're interested in more detail, I have code fixes (they are at work so I'll send on Monday).

Please send them. I'm interested.

Michael

--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@...
VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL

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

Re: ecpg & 8.3 -> 8.4 migration

2009-11-21T12:49:33Z

I'm pretty sure the problem I found is related to this, but I found that ecpg doesn't process booleans correctly- this was in a old version of postgres (I think it was 7.4.2). I traced it down in the code, and there is a section that defines the values to be "yes" or "no", but then further processing looks for "true" or "false", so the end result is that a boolean is ALWAYS false, because the 2 filters don't match.

If you're interested in more detail, I have code fixes (they are at work so I'll send on Monday).

Mark

--- On Fri, 11/20/09, Tom Lane <tgl@...> wrote:

From: Tom Lane <tgl@...>
Subject: Re: [INTERFACES] ecpg & 8.3 -> 8.4 migration
To: "Bosco Rama" <postgres@...>
Cc: pgsql-interfaces@..., pgsql-hackers@..., "Michael Meskes" <meskes@...>
Date: Friday, November 20, 2009, 5:02 PM

Bosco Rama <postgres@...> writes:
> According to the PG docs 'server' is a *non-reserved*
> keyword. Does ecpg treat it as a reserved word?

Upon poking around in the ecpg sources, I discover that it has its own
list of "unreserved" keywords and pays no attention whatsoever to the
core grammar's unreserved_keyword list. I can hardly find words to
express my dissatisfaction with that. The unreserved_keyword list might
not be the single most-likely-to-change production in the core grammar,
but it's got to be right up there in the top two or three. This little
shortcut means that all the work done last year to generate the ecpg
grammar from core was practically useless --- we still have to worry
about manually maintaining the ecpg grammar any time we change core.

This has *got* to be fixed. The lack of obvious feedback about keywords
not included in any keyword list means that manual maintenance is
guaranteed to fail, as indeed it's already done, per this report.

regards, tom lane

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

Re: ecpg & 8.3 -> 8.4 migration

2009-11-21T12:18:33Z

On Fri, Nov 20, 2009 at 07:02:11PM -0500, Tom Lane wrote:
> Upon poking around in the ecpg sources, I discover that it has its own
> list of "unreserved" keywords and pays no attention whatsoever to the
> core grammar's unreserved_keyword list. I can hardly find words to
> express my dissatisfaction with that. The unreserved_keyword list might

I cannot agree more. Sorry about that, it seems this one got forgotten. I
wasn't aware of this blunder.

Thanks for fixing it Tom.

Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@...
VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL

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

Re: ecpg & 8.3 -> 8.4 migration

2009-11-20T16:02:11Z

Bosco Rama <postgres@...> writes:
> According to the PG docs 'server' is a *non-reserved*
> keyword. Does ecpg treat it as a reserved word?

Upon poking around in the ecpg sources, I discover that it has its own
list of "unreserved" keywords and pays no attention whatsoever to the
core grammar's unreserved_keyword list. I can hardly find words to
express my dissatisfaction with that. The unreserved_keyword list might
not be the single most-likely-to-change production in the core grammar,
but it's got to be right up there in the top two or three. This little
shortcut means that all the work done last year to generate the ecpg
grammar from core was practically useless --- we still have to worry
about manually maintaining the ecpg grammar any time we change core.

This has *got* to be fixed. The lack of obvious feedback about keywords
not included in any keyword list means that manual maintenance is
guaranteed to fail, as indeed it's already done, per this report.

regards, tom lane

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

ecpg & 8.3 -> 8.4 migration

2009-11-20T12:02:32Z

Howdy folks,

I have an application that works just fine in PG 8.3.
We've installed 8.4 on another machine to perform pre-
migration testing. When we tried to compile our ecpg
stuff under 8.4 the first thing that caught us was an
error stating that the column name 'server' was causing
an error.

According to the PG docs 'server' is a *non-reserved*
keyword. Does ecpg treat it as a reserved word?

TIA

Bosco.

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

Re: Upgrading databases

2009-11-14T14:42:25Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Greg quoting Greg asks:

>> 3. Slony. Setup a slave database, get everything in sync, then
>> switch over to the new database. Very minimal downtime (seconds
>> to minutes). Requires all tables have primary keys.
>>
>> 4. Bucardo. Similar to the steps of Slony above. More forgiving of
>> interruptions in the original replication event.

> I've never done this process myself. I'm wondering how flexible Slony
> and Bucardo are with the versions of Postgres they support.
>
> Does the Slony version run on the new version have to match the Slony
> version on the old one? Do old versions of Slony work on new versions
> of Postgres? Or do you have to update the version of Slony on the old
> database before you can move to a new database version because the new
> database version requires a newer version of Slony?

ObNote: Interfaces is not really the correct mailing list for this, so I'm
cc'ing it over to pgsql-general.

Yes, Slony must be the same. Older versions of Slony will not work against
new versions of Postgres (nor will newer versions of Slony work against
older versions of Postgres).

> I'm even less familiar with Bucardo but have the same questions there too.

Bucardo can connect to any Postgres 8.1 or greater. It may even work against
older versions, but nobody has tested with versions that old that I know of.
The source and target can be different versions of Postgres, no problem.
Unlike Slony, there is only a single master Bucardo daemon that can live
anywhere, even a box that is not the master or slave, as long as it can
talk to both.

- --
Greg Sabino Mullane greg@...
End Point Corporation
PGP Key: 0x14964AC8 200911141738
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkr/MiEACgkQvJuQZxSWSsgGcQCfVCr0jIciY5b9N4OljPn61cMo
BoEAn03wsZ5EDrqZ2WRZIOPsAa/nXsk0
=L94s
-----END PGP SIGNATURE-----

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

Re: Upgrading databases

2009-11-14T11:20:05Z

I didn't actually run Sloany, so their may be some better people to ask.

However, the versions of Sloany depend on different versions of postgres - so if you use the latest version of Postgres, then you'll need the latest version of Sloany. From what I could tell, you run Sloany on your master (which ever database you want to propogate - probably an old database) and it updates/populates the slaves (the new database). So you'll have to get an older version os Sloany to do this. Again, I never ran it so take my advice for what it's worth.

--- On Sat, 11/14/09, Greg Stark <gsstark@...> wrote:

From: Greg Stark <gsstark@...>
Subject: Re: Upgrading databases
To: "Greg Sabino Mullane" <greg@...>
Cc: pgsql-interfaces@..., markmapo@...
Date: Saturday, November 14, 2009, 11:48 AM

On Sat, Nov 14, 2009 at 3:28 PM, Greg Sabino Mullane <greg@...> wrote:
> 3. Slony. Setup a slave database, get everything in sync, then switch over to the
> new database. Very minimal downtime (seconds to minutes). Requires all tables
> have primary keys.
>
> 4. Bucardo. Similar to the steps of Slony above. More forgiving of interruptions
> in the original replication event.

I've never done this process myself. I'm wondering how flexible Slony
and Bucardo are with the versions of Postgres they support.

Does the Slony version run on the new version have to match the Slony
version on the old one? Do old versions of Slony work on new versions
of Postgres? Or do you have to update the version of Slony on the old
database before you can move to a new database version because the new
database version requires a newer version of Slony?

I'm even less familiar with Bucardo but have the same questions there too.

--
greg

Re: Upgrading databases

2009-11-14T10:48:29Z

On Sat, Nov 14, 2009 at 3:28 PM, Greg Sabino Mullane <greg@...> wrote:
> 3. Slony. Setup a slave database, get everything in sync, then switch over to the
> new database. Very minimal downtime (seconds to minutes). Requires all tables
> have primary keys.
>
> 4. Bucardo. Similar to the steps of Slony above. More forgiving of interruptions
> in the original replication event.

I've never done this process myself. I'm wondering how flexible Slony
and Bucardo are with the versions of Postgres they support.

Does the Slony version run on the new version have to match the Slony
version on the old one? Do old versions of Slony work on new versions
of Postgres? Or do you have to update the version of Slony on the old
database before you can move to a new database version because the new
database version requires a newer version of Slony?

I'm even less familiar with Bucardo but have the same questions there too.

--
greg

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

Re: Upgrading databases

2009-11-14T07:28:55Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> I have a 8.2.4 database and I installed 8.3.7 and tried using the
> same /pgsql/data/base directory and got an error about incompatiblity.
...
> Is there a conversion routine to change the files themselves? I know I can dump
> and reload - but that takes large disk space and time. Any other way around?

There are basically four ways to upgrade:

1. Dump and restore. As you mention, it is slow and non-concurrent. Very large
block of client downtime.

2. pg_migrator. Conversion of your current system to the new one. Much faster
than dump and restore, but only works for certain versions and has some minor
caveats. Requires medium client downtime.

3. Slony. Setup a slave database, get everything in sync, then switch over to the
new database. Very minimal downtime (seconds to minutes). Requires all tables
have primary keys.

4. Bucardo. Similar to the steps of Slony above. More forgiving of interruptions
in the original replication event.

- --
Greg Sabino Mullane greg@...
End Point Corporation
PGP Key: 0x14964AC8 200911141026
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkr+zJcACgkQvJuQZxSWSsgd+gCfbqJX/XQ4+tGSHCC7rE6D/Q+j
f/kAoJpdva3ylipMmDF45jIsmqC8TTR+
=ZlaQ
-----END PGP SIGNATURE-----

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

Re: Upgrading databases

2009-11-11T10:58:43Z

Mark Richardson wrote:

> Sorry if this is in the wrong list, but this is the closest I could find...
>
> I have a 8.2.4 database and I installed 8.3.7 and tried using the same
> /pgsql/data/base directory and got an error about incompatiblity.
>
> The database currently has billions of records but it's sparsely populated.
> It took about 4 months to just populate the original database and I REALLY
> don't want to do that again.
>
> Is there a conversion routine to change the files themselves? I know I can
> dump and reload - but that takes large disk space and time. Any other way
> around?

There is no 'in-situ' DB upgrade between major updates from what I can
tell. There is, however, an alternative to the 'dump to disk' approach
which is to pipe the dump from the old DB to the new DB as outlined in
the migration guide here:
<http://www.postgresql.org/docs/8.3/static/migration.html>

HTH.

Bosc.

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

Re: Upgrading databases

2009-11-11T10:51:42Z

On Wednesday 11 November 2009 11:38:31 Mark Richardson wrote:

> Sorry if this is in the wrong list, but this is the closest I could find...
>
> I have a 8.2.4 database and I installed 8.3.7 and tried using the same
> /pgsql/data/base directory and got an error about incompatiblity.
> The database currently has billions of records but it's sparsely
> populated. It took about 4 months to just populate the original database
> and I REALLY don't want to do that again.
> Is there a conversion routine to change the files themselves? I know I can
> dump and reload - but that takes large disk space and time. Any other way
> around?
> Thanks,
> Mark
>

It's common to use SLONY to do this:

1) install 8.3.7 and create a DDL only dump of the 8.2.4 db and install it
into the new 8.3.7 system data dir (so maybe the 8.2 cluster lived in
/var/lib/pgsql/data and the 8.3 cluster lives in /var/lib/pgsql/8.3/data)

2) setup SLONY and replicate all tables and sequences from the 8.2 cluster
into the 8.3 cluster

3) once the db's are completely in sync, remove slony , drop (or at least
shut down) the 8.2 cluster, and move the users to the new cluster.

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

Upgrading databases

2009-11-11T10:38:31Z

Sorry if this is in the wrong list, but this is the closest I could find...

I have a 8.2.4 database and I installed 8.3.7 and tried using the same /pgsql/data/base directory and got an error about incompatiblity.

The database currently has billions of records but it's sparsely populated. It took about 4 months to just populate the original database and I REALLY don't want to do that again.

Is there a conversion routine to change the files themselves? I know I can dump and reload - but that takes large disk space and time. Any other way around?

Thanks,

Mark

Re: Implementing Frontend/Backend Protocol

2009-10-23T02:25:44Z

Hello,

We're investigating again the idea of creating a directly connection
between our app and postgresql, using TCP/IP.

I found some examples in src/interfaces/libpq but they are in C, and
also found interesting the ones from Lisp.

But I can't figure it out almost nothing ...

:-)

So, maybe a practical example would be better:

I can start a connection, but I'm getting an error when I send the
start up sequence.

StartupMessage (F)
Int32
Length of message contents in bytes, including self.

** The total length including the total string => 33

Int32(196608)
The protocol version number. The most signiﬁcant 16 bits are the
major version number (3
for the protocol described here). The least signiﬁcant 16 bits are
the minor version number
(0 for the protocol described here).

** 300

The protocol version number is followed by one or more pairs of
parameter name and value
strings. A zero byte is required as a terminator after the last name/
value pair. Parameters can
appear in any order. user is required, others are optional. Each
parameter is speciﬁed as:
String
The parameter name. Currently recognized names are:
user
The database user name to connect as. Required; there is no default.
database
The database to connect to. Defaults to the user name.
options
Command-line arguments for the backend. (This is deprecated in favor
of setting indi-
vidual run-time parameters.)
In addition to the above, any run-time parameter that can be set at
backend start time might
be listed. Such settings will be applied during backend start (after
parsing the command-line
options if any). The values will act as session defaults.
String
The parameter value.

Ok, I can't see how I have to separate the name/value, maybe with a
slash / ?

And how I have to separate the next name/value ?

I understand that I have to add a byte 0 at the end of the last name/
value but not between them ?

user/postgresdatabase/scann0

this is what I send:

33300user/postgresdatabase/scann0

thanks,

regards,

r.

On 19/04/2007, at 4:03, John DeSoi wrote:

> It takes a bit of work to implement, but it is not too difficult.
> What is your target implementation language?
>
> Here is source library for Lisp:
>
> http://common-lisp.net/project/postmodern/
>
> John
>
>
>
> On Apr 17, 2007, at 5:22 AM, Raimon Fernandez wrote:
>
>> We want to implement, or at least, investigate how difficult will
>> be to talk directly with PostgreSQL via TCP/IP.
>>
>> We have the original documentation, and in chapter 43 there is some
>> info.
>>
>> Do you know where can we find examples (code) to start the project ?
>>
>> We found some but where not related to TCP/IP.
>
>
>
> John DeSoi, Ph.D.
> http://pgedit.com/
> Power Tools for PostgreSQL
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

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

Re: problem on test perlu trigger function.

2009-09-05T10:53:13Z

:-[ I am stupid, it is obvious !

Really you are right :-D , script is thrown with the rights of account postgres and it does not have the rights to browse this directory ...
Your proposal of the "mkdir -p" seems to me the better solution !

Still thank you for this analysis !

However, i have an other problem and I am going to open new thread. And that there seems to me a little more crooked...

Vic :-)

Greg Sabino Mullane a écrit :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

if (! -d  "$PATHBASE/$_TD->{new}{categorie}") {
         `sudo -u http mkdir "$PATHBASE/$_TD->{new}{categorie}"`;
      }

Sudo function is performed in spite of the presence of directory ! It as
if  "-d" serve has nothing...

Anybody knows why?


Because the directory is created and owned by the http user, but is not
visible to the process that runs this function (postgres). One solution
would be to skip the test and call mkdir -p. Another would be to set
the permissions so that the postgres user can see the directories
inside of $PATHBASE.

- --
Greg Sabino Mullane greg@...
End Point Corporation
PGP Key: 0x14964AC8 200909050729
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkqiS88ACgkQvJuQZxSWSshetgCbB3ao2kGembYXswSu7fQ77NFH
4lEAoMfBRsbbNMg4g8wSgIJ6iE+mhFHC
=esTM
-----END PGP SIGNATURE-----

Re: problem on test perlu trigger function.

2009-09-05T04:30:27Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> if (! -d "$PATHBASE/$_TD->{new}{categorie}") {
> `sudo -u http mkdir "$PATHBASE/$_TD->{new}{categorie}"`;
> }

> Sudo function is performed in spite of the presence of directory ! It as
> if "-d" serve has nothing...
>
> Anybody knows why?

Because the directory is created and owned by the http user, but is not
visible to the process that runs this function (postgres). One solution
would be to skip the test and call mkdir -p. Another would be to set
the permissions so that the postgres user can see the directories
inside of $PATHBASE.

- --
Greg Sabino Mullane greg@...
End Point Corporation
PGP Key: 0x14964AC8 200909050729
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkqiS88ACgkQvJuQZxSWSshetgCbB3ao2kGembYXswSu7fQ77NFH
4lEAoMfBRsbbNMg4g8wSgIJ6iE+mhFHC
=esTM
-----END PGP SIGNATURE-----

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

problem on test perlu trigger function.

2009-09-04T22:18:13Z

Hello,

I have a problem on a test directory on my trigger function.
For information, i use a 8.0.21 version of perl.

To make things simple, i make a perlu function trigger on when i modify
a row, i try to test the existence of a directory. I have the impression
that this test
does not work :-(

my function...

..
if (! -d "$PATHBASE/$_TD->{new}{categorie}") {
`sudo -u http mkdir "$PATHBASE/$_TD->{new}{categorie}"`;
}
...

Sudo function is performed in spite of the presence of directory ! It as
if "-d" serve has nothing...

Anybody knows why?

Vic

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

Re: SERIOUS BUG IN DBD::Pg 2.14.0 for bigint types

2009-07-28T10:06:49Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> You can't store a large 8 byte int value into an 8 byte floating point
> value without loss of precision. (See appended explanation.)
...
>
> Here's a fix:

Thank you very much, Tim. 2.14.1 with the fix has been uploaded to CPAN.

- --
Greg Sabino Mullane greg@...
End Point Corporation
PGP Key: 0x14964AC8 200907281306
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkpvMBUACgkQvJuQZxSWSsgQQACfTvQKFdgZWP1vJ2K+yupMx7zs
zHsAn1lxySXKXpn7UfzNUbz6C4NyAndT
=BR3f
-----END PGP SIGNATURE-----

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

SERIOUS BUG IN DBD::Pg 2.14.0 for bigint types

2009-07-28T09:53:05Z

On Tue, Jul 28, 2009 at 02:44:55AM -0000, Greg Sabino Mullane wrote:
>
> Version 2.14.0 of DBD::Pg has been released and is available on CPAN.
>
> 2.14.0 Released July 27, 2009 (subversion r13130)
>
> - Return ints and bools-cast-to-number from the db as true Perlish numbers.
> (CPAN bug #47619) [GSM]

The code now stores bigint values (8 bytes long) in a floating point
variable (NV). Most perl's are configured with the NV type being a
simple C 'double' which is typically 8 bytes:

$ perl -V:'^nv(size|type)'
nvsize='8';
nvtype='double';

You can't store a large 8 byte int value into an 8 byte floating point
value without loss of precision. (See appended explanation.)

To be completely clear about this:

DBD::Pg 2.14.0 may *SILENTLY ALTER LARGE BIGINT VALUES*

Here's a fix:

--- dbdimp.c.orig 2009-07-28 09:46:21.000000000 -0700
+++ dbdimp.c 2009-07-28 09:46:35.000000000 -0700
@@ -3381,9 +3381,6 @@
case PG_INT2:
sv_setiv(sv, atol((char *)value));
break;
- case PG_INT8:
- sv_setnv(sv, atoll((char *)value));
- break;
default:
sv_setpvn(sv, (char *)value, value_len);
}

Tim.

=head3 Perl Floating Point Values

Technically the term "floating point" refers to a number representation
consisting of a I<mantissa>, C<M>, and an I<exponent>, C<E>. The number
represented is the value of C<M ** E>. But what does that mean?

Basically, a floating point value is represented internally by two
values. One value, the mantissa, holds a binary I<approximation> of the
significant digits and another value, the exponent, is used to indicate
where the decimal point should be. It may be within the significant
digits but it may also be way off to the right (positive mantissa) or
left (negative mantissa).

Floating point values are typically stored in 64 bits or sometimes 96
bits (that's 8, or 12 bytes) depending on how your perl was configured.
You can check the size used in your perl by running C<perl -V> and
looking for C<nvsize=> in the output. The 64 bit floats are known as
I<doubles> and have approximately 15 digits of precision between 1e-307
to 1e+308, and the 96 bit floats are known as I<long doubles> and have
approximately 18 digits of precision between 1e-4931 to 1e+4932. Some
systems support 128 bit I<quad doubles> with even greater precision and
scale.

It's becoming more common for perl to be configured with 64 bit
integers but still using 64 bit floating point values. But a 64 bit
integer has 19 digits of precision whereas a 64 bit floating point
value only has approximately 18. This is important to know because it
means that a large integer may loose precision if it's involved in a
calculation that causes it to be converted to a floating point value
(which is basically anything more involved that addition or subtraction
of another integer).

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

Re: Linker Confusion.....

2009-07-23T14:39:39Z

Ralf Hasemann <rhasemann@...> writes:
> How does the linker know to link against libpq.5.dylib when libpq.a is
> the only lib in my project?

You'd be best advised to ask that on an OSX development list; it's not
particularly a Postgres question, but a question of the behavior of the
development tools on that platform.

Mind you, the above behavior is probably *good*, and I don't recommend
you try to override it. Statically linked libraries are a real pain
in the neck when it comes time for a software update. But exactly how
the toolchain you're using finds the dynamic library, I don't know.

regards, tom lane

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

Linker Confusion.....

2009-07-23T13:19:22Z

Hello,

I am wirting an application that uses the libpq interface to access
the PostgreSQL database. My system is Mac OS X.

I have set up my project in Xcode and everything works fine. DB access
is flawless and very fast. But I often like to dig deeper into things
to get knowledge on how things work. What confuses me is, when I use
otool to inspect my executable, I get the information that my app is
linked against libpq.5.dylib (which is a symlink to libpq.5.1.dylib),
which is probably the dynamic library that does the work in
communicating with the database server.
But what I don't understand: In my Xcode project, I have put libpq.a
(and not libpq.5.dylib!) into the linked frameworks of my project and
the project is build against it.
How does the linker know to link against libpq.5.dylib when libpq.a is
the only lib in my project?

I hope my problem description is not too confusing....

Thank you for any answer and thank you to the PostgreSQL team for the
great database! ;-)

Best regards,
Ralf

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

Linker Confusion.....

2009-07-23T12:47:06Z

Re: Type OIDs

2009-06-07T03:22:32Z

* Tom Lane:

> Florian Weimer <fw@...> writes:
>> By the way, the binary encoding would be pretty useful for BYTEA
>> columns and parameters, but it's a pretty hefty burden for almost
>> anything else. Wouldn't it make sense to add a format flag which
>> basically says "binary if it's BYTEA, otherwise text"?
>
> What is "easy" is very much in the eye of the beholder --- I would think
> for instance that a lot of people would consider integer columns to be
> easy enough to deal with in binary format. ntohl() isn't much of a
> burden.

The documentation is silent on alignment, so I would have thought that
a memcpy() is needed, too.

> As far as output goes, I seem to recall some discussion awhile back of a
> format value that would mean "send <some list of types> in binary" where
> the specific list could be set by the client. This would seem to me to
> be a lot more useful and less klugy than hard-wiring bytea as a special
> case.

Yes, but it would be more difficult to implement, wouldn't it? (Of
course, it's better to implement the full-blown version from the
beginning if it is implemented ever.)

> On the input side it's much more questionable since (as you noted)
> clients don't always have a solid grasp on which parameters are
> which types.

The input side is actually *much* *more* problematic because right
now, I've got this string, and I pass it to PostgreSQL, and depending
on the query, I've got to BYTEA-encode it or not. There is no way to
figure out if this is necessary for a particular parameter. If I
specify a BYTEA type for all string columns, I break type enference
(there's no conversion or cast for BYTEA to INTEGER, for instance).

As a result, if you use BYTEA columns from one of the scripting
languages, you end up with manually specificing BYTEA types. I hate
that, and people forget it and complain when things break.

In contrast, for the output side, I can look at the column type and
decode the value if it's BYTEA. It's just an efficiency issue. The
API itself isn't problematic.

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

Re: Type OIDs

2009-06-06T08:15:02Z

Florian Weimer <fw@...> writes:
> By the way, the binary encoding would be pretty useful for BYTEA
> columns and parameters, but it's a pretty hefty burden for almost
> anything else. Wouldn't it make sense to add a format flag which
> basically says "binary if it's BYTEA, otherwise text"?

What is "easy" is very much in the eye of the beholder --- I would think
for instance that a lot of people would consider integer columns to be
easy enough to deal with in binary format. ntohl() isn't much of a
burden.

As far as output goes, I seem to recall some discussion awhile back of a
format value that would mean "send <some list of types> in binary" where
the specific list could be set by the client. This would seem to me to
be a lot more useful and less klugy than hard-wiring bytea as a special
case. On the input side it's much more questionable since (as you
noted) clients don't always have a solid grasp on which parameters
are which types.

regards, tom lane

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

Re: Type OIDs

2009-06-06T03:32:07Z

* Tom Lane:

> Florian Weimer <fw@...> writes:
>> Can I embed the types I'm interested in into my program, or should I
>> query the server at least once per connection to get the mapping? I'm
>> interested in types such as INTEGER, TEXT, BYTEA, etc. No user
>> defined types, and nothing fancy. Ultra-long-term portability isn't
>> required, either.
>
> Well, the type OIDs of the standard built-in types haven't changed in
> at least ten years, but that doesn't mean we won't change 'em in the
> future. I'd advise at least using the #define's from pg_type.h rather
> than writing actual numeric constants.

Okay, will do that. Thanks.

By the way, the binary encoding would be pretty useful for BYTEA
columns and parameters, but it's a pretty hefty burden for almost
anything else. Wouldn't it make sense to add a format flag which
basically says "binary if it's BYTEA, otherwise text"? I don't think
many host languages make a strong distinction between BYTEA and TEXT
types (except those which use UTF-16 and expose that to the user, like
Java and C#). As a result, it is difficult to specify the right types
when talking to the server. You don't want to label a column as BYTEA
overeagerly because it will break type inference on the SQL side (I
think).

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

Re: Type OIDs

2009-06-03T18:18:22Z

Tom Lane wrote:

I'll second that. It's exactly what I've been doing in PL/R for several
years now.

Joe

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

Re: Type OIDs

2009-06-03T12:26:28Z

Florian Weimer <fw@...> writes:
> Can I embed the types I'm interested in into my program, or should I
> query the server at least once per connection to get the mapping? I'm
> interested in types such as INTEGER, TEXT, BYTEA, etc. No user
> defined types, and nothing fancy. Ultra-long-term portability isn't
> required, either.

Well, the type OIDs of the standard built-in types haven't changed in
at least ten years, but that doesn't mean we won't change 'em in the
future. I'd advise at least using the #define's from pg_type.h rather
than writing actual numeric constants.

regards, tom lane

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

Type OIDs

2009-06-03T11:45:16Z

I'd like to use type information in a query result to convert its
elements to more appropriate types if necessary.

Can I embed the types I'm interested in into my program, or should I
query the server at least once per connection to get the mapping? I'm
interested in types such as INTEGER, TEXT, BYTEA, etc. No user
defined types, and nothing fancy. Ultra-long-term portability isn't
required, either.

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

Keep alive in libpq

2009-05-27T03:03:55Z

Hello, pgsql-interfaces.

I found solution how to implement keep alive through sockets in
archive: http://archives.postgresql.org/pgsql-interfaces/2006-11/msg00014.php

However, it is dated 2006 year and I am wonder if this is for real? At
least in Windows environment?

If not are there any solutions?

--
With best wishes,
Pavel mailto:pavel@...

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

Re: Timestamp with libpq

2009-05-20T14:53:03Z

Hi Jakob,
can you post your code?
I've wrote my own binary timestamp functions (available here), but looking forward to adapt my code to doubles also.

Jakob Lechner-4 wrote:

>
> I doubt this. It might be true for double storage but not for 8 byte integers,
> well that is in the database of course. But I see no reason whatsoever that the
> data is truncated by libpq.
>

I found an easy solution for my problem: Libpq provides information if
the timestamps are double values or integer values.

When passing the parameter "integer_datetimes" to the function "PQparameterStatus"
"on" or "off" is returned.

I adapted my conversion routine to handle both integer and double
timestamps. Everything works fine now.

Best regards
Jakob

INTERVAL data type and libpq - what format?

2009-05-19T01:12:20Z

Hello,

I try to use the new 8.4 INTERVAL type with libpq, but get crazy with
the input formatting rules...

I use PQprepare() / PQexecPrepared() with parameter list, binding the
INTERVAL values with the 1186 pg_type and passing a string buffer with
values like:

"12345" for an INTERVAL YEAR

The INSERT works without error, but when selecting rows from the table
in psql, I get "00:00:00" values ?!?!

When inserting the value "12345" from the psql command tool it works...

I must be doing something wrong, but I could not find any documentation
on using INTERVAL in libpq...

Can someone from the hackers just tell me if it's supposed to work and
if yes what format is expected by the client library?

Attached, you have a test case to reproduce the problem.

Thanks a lot!
Seb

/*
Version: 8.4.beta1
Created by: sf@...

Problem with INTERVAL input format
----------------------------------

After executing this program, 2 rows are present in the table.
Only the first has the expected values...

Why does the second insert fail to insert "123 11" in INTERVAL DAY TO HOUR?
Diagnostic info:
SQL State: 22007
Message : invalid input syntax for type interval: " 123 11"

Why does the third row show "00:00:00" in first INTERVAL YEAR column?

[sf@fox problems]$ psql test1 -U pgsuser
psql (8.4beta1)
Type "help" for help.

test1=> select * from t1;
k | i1 | i2
---+--------------+-------------------
1 | -12345 years | 123 days 11:00:00
3 | 00:00:00 | 123 days 11:00:00
(2 rows)

When inserting rows with psql, the format used by the C program are supported:

test1=> insert into t1 values ( 4, '-12345', '123 11' );
INSERT 0 1
test1=> select * from t1 where k=4;
k | i1 | i2
---+--------------+-------------------
4 | -12345 years | 123 days 11:00:00
(1 row)

So what am I doing wrong here?

*/

#include <stdio.h>
#include <libpq-fe.h>

static int checkResult(PGresult * r)
{
if (r == NULL)
return 0;
switch (PQresultStatus(r)) {
case PGRES_COMMAND_OK:
case PGRES_TUPLES_OK:
return 1;
default:
return 0;
}
}

static void getErrorInfo(PGresult * r)
{
if (r == NULL)
return;
fprintf(stderr, "Diagnostic info:\n");
fprintf(stderr, " SQL State: %s\n", PQresultErrorField(r, PG_DIAG_SQLSTATE));
fprintf(stderr, " Message : %s\n", PQresultErrorField(r, PG_DIAG_MESSAGE_PRIMARY));
}

int main(int argc, char **argv)
{
PGresult *r;
PGconn *c;
Oid paramTypes[10];
const char *paramValues[10];

fprintf(stdout,"++ Connecting...\n");
c = PQconnectdb("dbname='test1' user='pgsuser' password='fourjs'");
if (c == NULL) {
fprintf(stderr,">> Could not connect.\n");
exit(1);
}

fprintf(stdout,"++ Creating table t1 ...\n");
r = PQexec(c, "DROP TABLE t1");
PQclear(r);
r = PQexec(c, "CREATE TABLE t1 ( k INT, i1 INTERVAL YEAR, i2 INTERVAL DAY TO HOUR)");
if (!checkResult(r)) {
fprintf(stderr,">> Could not create table 1.\n");
getErrorInfo(r);
exit(1);
}
PQclear(r);

fprintf(stdout,"++ Preparing INSERT ...\n");
paramTypes[0] = 23; /* INT4 */
paramTypes[1] = 1186; /* INTERVAL */
paramTypes[2] = 1186; /* INTERVAL */
r = PQprepare(c, "s1",
"INSERT INTO t1 VALUES ( $1, $2, $3 )",
3, (const Oid *) paramTypes);
if (!checkResult(r)) {
fprintf(stderr,">> Could not prepare stmt 1.\n");
getErrorInfo(r);
exit(1);
}
PQclear(r);

/* This is working */
fprintf(stdout,"++ Executing INSERT (1) ...\n");
paramValues[0] = "1";
paramValues[1] = "-12345 years";
paramValues[2] = " 123 11:00";
r = PQexecPrepared(c, "s1", 3, paramValues, NULL, NULL, 0);
if (!checkResult(r)) {
fprintf(stderr,">> Could not exec stmt 1.\n");
getErrorInfo(r);
exit(1);
}
PQclear(r);

/* This is NOT working */
fprintf(stdout,"++ Executing INSERT (2) ...\n");
paramValues[0] = "2";
paramValues[1] = "-12345";
paramValues[2] = " 123 11";
r = PQexecPrepared(c, "s1", 3, paramValues, NULL, NULL, 0);
if (!checkResult(r)) {
fprintf(stderr,">> Could not exec stmt 2.\n");
getErrorInfo(r);
/*exit(1);*/
}
PQclear(r);

/* This is NOT working */
fprintf(stdout,"++ Executing INSERT (3) ...\n");
paramValues[0] = "3";
paramValues[1] = "-12345";
paramValues[2] = " 123 11:00";
r = PQexecPrepared(c, "s1", 3, paramValues, NULL, NULL, 0);
if (!checkResult(r)) {
fprintf(stderr,">> Could not exec stmt 3.\n");
getErrorInfo(r);
exit(1);
}
PQclear(r);

PQfinish(c);
}

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

DBD::Pg 2.13.1 has been released

2009-04-24T12:12:38Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Version 2.13.1 of DBD::Pg has just been released. You can find it at:

http://search.cpan.org/dist/DBD-Pg/

2.13.1 addressed a minor leak in pg_warn.

2.13.0 applied better SQLSTATE codes

2.12.0 changed the large object interface to use pg_lo_* (instead of the improper lo_* method),
and fixed a handful of other minor problems.

A list of all changes can be found at:

http://cpansearch.perl.org/src/TURNSTEP/DBD-Pg-2.13.1/Changes

The checksums for the new tarball are:

4e16c70109146d18a11a5170d30b305a DBD-Pg-2.13.1.tar.gz
ef115d2e20153803f2c3abe4671dbbb43e2f9762 DBD-Pg-2.13.1.tar.gz

- --
Greg Sabino Mullane greg@...
End Point Corporation
PGP Key: 0x14964AC8 200904241511
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAknyDuEACgkQvJuQZxSWSsiw1QCgjwmwlVxvYiCMNyBrY8cXM7GQ
2N4AnR2s5kzxGb9Y17uAa2OPUvO99E/m
=j4rF
-----END PGP SIGNATURE-----

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

Re: this mailing list is proposed to be retired

2009-03-25T18:23:06Z

Thomas Adam <thomas.adam22@...> writes:
> I find it amusing that "low traffic" implies some level of
> irrelevancy. What a load of tosh. This list has a purpose, it
> *serves* that purpose, and does so well.

Not counting this thread itself, since January 1 this list has had
22 posts, all but five of which were demonstrably off-topic (assuming
that that Javascript thread in January should have been on pgsql-jdbc).
Of the five, three were a single thread about ECPG, and the other two
were questions that went unanswered. So in other words, there's been
*one* effective, on-topic exchange in three months here, and a much
larger volume of stuff that should have gone somewhere else.

The list looks pretty moribund to me :-(.

regards, tom lane

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

Re: this mailing list is proposed to be retired

2009-03-25T17:47:48Z

2009/3/25 Alvaro Herrera <alvherre@...>:

> Peter Eisentraut wrote:
>> Some PostgreSQL mailing lists, including the one you are reading now, are
>> proposed to be retired, because they receive very little or mostly off-topic
>> traffic.
>
>> * pgsql-interfaces
>>
>> Many PostgreSQL interfaces have their own mailing lists. Posts that don't fit
>> anywhere else could go to pgsql-general.
>
> We consider that enough time for objections has passed with no
> objections being raised, so this list is going to be deleted Real Soon
> Now. You Have Been Warned.

I find it amusing that "low traffic" implies some level of
irrelevancy. What a load of tosh. This list has a purpose, it
*serves* that purpose, and does so well. By removing this and
consolidating it with another similarly-related one, you're just going
to contaminate that other list.

-- Thomas Adam

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

Re: this mailing list is proposed to be retired

2009-03-25T16:32:22Z

> Peter Eisentraut wrote:
>> Some PostgreSQL mailing lists, including the one you are reading
>> now, are
>> proposed to be retired, because they receive very little or mostly
>> off-topic
>> traffic.
>
>> * pgsql-interfaces
>>
>> Many PostgreSQL interfaces have their own mailing lists. Posts
>> that don't fit
>> anywhere else could go to pgsql-general.
>
> We consider that enough time for objections has passed with no
> objections being raised, so this list is going to be deleted Real Soon
> Now. You Have Been Warned.

I'm pretty sure I posted when you first proposed killing this list - I
find it both useful and on-topic, and the alternatives less so. I'll
be disappointed if you kill it.

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

Re: this mailing list is proposed to be retired

2009-03-25T14:50:34Z

Peter Eisentraut wrote:
> Some PostgreSQL mailing lists, including the one you are reading now, are
> proposed to be retired, because they receive very little or mostly off-topic
> traffic.

> * pgsql-interfaces
>
> Many PostgreSQL interfaces have their own mailing lists. Posts that don't fit
> anywhere else could go to pgsql-general.

We consider that enough time for objections has passed with no
objections being raised, so this list is going to be deleted Real Soon
Now. You Have Been Warned.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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