On Aug 26, 2006, at 11:40 , Bruce Momjian wrote:
I used your ideas to make a patch to fix your example:
test= select '41 months'::interval / 10;
?column?
---
4 mons 3 days
(1 row)
and
test= select '41 months'::interval *
Hi,
what's the problem with COPY view TO, other than you don't like it? :-)
That was the beginning and is used in production
according to the original authors.
I also broke the check for a FOR UPDATE clause. Not sure where but it
must be easy to fix :-) I'd do it myself but I'm heading to
Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes would be
needed (eg, there's no need to eat maintenance_work_mem worth of RAM
for the dead-TIDs array); and a decent respect to
Bruce Momjian [EMAIL PROTECTED] wrote:
Is there anything to do for 8.2 here?
I'm working on Tom's idea. It is not a feature and does not change
the on-disk-structures, so I hope it meet the 8.2 deadline...
Tom Lane [EMAIL PROTECTED] wrote:
I'm wondering about doing something similar to what
Hi there,
here comes the latest version (version 7) of the patch to handle large
result sets with psql. As previously discussed, a cursor is used
for SELECT queries when \set FETCH_COUNT some_value 0
(defaults to 100 if FETCH_COUNT is set with no value).
Comparing to the previous version, the
Böszörményi Zoltán wrote:
Hi,
what's the problem with COPY view TO, other than you don't like it? :-)
The problem is that it required a ugly piece of code. Not supporting it
means we can keep the code nice. The previous discussion led to this
conclusion anyway so I don't know why we are
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes would be
needed (eg, there's no need to eat maintenance_work_mem worth of RAM
for the dead-TIDs
Alvaro Herrera wrote:
Böszörményi Zoltán wrote:
Hi,
what's the problem with COPY view TO, other than you don't like it? :-)
The problem is that it required a ugly piece of code. Not supporting it
means we can keep the code nice. The previous discussion led to this
conclusion anyway
Andrew Dunstan írta:
Alvaro Herrera wrote:
Böszörményi Zoltán wrote:
Hi,
what's the problem with COPY view TO, other than you don't like it? :-)
The problem is that it required a ugly piece of code. Not supporting it
means we can keep the code nice. The previous discussion led to
Zoltan Boszormenyi wrote:
Andrew Dunstan írta:
Alvaro Herrera wrote:
Böszörményi Zoltán wrote:
what's the problem with COPY view TO, other than you don't like it? :-)
The problem is that it required a ugly piece of code. Not supporting it
means we can keep the code nice. The previous
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must be reached before introducing such a change (and not
during
Hans-Juergen Schoenig wrote:
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must be reached before introducing
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Andrew Dunstan írta:
Alvaro Herrera wrote:
Böszörményi Zoltán wrote:
what's the problem with COPY view TO, other than you don't like it? :-)
The problem is that it required a ugly piece of code. Not
Alvaro Herrera [EMAIL PROTECTED] writes:
My question is, if we allow this:
copy (select * from view) to stdout;
(or to a file, whatever), is it enough for you? Or would you insist on
also having
copy view to stdout;
?
We can, and the posted patch does, support the first form, but not the
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must be
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must be reached
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
My question is, if we allow this:
copy (select * from view) to stdout;
(or to a file, whatever), is it enough for you? Or would you insist on
also having
copy view to stdout;
?
We can, and the posted patch does, support the
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must be reached before introducing such a change (and not
during
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed
Hans-Juergen Schoenig wrote:
It's ugly because you are forcing the system to parse something that
was already parsed.
definitely an argument for dropping the view stuff ...
On the other hand, it's quite possible that this could be made to work
_without_ doing black magic (which would be OK
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
But COPY view (col1, col2, ...) TO may still be
useful even if the COPY (SELECT ...) (col1, col2, ...) TO
is pointless. [1]
Hum, I don't understand what you're saying here -- are you saying that
you can't do something with the first form, that
On the other hand I don't see why you are arguing in favor of a useless
feature whose coding is dubious; you can have _the same thing_ with nice
code and no discussion.
Because of [1] and because Mr. Schoenig's arguments
about changing schemas.
first of all; hans is enough - skip the mr
[EMAIL PROTECTED] writes:
here comes the latest version (version 7) of the patch to handle large
result sets with psql. As previously discussed, a cursor is used
for SELECT queries when \set FETCH_COUNT some_value 0
Wait a minute. What I thought we had agreed to was a patch to make
commands
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
But COPY view (col1, col2, ...) TO may still be
useful even if the COPY (SELECT ...) (col1, col2, ...) TO
is pointless. [1]
Hum, I don't understand what you're saying here -- are you saying that
you can't
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
But COPY view (col1, col2, ...) TO may still be
useful even if the COPY (SELECT ...) (col1, col2, ...) TO
is pointless. [1]
Hum, I don't understand what you're saying here -- are
Tom Lane wrote:
Wait a minute. What I thought we had agreed to was a patch to make
commands sent with \g use a cursor. This patch changes SendQuery
so that *every* command executed via psql is treated this way.
That's what I remembered. I don't think we want to introduce a
difference
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
But COPY view (col1, col2, ...) TO may still be
useful even if the COPY (SELECT ...) (col1, col2, ...) TO
is pointless. [1]
Hum,
Zoltan Boszormenyi wrote:
I think at this point is someone else's judgement whether you can put it
back or not. Tom already said that he doesn't object to the feature per
se; no one else seems opposed to the feature per se, in fact.
Now, I don't really see _how_ to do it in nice code, so
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
I think at this point is someone else's judgement whether you can put it
back or not. Tom already said that he doesn't object to the feature per
se; no one else seems opposed to the feature per se, in fact.
Now, I don't really see _how_ to do
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
I think at this point is someone else's judgement whether you can put it
back or not. Tom already said that he doesn't object to the feature per
se; no one else seems opposed to the feature per se, in fact.
Alvaro Herrera [EMAIL PROTECTED] writes:
Zoltan Boszormenyi wrote:
My v8 had the syntax support for
COPY (SELECT ...) (col1, col2, ...) TO
and it was actually working. In your v9
you rewrote the syntax parsing so that
feature was lost in translation.
Interesting. I didn't realize
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Alvaro Herrera írta:
Hum, are you going to put back the original cruft to support copy view?
I suggest you don't do that.
Well, the other way around is to teach heap_open()
to use views. Brrr. Would it be any cleaner?
Don't even think of going
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Alvaro Herrera írta:
Hum, are you going to put back the original cruft to support copy view?
I suggest you don't do that.
Well, the other way around is to teach heap_open()
to use views. Brrr. Would it be any
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Zoltan Boszormenyi wrote:
My v8 had the syntax support for
COPY (SELECT ...) (col1, col2, ...) TO
and it was actually working. In your v9
you rewrote the syntax parsing so that
feature was lost in translation.
Peter Eisentraut wrote:
Tom Lane wrote:
Wait a minute. What I thought we had agreed to was a patch to make
commands sent with \g use a cursor. This patch changes SendQuery
so that *every* command executed via psql is treated this way.
That's what I remembered. I don't think we want to
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Tom Lane wrote:
Wait a minute. What I thought we had agreed to was a patch to make
commands sent with \g use a cursor.
I am confused. I assume \g and ; should be affected, like Peter says.
Tom, what *every* command are you
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Tom Lane wrote:
Wait a minute. What I thought we had agreed to was a patch to make
commands sent with \g use a cursor.
I am confused. I assume \g and ; should be affected, like Peter says.
Tom, what
Bruce Momjian [EMAIL PROTECTED] writes:
OK, got it. I just don't see the value to doing \g and not ;. I think
the \gc case was a hack when he didn't have \set. Now that we have
\set, we should be consistent.
I'm willing to accept this if we can make sure we aren't adding any
overhead --- see
I am confused. I assume \g and ; should be affected, like Peter says.
Tom, what *every* command are you talking about? You mean \d?
Like I said, I thought we were intending to modify \g's behavior only;
that was certainly the implication of the discussion of \gc.
At some point
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, got it. I just don't see the value to doing \g and not ;. I think
the \gc case was a hack when he didn't have \set. Now that we have
\set, we should be consistent.
I'm willing to accept this if we can make sure we aren't
On Mon, Aug 28, 2006 at 19:35:11 +0200,
Zoltan Boszormenyi [EMAIL PROTECTED] wrote:
(BTW, is there anyone as high-ranking as them,
or the committee is a duumvirate? :-) )
There is a group referred to as core that is the final arbitrator of things.
Tom and Bruce are both members of this
Guillaume Smet wrote:
On 8/7/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Updated patch attached. It prints the text bind parameters on a single
detail line. I still have not seen portal names generated by libpq.
I'm currently testing CVS tip to generate sample log files. I noticed
that
Bruno Wolff III wrote:
On Mon, Aug 28, 2006 at 19:35:11 +0200,
Zoltan Boszormenyi [EMAIL PROTECTED] wrote:
(BTW, is there anyone as high-ranking as them,
or the committee is a duumvirate? :-) )
There is a group referred to as core that is the final arbitrator of things.
Tom and
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, I do. I have applied the attached patch to fix this issue and
several others. The fix was to save the bind parameters in the portal,
and display those in the executor output, if available.
I have a feeling you just blew away the 4% savings in psql
BTom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, I do. I have applied the attached patch to fix this issue and
several others. The fix was to save the bind parameters in the portal,
and display those in the executor output, if available.
I have a feeling you just blew away
bruce wrote:
BTom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, I do. I have applied the attached patch to fix this issue and
several others. The fix was to save the bind parameters in the portal,
and display those in the executor output, if available.
I have a
46 matches
Mail list logo
