Re: [GENERAL] more custom C function fun

On Mon, May 05, 2008 at 11:43:40PM -0600, Dan Heron Myers wrote: > I have a custom C function that takes two text*s and returns a text*. > > text* calling_party = PG_GETARG_TEXT_P(0); > > char* thestr = VARDATA(calling_party); > if(thestr[20] == ')') >

Re: [GENERAL] operator is not unique: integer || integer

another example?: RAISE NOTICE "error during validation % :", 'ks:"'||ks||'"@"'|| loopdate||'"'; (here LoopDate is a DateTime) Ehm... What's wrong with RAISE NOTICE "error during validation ks:"%"@"%" :', ks, loopdate; ? (I don't quite understand the purpose of that colon at the end, btw)

Re: [GENERAL] more custom C function fun

Harvey, Allan AC wrote: Try if(thestr[20] == 0x29) might reveal something in the parsing if it works. No effect. - Dan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] more custom C function fun

I have a custom C function that takes two text*s and returns a text*. My problem is with this code: PG_FUNCTION_INFO_V1(get_agent); PGMODULEEXPORT Datum get_agent(PG_FUNCTION_ARGS) { if(!PG_ARGISNULL(0)) { text* calling_party = PG_GETARG_TEXT_P(0);

Re: [GENERAL] checkpoint_segments warning?

Dan Armbrust escribió: I got a warning from PostgreSQL 8.3.1 that said something to the effect of checkpoints are happening to frequently... (-2484 seconds) That part that confused me was the "-2484". Is that just a hyphen in a strange place? Or did it really calculate a negative value? Is t

Re: [GENERAL] Custom C function - is palloc broken?

Tom Lane wrote: Craig Ringer <[EMAIL PROTECTED]> writes: The other thing I had to do was add include guards on pg_config_os.h to protect against repeat inclusion. VC++ 8.0 does not like the repeated definition of `struct timezone' and `struct itimerval' (but 9.0 - correctly - doesn't care). I

Re: [GENERAL] Custom C function - is palloc broken?

Dan "Heron" Myers wrote: Tom Lane wrote: > You need to > get over this concept of "Postgres is broken" and try to identify a > specific reason why your DLL builds are not working. I don't think I ever said Postgres was broken. I said Postgres was crashing. I expressed doubt that Postgres'

Re: [GENERAL] Custom C function - is palloc broken?

Craig Ringer wrote: And in the server log files (PG_INSTALL_DIR\data\pg_log) ? The log files contained no indication of an error, not even an "oops, the server crashed" message. I'd be interested in confirmation that you're able to get your code working when you build it with VC++ . I did

Re: [GENERAL] Custom C function - is palloc broken?

Craig Ringer <[EMAIL PROTECTED]> writes: > The other thing I had to do was add include guards on pg_config_os.h to > protect against repeat inclusion. VC++ 8.0 does not like the repeated > definition of `struct timezone' and `struct itimerval' (but 9.0 - > correctly - doesn't care). I have no id

Re: [GENERAL] Custom C function - is palloc broken?

"Dan \"Heron\" Myers" <[EMAIL PROTECTED]> writes: > It seems odd that they can compile PostgreSQL with Visual Studio (according > to Magnus, anyway) And according to several buildfarm machines, as well as quite a few other folks who have managed to build things successfully. You need to get over

Re: [GENERAL] Custom C function - is palloc broken?

Dan "Heron" Myers wrote: Craig Ringer wrote: I'm actually using a dummy header (just an empty file) for libintl.h . None of the involved module code actually uses anything from libintl, neither directly nor via any inlines/macros from postgresql's headers. I'm not even sure PostgreSQL needs to

Re: [GENERAL] Custom C function - is palloc broken?

Craig Ringer wrote: I'm actually using a dummy header (just an empty file) for libintl.h . None of the involved module code actually uses anything from libintl, neither directly nor via any inlines/macros from postgresql's headers. I'm not even sure PostgreSQL needs to include the header in its

Re: [GENERAL] Custom C function - is palloc broken?

Dan "Heron" Myers wrote: Craig Ringer wrote: I've tested this definition and it produces a DLL that links correctly and does so without the warnings of inconsistent DLL linkage produced by the original versions (which declared the function __declspec(dllimport) then defined it). Did you actu

Re: [GENERAL] Custom C function - is palloc broken?

Craig Ringer wrote: Which compiler did you use? I've been using MinGW because I don't know how to turn off NLS to compile with VC++. - Dan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-gene

Re: [GENERAL] operator is not unique: integer || integer

Daniel Schuchardt wrote: Tino Wildenhain schrieb: RETURN extract(year FROM $1)*100+extract(month FROM $1)-1; was too clean and easy? ;)) Looks like a good oportunity to clean up your code before anything unexpected happens :-) Cheers T. LOL. Yes I don't like such easy things :-P > RAISE

Re: [GENERAL] Custom C function - is palloc broken?

Craig Ringer wrote: I've tested this definition and it produces a DLL that links correctly and does so without the warnings of inconsistent DLL linkage produced by the original versions (which declared the function __declspec(dllimport) then defined it). Did you actually try to use those func

Re: [GENERAL] checkpoint_segments warning?

> > That part that confused me was the "-2484". Is that just a hyphen in > > a strange place? Or did it really calculate a negative value? > > Yeah, it really did. AFAICS this could only happen if the value of time(2) > went backwards. Something fooling with your system clock? > >

Re: [GENERAL] operator varchar = integer

Tom Lane schrieb: David Fetter <[EMAIL PROTECTED]> writes: On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote: our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views that all use implicit casting. and: everything is working fine ;-) :-P How do

Re: [GENERAL] COPY Performance

> > > > We're using a statement like this to dump between 500K and >5 > > > > million rows. > > > > > > > > COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn > '0') > > > > TO '/dev/shm/SomeFile.csv' > > > > > > > > Upon first run, this operation can take several minutes. Upon > > > > second ru

Re: [GENERAL] psycopg2 and prepared statements

On Monday 05 May 2008 14:28:47 Micah Yoder wrote: > Just started a nice new project in mod_python with psycopg2, then > discovered that psycopg2 apparently does not support prepared statements. >  Is that true? Any workarounds? Ah wait, do prepared statements not need any support from the client l

Re: [GENERAL] checkpoint_segments warning?

"Dan Armbrust" <[EMAIL PROTECTED]> writes: > I got a warning from PostgreSQL 8.3.1 that said something to the effect of > checkpoints are happening to frequently... (-2484 seconds) > That part that confused me was the "-2484". Is that just a hyphen in > a strange place? Or did it really calculat

Re: [GENERAL] operator is not unique: integer || integer

Tino Wildenhain schrieb: RETURN extract(year FROM $1)*100+extract(month FROM $1)-1; was too clean and easy? ;)) Looks like a good oportunity to clean up your code before anything unexpected happens :-) Cheers T. LOL. Yes I don't like such easy things :-P But you see i have a function so

Re: [GENERAL] bytea and character encoding when inserting escaped literals

Lee Feigenbaum <[EMAIL PROTECTED]> writes: > Would be nice if the bytea parser understood hex representation too, but > beggars can't be choosers :) decode() might help you: select decode('1200AB', 'hex'); decode -- \022\000\253 (1 row) regards, tom

[GENERAL] checkpoint_segments warning?

I got a warning from PostgreSQL 8.3.1 that said something to the effect of checkpoints are happening to frequently... (-2484 seconds) That part that confused me was the "-2484". Is that just a hyphen in a strange place? Or did it really calculate a negative value? Is this expected? Thanks, D

[GENERAL] psycopg2 and prepared statements

Just started a nice new project in mod_python with psycopg2, then discovered that psycopg2 apparently does not support prepared statements. Is that true? Any workarounds? That ruins my whole day ... -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your

Re: [GENERAL] operator is not unique: integer || integer

Daniel Schuchardt wrote: Tino Wildenhain schrieb: Hi, Daniel Schuchardt wrote: ... in 81: postgres=# SELECT 1::INTEGER||1::INTEGER; ?column? -- 11 (1 row) *shudder* is this actually a port of an application originally targeted at M*Sql? ;) Are you using those columns somewhere with

Re: [GENERAL] operator is not unique: integer || integer

Tino Wildenhain schrieb: Hi, Daniel Schuchardt wrote: ... in 81: postgres=# SELECT 1::INTEGER||1::INTEGER; ?column? -- 11 (1 row) *shudder* is this actually a port of an application originally targeted at M*Sql? ;) Are you using those columns somewhere with their real type - as inte

Re: [GENERAL] operator is not unique: integer || integer

Hi, Daniel Schuchardt wrote: ... in 81: postgres=# SELECT 1::INTEGER||1::INTEGER; ?column? -- 11 (1 row) *shudder* is this actually a port of an application originally targeted at M*Sql? ;) Are you using those columns somewhere with their real type - as integer? I mean if you use the

Re: [GENERAL] operator varchar = integer

Hi, Daniel Schuchardt wrote: Tino Wildenhain schrieb: Hi, ... Comparing int with text in general does not sound like a very good idea to me. It should be quite easy to write a script to identify such places so you can either change the datatypes (preferred) or add the cast. Then rerun your a

[GENERAL] Re: [GENERAL] close database, nomount state

paul rivers <[EMAIL PROTECTED]> wrote: Short answer-- no. Longer answer-- there's really no need for the Oracle-esque nomount state in Pg. If you're doing media recovery, it's very much all or nothing, cluster-wide. You are not going to do media recovery for a set of tablespaces, for example

Re: [GENERAL] bytea and character encoding when inserting escaped literals

Asche wrote: Hi Lee, Thanks for the suggestion. I should have mentioned in my original message that as per your suggestion and the suggestion in the documentation, I have tried escaping the backslashes. When I do this, I get the error: ERROR: invalid input syntax for type bytea I tried al

Re: [GENERAL] operator varchar = integer

David Fetter <[EMAIL PROTECTED]> writes: > On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote: >> our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views >> that all use implicit casting. and: everything is working fine ;-) >> :-P > How do you know? 8.3 removed the im

Re: [GENERAL] operator varchar = integer

Tino Wildenhain schrieb: Hi, Daniel Schuchardt wrote: David Fetter schrieb: That technical debt is a risk to your whole project, and you need to dedicate resources to paying it down. There are ways to get those automated casts, but they will only

[GENERAL] operator is not unique: integer || integer

yeah, its clear that an upgrade from 8.1 to 8.3 is impossible for us without a major relase. there are to many changes so the whole project has to be rechecked. another example: in 83: postgres=# SELECT 1::INTEGER||1::INTEGER; ERROR: operator does not exist: integer || integer at character 18

Re: [GENERAL] operator varchar = integer

No buts. If you create those automated casts, you are just putting off the inevitable. yes but than it will become a future project. (i think with postgres 8,5 or 8,6 :-P ) You're just confirming the fact that your project is in existential trouble. no, we would get trouble if we upg

Re: [GENERAL] bytea and character encoding when inserting escaped literals

I'm thinking that the answer is in the literal interpretation of the error message, i.e. it doesn't like the specific byte 0x00, i.e. the null byte. According to the docs (4.1.2.1. String Constants): "The character with the code zero cannot be in a string constant." The reason may be that th

Re: [GENERAL] operator varchar = integer

On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote: > David Fetter schrieb: >> That technical debt is a risk to your whole project, and you need >> to dedicate resources to paying it down. >> >> >> >> There are ways to get those automated

Re: [GENERAL] operator varchar = integer

Hi, Daniel Schuchardt wrote: David Fetter schrieb: That technical debt is a risk to your whole project, and you need to dedicate resources to paying it down. There are ways to get those automated casts, but they will only make your situation worse

Re: [GENERAL] bytea and character encoding when inserting escaped literals

Hi Lee, Thanks for the suggestion. I should have mentioned in my original message that as per your suggestion and the suggestion in the documentation, I have tried escaping the backslashes. When I do this, I get the error: ERROR: invalid input syntax for type bytea I tried also doing

Re: [GENERAL] bytea and character encoding when inserting escaped literals

Asche wrote: Hi Lee, On 05.05.2008, at 17:07, Lee Feigenbaum wrote: INSERT INTO myTable VALUES (..., E'\x15\x1C\x2F\x00\x02...', ...) ; try escaping the backslashes: INSERT INTO myTable VALUES (..., E'\\x15\\x1C\\x2F\\x00\\x02...', ...) ; Hi Jan, Thanks for the suggestion. I should have m

Re: [GENERAL] operator varchar = integer

David Fetter schrieb: That technical debt is a risk to your whole project, and you need to dedicate resources to paying it down. There are ways to get those automated casts, but they will only make your situation worse in the long run. Cheers, Davi

Re: [GENERAL] Custom C function - is palloc broken?

Craig Ringer wrote: After a bit of sleep and with the advantage of a now-working brain I've got it working, at least with 8.3 . Awesome, thanks :) - Dan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpr

Re: [GENERAL] bytea and character encoding when inserting escaped literals

Hi Lee, On 05.05.2008, at 17:07, Lee Feigenbaum wrote: INSERT INTO myTable VALUES (..., E'\x15\x1C\x2F\x00\x02...', ...) ; try escaping the backslashes: INSERT INTO myTable VALUES (..., E'\\x15\\x1C\\x2F\\x00\\x02...', ...) ; Jan -- Sent via pgsql-general mailing list (pgsql-general@postgre

Re: [GENERAL] COPY Performance

On Mon, May 5, 2008 at 9:03 AM, Scott Marlowe <[EMAIL PROTECTED]> wrote: > On Sun, May 4, 2008 at 5:11 PM, Hans Zaunere <[EMAIL PROTECTED]> wrote: > > Hello, > > > > We're using a statement like this to dump between 500K and >5 million > rows. > > > > COPY(SELECT SomeID FROM SomeTable WHERE

[GENERAL] bytea and character encoding when inserting escaped literals

Hi, I've searched the archives a fair amount on this topic, but have not found quite the answer / explanation I'm looking for. I attribute this to my eternal confusion over character encoding issues in all environments, so I apologize in advance for what might be a stupid question. :) I'mm

Re: [GENERAL] COPY Performance

On Sun, May 4, 2008 at 5:11 PM, Hans Zaunere <[EMAIL PROTECTED]> wrote: > Hello, > > We're using a statement like this to dump between 500K and >5 million rows. > > COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn > '0') > TO '/dev/shm/SomeFile.csv' Wait, are you really creating a .csv file

Re: [GENERAL] COPY Performance

On Mon, May 5, 2008 at 6:18 AM, Hans Zaunere <[EMAIL PROTECTED]> wrote: > > > We're using a statement like this to dump between 500K and >5 million > > > rows. > > > > > COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn > '0') > > > TO '/dev/shm/SomeFile.csv' > > > > > Upon first run, this

Re: [GENERAL] operator varchar = integer

On Mon, May 05, 2008 at 11:18:37AM +0200, Daniel Schuchardt wrote: > Hey Group, > > i know what all will say but i need to recreate the = operator for > datatypes varchar and integer in PostgreSQL 8.3. > > Our Software Project has Millions of Lines and so it would be > difficult to check all querie

Re: [GENERAL] Archive_command

Martin Marques <[EMAIL PROTECTED]> writes: > I have a question related to the archive_command option of postgresql.conf. > In the documentation[1] I found examples that add a "< /dev/null" at the > end of the cp command. I know what the redirection from /dev/null does > (send an EOF), but is it r

[GENERAL] Archive_command

I have a question related to the archive_command option of postgresql.conf. In the documentation[1] I found examples that add a "< /dev/null" at the end of the cp command. I know what the redirection from /dev/null does (send an EOF), but is it really needed? In [2] there are examples that don

Re: [GENERAL] operator varchar = integer

Daniel Schuchardt wrote: > i know what all will say but i need to recreate the = operator for > datatypes varchar and integer in PostgreSQL 8.3. > > Our Software Project has Millions of Lines and so it would be > difficult > to check all queries and Datatypes. Also it works really fine > and w

Re: [GENERAL] COPY Performance

> > We're using a statement like this to dump between 500K and >5 million > > rows. > > > COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn > '0') > > TO '/dev/shm/SomeFile.csv' > > > Upon first run, this operation can take several minutes. Upon second > > run, it will be complete in generall

Re: [GENERAL] COPY Performance

> > We're using a statement like this to dump between 500K and >5 > > million rows. > > > > COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn > '0') > > TO '/dev/shm/SomeFile.csv' > > > > Upon first run, this operation can take several minutes. Upon > > second run, it will be complete in ge

Re: [GENERAL] operator varchar = integer

ups; i have this script but forgott to execute it in the new createt db monday morning thnx. Filip Rembiałkowski schrieb: 2008/5/5 Daniel Schuchardt <[EMAIL PROTECTED] >: Hey Group, i know what all will say but i need to recreate the = operator for

Re: [GENERAL] operator varchar = integer

2008/5/5 Daniel Schuchardt <[EMAIL PROTECTED]>: > Hey Group, > > i know what all will say but i need to recreate the = operator for > datatypes varchar and integer in PostgreSQL 8.3. > > Our Software Project has Millions of Lines and so it would be difficult to > check all queries and Datatypes. A

[GENERAL] operator varchar = integer

Hey Group, i know what all will say but i need to recreate the = operator for datatypes varchar and integer in PostgreSQL 8.3. Our Software Project has Millions of Lines and so it would be difficult to check all queries and Datatypes. Also it works really fine and we all know the risk of wro

Re: [GENERAL] Request for Materialized Views

am Mon, dem 05.05.2008, um 0:43:46 -0700 mailte [EMAIL PROTECTED] folgendes: > Hi, > > I am not sure about the right place to post this question so I'm > trying here first: > > We are using Postgres in our company successfully since 2001 but now > we arrived at the conclusion that we really nee

Re: [GENERAL] Request for Materialized Views

Hi, [EMAIL PROTECTED] wrote: Hi, I am not sure about the right place to post this question so I'm trying here first: We are using Postgres in our company successfully since 2001 but now we arrived at the conclusion that we really need "Materialized Views" for our further business. Also we deci

[GENERAL] Request for Materialized Views

Hi, I am not sure about the right place to post this question so I'm trying here first: We are using Postgres in our company successfully since 2001 but now we arrived at the conclusion that we really need "Materialized Views" for our further business. Also we decided that we should try to pay so

Re: [GENERAL] Custom C function - is palloc broken?

Nathan Thatcher wrote: So what options does that leave all of us who need to compile and run our custom C functions in Windows? After a bit of sleep and with the advantage of a now-working brain I've got it working, at least with 8.3 . The problem was with DLL linkage, especially the Current

Re: [GENERAL] Custom C function - is palloc broken?

Nathan Thatcher wrote: > So what options does that leave all of us who need to compile and run > our custom C functions in Windows? Debug further :-) Because it's certainly possible to do it. IIRC, PostGIS for 8.3 is build with MingW and it works fine. And other extensions are known working when