On 6/20/06, Tom Lane <[EMAIL PROTECTED]> wrote:
One idea that comes to mind is to have a compile time option to record
the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
would not be so hard to identify the culprit while trawling through
memory. The overhead costs would be so h
Probably this explains the ERROR for the last query... The ORDER BY
and LIMIT clauses are expected to end a query (except for subqueries,
of course), and hence the keyword UNION is not expected after the
LIMIT clause...
On 6/18/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Joe Conway <[EMAIL PROTECTED
Confirmation: The patch rollback in src/pl/plpgsql/src/gram.y resolved
the issue.
On 5/28/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I wrote:
> Currently looking through the rest of the patch. I'm wondering
> about appendStringLiteral: maybe we should kill that entirely
> in favor of using PQescap
Any ideas how I can revert back to compilable code?
On 5/28/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Bruce Momjian writes:
> I am thinking it is best to always use E'' in that case. OK?
I'm planning to revert it to the previous logic: E if there's any
backslash. I think we have to do likewise
Hi All,
I am constantly getting this error:
make -C pl all
make[2]: Entering directory `/d/Dev/postgres/pgsql_tip/src/pl'
make[3]: Entering directory `/d/Dev/postgres/pgsql_tip/src/pl/plpgsql'
make -C src all
make[4]: Entering directory `/d/Dev/postgres/pgsql_tip/src/pl/plpgsql/src'
dlltool -
On 5/26/06, Simon Riggs <[EMAIL PROTECTED]> wrote:> On Fri, 2006-05-26 at 10:22 +0200, Dennis Bjorklund wrote:
> > Shouldn't> >> >SELECT max(*) FROM foo;
> >> > give an error?IMO, yes.> > SQL:2003 would not allow this; SQL:2003 permits only COUNT(*) and no> other aggregate function. All other a
try installing mingw.
Sorry for uiintentionally misleading someone, if I did!
Regards,
Gurjeet
On 5/25/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Gurjeet Singh said:
>Also, I would recommend uninstalling cygwin before you install
> mingw,
>If you don't wi
at least rename the folder
to someting else (cygwin.before.mingw) so that you don't accidentally
use cygwin's binaries.
Regards,
Gurjeet.
On 5/25/06, Gurjeet Singh <[EMAIL PROTECTED]> wrote:
Hi Sibel,
Here's the mail that I posted about 10 days ago about compiling
and d
Hi Sibel,
Here's the mail that I posted about 10 days ago about compiling
and debugging postgres on windows. I have used msys/mingw toolkit and
it is the recommended (by pg community) toolkit to compile postgres on
windows.
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00396.php
One more question comes to mind. IIRC, Oracle doesn't need you to
rollback the whole transaction if one statement fails (like constarint
violation in this case)!!! Does the standard dictate that an error in
a transaction should force a rollback?
I could be wrong about Oracle; I do not have
ards,
Gurjeet.
On 5/21/06, Jaime Casanova <[EMAIL PROTECTED]> wrote:
On 5/21/06, Gurjeet Singh <[EMAIL PROTECTED]> wrote:
> Hi All,
>
>While trying to implement a recent TODO item, I noticed this behaviour:
>
> test=# select * from t2;
> ERROR: current transaction
Hi All,
While trying to implement a recent TODO item, I noticed this behaviour:
test=# drop table t2; drop table t1;
DROP TABLE
DROP TABLE
test=# create table t1(a int primary key );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"t1_pkey" for table "t1"
CREATE TABLE
test=# cr
Just a small example of the fact that people need such
functionality... and will devise other ways, albeit inefficient and
dangerous, to implement the missing feature.
The success of an RDBMS (or any other product for that matter)
depends on how well it strikes the balance between the stand
Do we have any plans of introducing 'AUTONOMOUS TRANSACTION' like feature?
Again, it might not be a part of the standard but it is very
helpful in situations like these!!! You can run a trigger with an
autonomous transaction attached to it, which guarantees that the work
done by trigge
I agree... VERBOSE option can be made parameterised to include
additional information in the EXPLAIN's output.
I also agree that adding the schema name wouldn't add any
overhead, and I support Tom's suggestion: 'Possibly a reasonable
compromise would be for EXPLAIN to act like rule reverse-
On 5/16/06, Martijn van Oosterhout wrote:
On Tue, May 16, 2006 at 09:15:13AM +0530, Gurjeet Singh wrote:
As has been pointed out, aliases ave always been displayed. The OPs
problem was that he was using schema.tablename everywhere and explain
didn't distinguish between schema1.mytabl
I think Jonah is referring to the the 'START WITH ... CONNECT BY'
clause feature from Oracle. Am I right Jonah?
For such queries, Oracle introduces a pseudocolumn LEVEL, that
holds the value of the indentation level of the current rusultant row.
In Oracle, the LEVEL column returns 0 for the
I don't think Cristiano is asking for the schema_name in the
EXPLAIN o/p. The request is for the table ALIASes to be shown in the
o/p, which makes more sense than schema_name+table_name, since the
same table can be used in the same query more than once.
Gurjeet.
On 5/15/06, Jim C. Nasby <[EMA
It done so, because InitProcess() is supposed to be called only
once per backend, because it allocates a PGPROC from a LIST OF free
PGPROCs.
So with this test, and calling elog( ERROR, ... ) we are stopping
the caller from doing a second initialization for this backend.
On 5/16/06, ipig <[
No I am not... I used Eclipse for the first time just last week.
But yes, I wish to contribute to the CDT plugin. I think their Indexer
is a bit slow... it takes more than an hour (about two hours) to index
postgres' source code!!! Also, I just noticed that the background gdb
crashes when tryin
e if you like what you
finally can do within Eclipse. Any inputs on the document will be
appreciated.
Thanks,
Gurjeet.
On 5/8/06, Thomas Hallgren <[EMAIL PROTECTED]> wrote:
Gurjeet Singh wrote:
>Thomas, I love the idea of eclipse; any platform, any language,
> one IDE. I am downlo
I dont think anyone is arguing that such an application is not
broken. We should see how we can stop a developer from writing buggy
code.
IMO, such a GUC variable _should_ be created and turned on by default.
In case an application fails, at the least, the developer knows
that his appli
On 5/5/06, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
On 5/5/06, Gurjeet Singh <[EMAIL PROTECTED]> wrote:
> If it is such a 'simple porting', may I ask why hasn't it been
> attempted successfuly in so many years of PG's history?
Because most of use don&
(missed the mailing list last time)
Hi William,
Thanks for the steps to succeed with vcproject. I am sure that
there will be a few more tweaks involved (like setting VC's include
path etc.). I will try to build it and consult/inform you if there is
any deviation from the README.
This will
Hi William(uniware), Chuck and Hackers,
I have been interested in doing complete PGSQL development in MSVC
for a long time now. With reference to one of Chuck's mails to
-hackers-win32 with the same subject, you said that you were able to
successfully compile PG 8.1 with some minor tweaks.
Hopefully your problem is solved by now; but if not, here's the link:
do read the README expanded at the end of the file-list:
http://www.postgresql.org/ftp/binary/v8.1.2/win32/
I could give you a long lecture on how to look for the things on your
own a little bit before pestering these mailing l
On 10/13/05, Josh Berkus wrote:
> Tom,
>
> > I think my preference is to allow '24:00:00' (but not anything larger)
> > as a valid input value of the time datatypes. This for two reasons:
> > * existing dump files may contain such values
> > * it's consistent with allowing, eg, '12:13
401 - 427 of 427 matches
Mail list logo
