Hi,
Hmm. That sounds like it would be a horrid mess. You need to decouple
> the execution of the subplan from the use of its outputs, apparently.
> There is some precedent for this in the way that InitPlans are handled:
> the result of the subplan is stored into a ParamList array entry that's
Hi,
On 3/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
NikhilS <[EMAIL PROTECTED]> writes:
> I have invented a ROWEXPR_SUBLINK type that handles multiple output
columns.
> The trouble is that since eventually columns of the parents have to be
part
> of the query's targetList, I am sending the enti
NikhilS <[EMAIL PROTECTED]> writes:
> I have invented a ROWEXPR_SUBLINK type that handles multiple output columns.
> The trouble is that since eventually columns of the parents have to be part
> of the query's targetList, I am sending the entire subquery as one of the
> entries in that list and the
Hi,
No. Offhand I think you'd either need to relax EXPR_SUBLINK to allow
> multiple output columns, or invent a ROW_SUBLINK SubLinkType that is
> just like EXPR_SUBLINK except for allowing multiple output columns.
> The latter would probably be less likely to break other things...
>
Yeah, was l
Hi,
On 3/16/07, Tom Lane <[EMAIL PROTECTED]> wrote:
NikhilS <[EMAIL PROTECTED]> writes:
> To allow both of the above to hold, I think the subselect will have to
be
> treated like a EXPR_SUBLINK subquery. I was wondering if we have a
similar
> mechanism for plain selects/subselects to check and
NikhilS <[EMAIL PROTECTED]> writes:
> To allow both of the above to hold, I think the subselect will have to be
> treated like a EXPR_SUBLINK subquery. I was wondering if we have a similar
> mechanism for plain selects/subselects to check and restrict their output to
> a single row.
No. Offhand I
Hi,
> What's the expected result if the tuple from subselect is more than 1?
Error, per SQL99 section 7.14:
1) If the cardinality of a is greater than 1
(one),
then an exception condition is raised: cardinality violation.
I expect no update at all in case of void resu
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> NikhilS wrote:
>> I have tried some update-subselect variations and they seem to work. For
>> example the case in the src/test/regress/sql/update.sql, which used to
>> fail till now, seems to work:
>>
>> UPDATE update_test SET (a,b) = (select a,b FROM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NikhilS wrote:
> I have tried some update-subselect variations and they seem to work. For
> example the case in the src/test/regress/sql/update.sql, which used to
> fail till now, seems to work:
>
> UPDATE update_test SET (a,b) = (select a,b FROM upd
Hi,
> The question is that since this enhances the UPDATE syntax, what changes
and
> where all they need to be made with respect to the documentation?
Documentation is the very least of your worries. What exactly is your
implementation plan? If this were a simple or narrow fix it would
have
NikhilS <[EMAIL PROTECTED]> writes:
> I have coded up a patch which solves the following TODO. I will submit a
> patch for this soon:
> http://archives.postgresql.org/pgsql-hackers/2006-07/msg01306.php
Cool...
> The question is that since this enhances the UPDATE syntax, what changes and
>
Hi,
I have coded up a patch which solves the following TODO. I will submit a
patch for this soon:
- UPDATE
- Allow UPDATE tab SET ROW (col, ...) = (SELECT...)
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01306.php
The question is that since this enhances the UPDATE sy
12 matches
Mail list logo
