I'm trying to read "money" field using PQgetvalue (PostgreSQL 8.3.7). The
function returns 9 bytes, smth like 0h 0h 0h 0h 0h 0h 14h 0h 0h, for the
Huh... You mean 8 bytes, right?
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-general mail
rr.param = param = PQparamCreate(conn);
PQputf(arr.param, "%int4 %int4 %int4 %int4", 3, 5, 6, 8);
res = PQexecf(conn,
"select name from foo where id in (%int4[])", &arr);
PQparamClear(arr.param);
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent
Pavel Stehule wrote:
On 14/12/2007, Andrew Chernow <[EMAIL PROTECTED]> wrote:
Ran across something that is confusing me. The docs for to_char
indicates that julian day 0 is January 1, 4712 BC at midnight.
http://www.postgresql.org/docs/8.3/static/functions-formatting.html
When I run t
Ran across something that is confusing me. The docs for to_char
indicates that julian day 0 is January 1, 4712 BC at midnight.
http://www.postgresql.org/docs/8.3/static/functions-formatting.html
When I run to_char, I don't get 0 for that date.
postgres=# select to_char('4712-01-01 BC'::date,
Merlin Moncure wrote:
On Dec 12, 2007 2:14 AM, Samantha Atkins <[EMAIL PROTECTED]> wrote:
This brings up a second question. How should I do byte order
conversion for 8 byte ints? I can't use hton ntoh routines as they
max out at 32 bits. Is there a better way? Also, are floating point
number
Merlin Moncure wrote:
On Dec 12, 2007 2:14 AM, Samantha Atkins <[EMAIL PROTECTED]> wrote:
This brings up a second question. How should I do byte order
conversion for 8 byte ints? I can't use hton ntoh routines as they
max out at 32 bits. Is there a better way? Also, are floating point
number
2007/1/5, Jorge Godoy <[EMAIL PROTECTED]>:
Andrew Chernow <[EMAIL PROTECTED]> writes:
> meet those requirements. It is far more effecient to have apache
access
> them
Where weren't we meeting his/her requirements? All the discussion is
around
available means to do that.
bly smarter than me :)
andrew
Jorge Godoy wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Or am
I the only one that is thinking about referential integrity with those files?
Not at all. I'm not sure how 3rd party tools like apache, `ls`, `gzip`,
`find`, nfs, etc... are brea
r (local or remote).
How is this any different than db replication. It would have to backup the same
amount of information? You would require the same horse power and bandwidth.
andrew
Jorge Godoy wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
And how do you guarantee that after a
unlink the old
version.
andrew
Ragnar wrote:
On fös, 2007-01-05 at 15:49 -0500, Andrew Chernow wrote:
I 100% agree. Use the database as a lookup into the filesystem. Don't load the
database up with terabytes of non-searchable binary data? not sure how that
would help you?
>I
>> Or am
>>I the only one that is thinking about referential integrity with those files?
Not at all. I'm not sure how 3rd party tools like apache, `ls`, `gzip`, `find`,
nfs, etc... are breaking integrity. Any php, jsp, C or shell script you write
would be doing the same thing, accessing the da
andrew
Jorge Godoy wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
I mean, how do you handle integrity with data
outside the database?
You don't, the file system handles integrity of the stored data. Although,
one must careful to avoid db and fs orphans. Meaning, a record with
>> Don't store your images in the database. Store them on the filesystem and
>> store their path in the database
I 100% agree. Use the database as a lookup into the filesystem. Don't load the
database up with terabytes of non-searchable binary data? not sure how that
would help you?
Here i
)
4. PHP, HTML, JavaScript (2+ years)
5. BASH, sed, awk, grep, etc... (PERL a plus)
6. Genral knowledge of other databases a plus (Oracle, MySQL, MSSQL, DB2)
7. Creativity and Innovation
8. Socket programming a plus
--
Andrew Chernow
Chief Technology Officer
eSilo, LLC.
1530 Cypress Drive, Suite
14 matches
Mail list logo
