Ron Peterson <[EMAIL PROTECTED]> writes:
> On Thu, Jan 09, 2003 at 04:50:56PM -0500, Ron Peterson wrote:
>> colindices = (int *) malloc (ncols * sizeof (int));
> Of course we should verify that malloc succeeded...
Actually, the correct answer is "you should not be using malloc() in
backend functi
On Thu, Jan 09, 2003 at 04:50:56PM -0500, Ron Peterson wrote:
> colindices = (int *) malloc (ncols * sizeof (int));
Of course we should verify that malloc succeeded...
if (colindices == NULL) {
elog (ERROR, "noupcol: malloc failed\n");
SPI_finish();
return PointerGetD
On Thu, Jan 09, 2003 at 22:48:11 -0200,
Maurício Sessue Otta <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a PHP script that do something like this:
>
> INSERT INTO table_with_sequence (field1, field2, fieldn)
> SELECT field1, field2, ..., fieldn FROM table,table
> WHERE condition, conditio
Hi,
I have a PHP script that do something like
this:
INSERT INTO table_with_sequence (field1,
field2, fieldn)
SELECT field1, field2, ..., fieldn FROM table,table
WHERE condition, condition
My doubt:
Will the rows just inserted in
"table_with_sequence" always be sequencial?
(won't
On Thu, Jan 09, 2003 at 19:15:51 -0500,
"Randy D. McCracken" <[EMAIL PROTECTED]> wrote:
>
> Hi Rajesh,
>
> I don't know why but the example you gave me did not work. Here is what
> happened when I tried:
>
> ==
>
> pubs_test=# UPDATE publications SET url = replace( 'www.srs.fs.fed.us
On Thu, 9 Jan 2003, Ross J. Reedstrom wrote:
> On Thu, Jan 09, 2003 at 11:00:32AM +0530, Rajesh Kumar Mallah. wrote:
> >
> > any anyone explain whats wrong with the replace based solution to this problem
> > which i posted earlier?
> >
> > did i misunderstood anything?
>
> Probably just overkill -
On Thu, Jan 09, 2003 at 11:00:32AM +0530, Rajesh Kumar Mallah. wrote:
>
> any anyone explain whats wrong with the replace based solution to this problem
> which i posted earlier?
>
> did i misunderstood anything?
Probably just overkill - I'm sure it would work, but, based on how the
question was
On Thu, Jan 09, 2003 at 07:54:04PM -, [EMAIL PROTECTED] wrote:
> Sounds similar to the plpgsql example at:
>
> http://www.archonet.com/pgdocs/lock-field.html
>
> which silently discards changes. It's trivial (apart from quoting issues)
> to write a trigger generator to customise the above in
On Thu, 2003-01-09 at 11:29, Radu-Adrian Popescu wrote:
> What i'm saying is that i know that some of my colleagues, nice guys for
> that matter, and good programmers, will come screaming
> to me "what's with the b.s. error ?!?", and when i'll tell them that the sql
> parser belives that's an inexi
> On Wed, Jan 08, 2003 at 01:13:03PM -0500, Ron Peterson wrote:
>> On Tue, Jan 07, 2003 at 11:01:08AM -0500, Tom Lane wrote:
>>
>> > > I thought that the idea behind noup was to protect single columns
>> from
>> > > update. However, when I apply the noup trigger as above, I can't
>> > > update /an
On Wed, Jan 08, 2003 at 01:13:03PM -0500, Ron Peterson wrote:
> On Tue, Jan 07, 2003 at 11:01:08AM -0500, Tom Lane wrote:
>
> > > I thought that the idea behind noup was to protect single columns from
> > > update. However, when I apply the noup trigger as above, I can't
> > > update /any/ column
Nice to see that things are starting to move.
I was wandering however whether I've succeeded in making a point.
Regards,
=
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
Subject: Re: [SQL] SQL function parse error ?
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Although the rules could be similar to those for + and - at the end of
> operator strings (no $ at the end of an operator unless it contains
> characters not normally in SQL92 operators). I'm not sure that
> behavior is sensible either, but if someone wa
On Thu, 9 Jan 2003, Tom Lane wrote:
> Achilleus Mantzios <[EMAIL PROTECTED]> writes:
> > On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
> >> Why is that ? Because the >$ does not exist, not in the default operator
> >> list
>
> > i think the parser is built with yacc, (not "from scratch code") so
Please let me state again where i stand regarding this issue, apart from
tech stuff.
>From the viewpoint of someone who has worked with databases for quite some
time, including postgresql (2yrs),
and is making a living out of it, -- that would be me :) -- it is a very odd
and unpleasant behaviour.
Achilleus Mantzios <[EMAIL PROTECTED]> writes:
> On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
>> Why is that ? Because the >$ does not exist, not in the default operator
>> list
> i think the parser is built with yacc, (not "from scratch code") so
> maybe finding if ">$" is in the specific DB's
On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
> Since you can overload and define new operators, the parser must - at some
> point in time - lookup the operator definition.
> It seems to me (but this is just an ideea), that the rules should go like
> this :
> ...
> check >$ is a defined operator
Since you can overload and define new operators, the parser must - at some
point in time - lookup the operator definition.
It seems to me (but this is just an ideea), that the rules should go like
this :
...
check >$ is a defined operator
if true,
it is applied to left side and 1, in my example
Hello, nice to hear from you. I sent my message just before this one
arrived, sorry... :(
About the
>Nonsense. SQL syntax is space-sensitive. Or have you successfully
>written
>SELECTXFROMY;
>lately?
I do hope this is a joke. If not, it's an insult.
If it's not even that, then the
On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
>
>
> Why is that ? Because the >$ does not exist, not in the default operator
> list (also there is no operator defined
> using $ anywhere within). And because whitespacing the code solves the
> problem, which is rather thin, i must say.
>
Radu-Adri
Thomas, this line of conversation is not quite what one would expect...
I do read the postgresql docs when in run into trouble. And yes, i do know
there is such a thing as
operator overloading.
What i'm saying here, and i belive to be right, is that writing a piece of
code such as
table.colu
"Radu-Adrian Popescu" <[EMAIL PROTECTED]> writes:
> This is SQL, and people who are using PostgreSql write SQL, not
> whitespace-sensitive SQL, bash or whatever.
Nonsense. SQL syntax is space-sensitive. Or have you successfully
written
SELECTXFROMY;
lately?
There has occasionally been t
One could subscribe to pgsql-bugs if you wanted to look into any new
bugs that come down the pipe.
Robert Treat
On Wed, 2003-01-08 at 23:30, Bruce Momjian wrote:
>
> No bugzilla, but do have a TODO list. See the developers FAQ.
>
> --
Radu-Adrian Popescu wrote:
I'm perfectly aware of the fact that a space solves the issue here.
What I'm saying is that it is not natural nor common to take some
whitespace
into
account when parsing, since this is not bash language, nor python, as it
shouldn't be !
This is SQL, and people who ar
I'm perfectly aware of the fact that a space solves the issue here.
What I'm saying is that it is not natural nor common to take some whitespace
into
account when parsing, since this is not bash language, nor python, as it
shouldn't be !
This is SQL, and people who are using PostgreSql write SQL,
Radu-Adrian Popescu wrote:
Take the following for example:
create or replace function testfunc1(int) returns setof test as
'
select * from test where age>$1;
'^^
language sql;
I didn't find it in documentation, but sql functions are like bash (you
forgot ab
Hello !
There is a strange behaviour in the SQL function
parser (haven't tested this with the plpgsql lang) when using standard
operators
and function parameters.
Take the following for example:
create or replace function
testfunc1(int) returns setof test as' select * from
test where
I have sucessfuly used resin (standard, not EE,
with datasource, pooling) and postgresql.
=Radu-Adrian PopescuCSA, DBA, DeveloperAldratech
Ltd.
- Original Message -
From:
Pedro
Igor
To: [EMAIL PROTECTED]
Sent: Thursday, January 02, 2003 3:16
PM
Subject: [SQL]
> but a select like this takes ages (long time):
> # select * from file where id = 1921773;
>id | name
>-+
> 1921777 | icons
>
I believe the reason is this : the numeric literal is first considered an int4
becuase it falls within the range of int4 (-2147483648
Hi,
Short: postrgesql-7.2.3 doesn't figure to convert int4 to int8
implicitly / by context (as in a query). How do I help it ?
Long:
I have index on a table, a select like this takes a split second:
# select * from file where id = fileIDseq.last_value-1;
id | name
-+
Warning: pg_connect() unable to connect to PostgreSQL server: FATAL 1: No
pg_hba.conf entry for host 64.49.215.82, user portal, database 186_portal
in /usr/local/www/www.postgresql.org/globals.php on line 130
==
Achilleus Mantzios
S/W
31 matches
Mail list logo
