Zoltan Boszormenyi [EMAIL PROTECTED] writes:
after some experimentation, I came up with the attached patch,
which implements parsing the following SERIAL types:
As has been pointed out before, it would be a seriously bad idea to
implement the SQL syntax for identity columns without matching
Hi,
after some more reading, I am finally starting
to grasp what Tom Lane meant with action at a
distance. I outline below the information that
I collected from the SQL2003 standard.
Under section 11.5 default clause:
Case:
a) If the descriptor of S indicates that
it represents a column of
Hi,
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 22 August 2006 16:10, Tom Lane wrote:
As I see it, we've effectively got a patch that was rejected once,
and Bruce wants to apply it anyway because no replacement has been
forthcoming.
Well, unless someone is going to commit to doing it
Hi,
Tom Lane wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of those
others. But is that what I should be spending my time on
Böszörményi Zoltán wrote:
Hi,
Tom Lane wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of
those
others. But is that what I
Böszörményi Zoltán wrote:
So when will you send in a revised patch?
Soon. :-)
No, don't send it soon. We're in feature freeze already (and have
been for three weeks). You need to send it now.
I have to test it some more but I will send it.
Best regards,
Zoltán Böszörményi
Böszörményi Zoltán wrote:
B?sz?rm?nyi Zolt?n wrote:
So when will you send in a revised patch?
Soon. :-)
No, don't send it soon. We're in feature freeze already (and have
been for three weeks). You need to send it now.
I have to test it some more but I will send it.
I think
Hi,
we have a large export here, I made an in-house benchmark
between Informix, plain PostgreSQL-8.1.4 and
8.2devel+COPY(SELECT) using the same data and query.
Find the results below for the two PostgreSQL versions.
With PostgreSQL 8.1.4, I used this:
begin;
select ... into temp myquery1;
copy
Böszörményi Zoltán [EMAIL PROTECTED] writes:
With PostgreSQL 8.1.4, I used this:
begin;
select ... into temp myquery1;
copy myquery1 to stdout csv delimiter '|';
rollback;
The performance of this would doubtless vary a lot with the temp_buffers
setting. Did you try different values
Hi,
2010-06-23 22:42 keltezéssel, Bruce Momjian írta:
Boszormenyi Zoltan wrote:
Hi,
we improved ECPG quite a lot in 9.0 because we worked and
still working with an Informix to PostgreSQL migration project.
We came across a pretty big performance problem that can be seen in
every naive
2010-06-24 11:04 keltezéssel, Heikki Linnakangas írta:
On 24/06/10 10:27, Böszörményi Zoltán wrote:
And this readahead is not on by default, it's only activated
by ecpg -r fetch_readahead.
Is there a reason not to enable it by default? I'm a bit worried that
it will receive no testing
2010-06-24 14:13 keltezéssel, Michael Meskes írta:
I think, yes, it does make sense. Because we are talking
about porting a whole lot of COBOL applications.
COBOL???
Yes, OpenCOBOL...
The ESQL/C or ECPG connector was already written
the Informix quirks in mind, so it fetches only
12 matches
Mail list logo