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 * 0.
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 b
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 respec
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 w
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 d
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 de
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 th
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
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 fea
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 intr
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 supportin
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
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 reache
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 r
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
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 fea
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 and
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 b
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, tha
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
com
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 do
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
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 bet
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 c
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 s
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'
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
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 cle
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 translati
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
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* comma
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 sa
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 ---
> > > 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
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 ar
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 t
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
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
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
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
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 think I've got it. I plan to update the regression tests this
evening, but I wanted to post what I believe is a solution.
select '41 mon'::interval / 10;
?column?
---
4 mons 3 days
(1 row)
select '41 mon 360:00'::interval / 10 as "pos"
, '-41 mon -360:00'::interval / 10 as
47 matches
Mail list logo
