> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > test=# select count(a.*) from pg_indexes a limit 10;
> > server closed the connection unexpectedly
>
> Hmmm ... the crash is certainly UnGood, but is there any reason we
> should accept this query rather than generating an error? I don't
> think it's
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Can you show me a non-broken
>> situation where pg_dump needs to resort to view shells?
> Well then shouldn't we just ban you from creating a view that creates a
> circular dependency?
I dunno. My question is exactly about whether there are
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> test=# select count(a.*) from pg_indexes a limit 10;
> server closed the connection unexpectedly
Hmmm ... the crash is certainly UnGood, but is there any reason we
should accept this query rather than generating an error? I don't
think it's legal vanilla
and a dump that orders the two views arbitrarily. We can certainly add
code to do something different, but are there any real-world cases where
this is needed? The above example seems more than slightly made-up.
The views aren't actually functional anyway (trying to use either would
result in an
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Please provide example cases.
> create view v1 as select 1;
> create view v2 as select 1 + (select * from v1);
> create or replace view v1 as select * from v2;
> It seems to me that the only way to solve that one is to dump 'view
> shells'.
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I just made distclean and then reconfigured with --with-openssl and I
> get this in HEAD:
FWIW, CVS tip builds perfectly cleanly --with-openssl in RHL 8.0,
which has (digs...)
openssl-devel-0.9.6b-29
openssl-0.9.6b-29
openssl096-0.9.6-11
Some
There's not currently any code for that, though I imagine we could
invent some at need. Please provide example cases.
create view v1 as select 1;
create view v2 as select 1 + (select * from v1);
create or replace view v1 as select * from v2;
It seems to me that the only way to solve that one is to
Hi,
A problem related with view was reported from a user. I narrowed down
the problem and found it was related to some usage of views:
(note that with/without limit is not relevant)
test=# select count(a.*) from pg_indexes a limit 10;
server closed the connection unexpectedly
This probabl
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Attached is a compile failure I am seeing in CVS HEAD in bin/pg_dump.
Hmm. I made some what-I-thought-were-unimportant changes in the order
of header inclusions in pg_dump. Probably what you are seeing is a
previously unnoticed case of some header that
> I'm interested to know how you deal with circular dependencies in Views
> and Functions?
There's not currently any code for that, though I imagine we could
invent some at need. Please provide example cases.
> Also, what happens if I delete a key dependency from my pg_depend table
> manually?
Christopher Kings-Lynne wrote:
/usr/include/openssl/asn1.h:907: syntax error before `)'
In file included from /usr/include/openssl/evp.h:145,
from /usr/include/openssl/x509.h:67,
from /usr/include/openssl/ssl.h:177,
from ../../../src/interfaces/lib
I just made distclean and then reconfigured with --with-openssl and I
get this in HEAD:
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../src/interfaces/libpq
-I../../../src/include -DBINDIR=\"/home/chriskl/local/bin\" -c -o
common.o common.c -MMD
I
fresh checkout just compiled fine for me on Linux (RH8) with ssl
enabled. Maybe it is your openssl installation?
cheers
andrew
Bruce Momjian wrote:
Attached is a compile failure I am seeing in CVS HEAD in bin/pg_dump.
The offending lines are:
gmake[3]: Leaving directory `/usr/var/local/src
Hey Tom,
I have committed some fairly wide-ranging revisions to pg_dump to make
it dump database objects in a "safe" order according to the dependency
information available from pg_depend. While I know that I have fixed
a lot of previously-broken cases, it's hardly unlikely that I've broken
some
Attached is a compile failure I am seeing in CVS HEAD in bin/pg_dump.
The offending lines are:
gmake[3]: Leaving directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/backend/parser'
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations
-O1 -
Bruce Momjian wrote:
> Tom Lane wrote:
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > The libpq SSL memory leak reported on -bugs would be good to fix.
> >
> > We don't know yet if that's our bug or not.
> >
> > > BTW, is there a particular reason we're pushing out 7.4.1 so soon?
> > > ISTM t
=?iso-8859-7?q?NK?= <[EMAIL PROTECTED]> writes:
> Could you please tell me the way to take the names of the columns?
There is no way to do that in the grammar, because it doesn't have the
information available.
You could probably modify the insert-statement processing in analyze.c
to print out th
Dear Friends,
I am trying to modify the parser of the postgresql so as to print all the columns of a table (or to put them in a seperate file) when the parser meets an Insert Statement.
In the file (/src/backend/parser/gram.y) ,
InsertStmt: INSERT INTO qualified_name insert_rest{ $4
Dear Friends,
I am trying to modify the parser of the postgresql so as to print all the columns of a table (or to put them in a seperate file) when the parser meets an Insert Statement.
During the parsing, i can have the relation name ( type: char *) but i cant find the way to get from the name
Dear Friends,
I am trying to modify the parser of the postgresql so as to print all the columns of a table (or to put them in a seperate file) when the parser meets an Insert Statement.
During the parsing, i can have the relation name ( type: char *) but i cant find the way to get from the name
Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Treating pointers as integers is technically nonportable but
realistically you would be pretty hard pressed to find any
architecture anyone runs postgres on where there isn't some integer
datatype that you can cast both directions from poin
Greg Stark <[EMAIL PROTECTED]> writes:
> Treating pointers as integers is technically nonportable but
> realistically you would be pretty hard pressed to find any
> architecture anyone runs postgres on where there isn't some integer
> datatype that you can cast both directions from pointers safely.
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> I tried with 7.3.3 and got error:
> ./pg_dump: relocation error: ./pg_dump: undefined symbol: get_progname
You have a problem with linking to the wrong version of libpq.so.
regards, tom lane
---(end of br
On Sat, 6 Dec 2003, Tom Lane wrote:
> I have committed some fairly wide-ranging revisions to pg_dump to make
> it dump database objects in a "safe" order according to the dependency
> information available from pg_depend. While I know that I have fixed
> a lot of previously-broken cases, it's har
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> From the C-FAQ:
>
> A:Not portably, it doesn't. It attempts to modify the variable a
> twice between sequence points, so its behavior is undefined.
> 10.3: How can I write a generic macro to swap two values?
Neither of these are really rel
25 matches
Mail list logo
