On Thu, Jul 31, 2003 at 10:00:07AM +0200, Christoph Haller wrote:
> >
> > So, I met such a problem: it's impossible to use NEW in a subselect
> > used in a (non-select) rule. The error is:
> > exist>. Is this a way to do that newertheless (without using of a
> > function, of course)?
> >
> Coul
On Tue, Jul 29, 2003 at 06:32:44PM -0400, Tom Lane wrote:
> The problem is that the rule gets expanded into something rather like
>
> insert into a select ... from new, produce(new.b);
>
> and we can't support that. If we ever add support for SQL99's
> LATERAL(), it might help improve matt
On Sun, Jul 27, 2003 at 11:49:10AM -0400, Tom Lane wrote:
> I put up a proposal in pgsql-hackers to change this behavior:
> http://archives.postgresql.org/pgsql-hackers/2003-07/msg00818.php
> If we made that change then the "wrong" way of defining the default
> would fail in an obvious fashion ---
In general, the task I'm trying to solve is to make a multiply inserts
for a table on the one only insert for a view. It should be noted
about the method of producing these multiply rows, that they depend on
the VALUES given to that INSERT. So, the trivialized
schema is:
create function produc
So, I met such a problem: it's impossible to use NEW in a subselect
used in a (non-select) rule. The error is: . Is this a way to do that newertheless (without using of a
function, of course)?
Thanks in advance.
---(end of broadcast)---
TIP 9: the
On Sun, Jul 27, 2003 at 08:47:16AM +0100, Richard Huxton wrote:
>
> No- 'now',now() and CURRENT_TIMESTAMP all stay fixed during a transaction.
> The one that changes is timeofday() I think. See the "Functions and
> Operators" section for details.
Yes, indeed... Documentation describes this. And
On Sat, Jul 26, 2003 at 10:31:44AM -0400, Tom Lane wrote:
> Denis Zaitsev <[EMAIL PROTECTED]> writes:
> > create table xxx (
> > s text,
> > t timestamp
> > default 'now'
> > );
>
> That's a dangerous way to define the
On Sat, Jul 26, 2003 at 03:14:16PM +0100, Richard Huxton wrote:
> On Saturday 26 July 2003 14:39, Denis Zaitsev wrote:
> > In short, the idea this example is to test for is to split a
> > comma-separated value of some text attribute (given to the INSERT
> > operator) and then
In short, the idea this example is to test for is to split a
comma-separated value of some text attribute (given to the INSERT
operator) and then insert a row for each of the parts of that text
value. I've tried to do this thru a nested triggers approach.
create
table xxx (
s text,
t tim
I've found a reason! It's some namespace problem - there are other
tho name_ops operator classes exist. My becomes third. All are the
default for (their) type. And somewhere there is the issue. Renaming
my operator class into, say, name_t_ops resolves the problem.
Thanks for the info.
--
10 matches
Mail list logo
