I've been running a few functions within schema's. It's annoying that
everything needs to be qualified as it doesn't allow the functions to be
moved very easily.
Would it be appropriate for the function to have it's own schema as
pre-pended onto the user path while in the users function?
--
RAISE seems to be quite wonky.
The below function fails to compile due to the function call in the
arguement.
create function test(text)
returns bool
as '
begin
raise exception ''test %'', quote_literal($1);
return false;
end;
' language plpgsql;
Likewise, the below fails to compil
On Sun, 2002-07-14 at 20:36, Rod Taylor wrote:
> I've been running a few functions within schema's. It's annoying that
> everything needs to be qualified as it doesn't allow the functions to be
> moved very easily.
>
>
> Would it be appropriate for the function to have it's own schema as
> pre-
Rod Taylor <[EMAIL PROTECTED]> writes:
> Likewise, the below fails to compile due to error message being an
> expression. I know this one used to work not all that long ago.
> Digging through 7.0 docs even found an example of it.
No, it never worked; that's why it was taken out of the docs.
Th
Rod Taylor <[EMAIL PROTECTED]> writes:
> I've been running a few functions within schema's. It's annoying that
> everything needs to be qualified as it doesn't allow the functions to be
> moved very easily.
> Would it be appropriate for the function to have it's own schema as
> pre-pended onto th
On Sun, 2002-07-14 at 21:19, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I've been running a few functions within schema's. It's annoying that
> > everything needs to be qualified as it doesn't allow the functions to be
> > moved very easily.
> > Would it be appropriate for the f
OK,
DROP COLUMN now seems to work perfectly. All the old test cases that failed
now work fine.
However, I'm not happy with the way dropped columns are renamed. I want to
give them a name that no-one would ever want to use as a legit column name.
I don't like this behaviour:
test=# create tabl
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> However, I'm not happy with the way dropped columns are renamed.
Okay...
> We could name the fields "dropped_x" sort of thing perhaps
In practice that would certainly work, especially if we increase
NAMEDATALEN to 128 or so, as
On Mon, 15 Jul 2002, Christopher Kings-Lynne wrote:
> However, I'm not happy with the way dropped columns are renamed. I want to
> give them a name that no-one would ever want to use as a legit column name.
> ...
> We could name the fields "dropped_x" sort of thing perhaps
I suggest
> > We could name the fields "dropped_x" sort of thing perhaps
>
> In practice that would certainly work, especially if we increase
> NAMEDATALEN to 128 or so, as has been proposed repeatedly.
Well, x is just an integer anyway, so even with 32 it's not a problem...
In case anyone was
On Mon, 2002-07-15 at 06:06, Christopher Kings-Lynne wrote:
> > > We could name the fields "dropped_x" sort of thing perhaps
> >
> > In practice that would certainly work, especially if we increase
> > NAMEDATALEN to 128 or so, as has been proposed repeatedly.
>
> Well, x is just an i
> > etc. I put that extra number after dropped and not at the end
> so prevent it
> > being off the end of a 32 character name.
> >
> > > Alternatively, we could invest a lot of work to make it possible for
> > > attname to be NULL, but I don't see the payoff...
> >
> > Yeah, I think a weird name
12 matches
Mail list logo
