Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>>It made me wonder why don't we always create internal functions this
>>way, or at least all except a core set of bootstrapped functions.
>
> I don't believe it will actually work: you *must* add an internal
> function to include/catalog/
Joe Conway <[EMAIL PROTECTED]> writes:
> It made me wonder why don't we always create internal functions this
> way, or at least all except a core set of bootstrapped functions.
I don't believe it will actually work: you *must* add an internal
function to include/catalog/pg_proc.h, or it won't g
I was trying to see if it was possible to create an 'internal' function
after bootstrap (i.e. without listing in pg_proc.h). The test case below
illustrates that it is indeed possible.
test=# CREATE OR REPLACE FUNCTION mytest(text,int,int) RETURNS text AS
'text_substr' LANGUAGE 'internal' IMMU
The answer from H2 (Jim Melton).
When this feature was being voted on, some vendors had "cascade" as a default,
others had "restrict". So, the compromise was not to define a default.
As such providing a "default" is a vendor extension and compliance simply
requires we also support the standard
Bruce Momjian <[EMAIL PROTECTED]> writes:
> How about:
>> DropFoo --- top level, corresponds to SQL DROP command
>> DropCascadeFoo --- dependency controller
>> RemoveFoo--- bottom level deleter
There is only one dependency controller; it's not Foo anything.
And I don't want to
J. R. Nield wrote:
> On Sat, 2002-07-13 at 02:25, Tatsuo Ishii wrote:
> > > (2) At least in the current CVS version, the code to do a 'CHECKPOINT'
> > > after creating a table has been #ifdef'ed out. Why is that?
> >
> > That is not after creation of a table, but while creating it, which is
On Sat, 2002-07-13 at 02:25, Tatsuo Ishii wrote:
> > (2) At least in the current CVS version, the code to do a 'CHECKPOINT'
> > after creating a table has been #ifdef'ed out. Why is that?
>
> That is not after creation of a table, but while creating it, which is
> not necessary any more sinc
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> The correct thing to do is to call performDeletion() with a parameter
>
> > Should it be called performDrop rather than Deletion?
>
> Well, if you want to rationalize the naming of these various routines:
>
> I think DROP ought to
Tom Lane dijo:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I encountered a problem while implementing new CREATE
> > CONVERSION. Since converion procs are dynamically invoked while doing
> > an encoding conversion, it might fail for some reasons:
>
> > (2) buggy conversion proc is defined by
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I encountered a problem while implementing new CREATE
> CONVERSION. Since converion procs are dynamically invoked while doing
> an encoding conversion, it might fail for some reasons:
> (1) stale pg_conversion entry. If someone re-register that proc, the
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Is it at all a problem that several columns in pg_conversion have the same
> name as columns in pg_constraint?
> Should the ones in pg_conversion become: convname instead of conname, etc.
> simply for clarity?
Perhaps so. The two patches we
Rod Taylor <[EMAIL PROTECTED]> writes:
> Yup. Makes sense. I submitted a patch which retains the difference.
> If the index is created with CREATE UNIQUE, it's dumped with CREATE
> UNIQUE. Constraint UNIQUE is treated likewise.
Yes, I was going to suggest that --- we should try to reproduce t
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> The correct thing to do is to call performDeletion() with a parameter
> Should it be called performDrop rather than Deletion?
Well, if you want to rationalize the naming of these various routines:
I think DROP ought to be associated with the SQL-leve
Rod Taylor wrote:
> On Sat, 2002-07-13 at 10:29, Bruce Momjian wrote:
> > Rod Taylor wrote:
> > > > > I prefer ...add constraint. After a while (release or 2) removal of
> > > > > create unique index all together.
> > > >
> > > > Remove CREATE UNIQUE INDEX entirely? Why?
> > >
> > > I was look
On Sat, 2002-07-13 at 10:29, Bruce Momjian wrote:
> Rod Taylor wrote:
> > > > I prefer ...add constraint. After a while (release or 2) removal of
> > > > create unique index all together.
> > >
> > > Remove CREATE UNIQUE INDEX entirely? Why?
> >
> > I was looking to encourage users to use core
On Sat, 2002-07-13 at 10:27, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I noticed that SERIAL sequences aren't dropping with the application of
> > the patch.
>
> > Was this intentional?
>
> Yeah, the dependency isn't stored yet. I didn't like the way you did
> that, and was t
Iavor Raytchev wrote:
> Hello,
>
> I somehow feel that I do not know anymore what are the current expectations
> for a release date for 7.3.
Beta freeze September 1, final release October/November, is my guess.
> And when do you think it will be stable enough so that testing of interfaces
> (li
> > So, what should the behavior be of a constant declared as
> > CHAR 'hi'
> > ? Right now it fails, since SQL9x asks that the char type defaults to a
> > length of one and our parser does not distinguish between usage as a
> > constant declaration and as a column definition (where you would want
Rod Taylor wrote:
> > > I prefer ...add constraint. After a while (release or 2) removal of
> > > create unique index all together.
> >
> > Remove CREATE UNIQUE INDEX entirely? Why?
>
> I was looking to encourage users to use core SQL as I spend more time
> than I want converting between syste
Rod Taylor <[EMAIL PROTECTED]> writes:
> I noticed that SERIAL sequences aren't dropping with the application of
> the patch.
> Was this intentional?
Yeah, the dependency isn't stored yet. I didn't like the way you did
that, and was trying to think of a better way...
More generally, a lot of d
Rod Taylor <[EMAIL PROTECTED]> writes:
>> Which of these are done with the patch?
> Below is what I listed off as complete when submitting the patch.
Note that I have not yet finished committing all of Rod's original
patch.
regards, tom lane
---(
Hello,
I somehow feel that I do not know anymore what are the current expectations
for a release date for 7.3.
And when do you think it will be stable enough so that testing of interfaces
(like pgaccess) will be meaningful (is this the period you call 'slow
down').
Iavor
--
www.pgaccess.org
22 matches
Mail list logo
