SEO

Hello Heikki,

On Sat, 29 Mar 2008 11:49:56 +0000 Heikki Linnakangas wrote:

> Regarding the patch itself: You define rule "opt_if_not_exists", but
> never use it. And you add a new rule for "CREATE LANGUAGE ... HANDLER
> ...", but forgot "IF_P NOT EXISTS" from the end of that. Looks like you
> couldn't decide which approach to take, and ended up doing a little bit
> of both ;-).

Now that you say it: yes, i tested a bit around, how to implement this
feature. But since my current approach is wrong, i have to change this
anyway.


Thank you for pointing this out.

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Hello all,

sorry, was off yesterday and i'm just reading all your answers.

On Sat, 29 Mar 2008 22:35:21 -0400 Tom Lane wrote:

> I wrote:
> > ... However, I seem to recall
> > that in the discussions leading up to implementing DROP IF EXISTS,
> > we considered and specifically rejected CREATE IF NOT EXISTS. Don't
> > have time right now to troll the archives for the reasoning.
>
> [ back from dinner party... ] Here's the thread I was remembering:
> http://archives.postgresql.org/pgsql...0/msg00632.php
>
> The key argument seems to be that it's quite unclear what the state
> following CREATE IF NOT EXISTS (CINE) should be, if the object does
> exist but not with the same properties specified in the CINE command.
> CREATE OR REPLACE resolves that by making it clear that it's gonna be
> what the command says.

Tom: this answers my other question: if someone executes a REPLACE
LANGUAGE and as example is using another handler, the new handler
should replace the old one. Correct?

So i will change my small patch and reimplement this extension with
CREATE OR REPLACE.


Thanks all for your useful answers.

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

On Sat, 29 Mar 2008 22:35:21 -0400 Tom Lane wrote:

> The key argument seems to be that it's quite unclear what the state
> following CREATE IF NOT EXISTS (CINE) should be, if the object does
> exist but not with the same properties specified in the CINE command.
> CREATE OR REPLACE resolves that by making it clear that it's gonna be
> what the command says. Perhaps there is a use-case for the alternate
> behavior where the pre-existing object doesn't get modified, but I'm
> not too sure what it would be.

Attached is a first version for the "CREATE OR REPLACE LANGUAGE" patch.
It's still missing some functionality (especially the update part is
far away from being complete) and it's also missing documentation.

I just want to know if i'm heading in the right direction or if
something is totally broken in my basic approach:


In case a language is already in pg_pltemplate, the (possibly changed)
values from this table are used to update the pg_languages entry. This
gives the ability to change the owner, trust status, the language or
validator handler.

In case the language is not in pg_pltemplate, the values from the
commandline are used, just like "create language".



Thanks & kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group


--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

"Andreas 'ads' Scherbaum" <adsmail@wars-nicht.de> writes:
> Attached is a first version for the "CREATE OR REPLACE LANGUAGE" patch.
> It's still missing some functionality (especially the update part is
> far away from being complete) and it's also missing documentation.

It strikes me that if there are any existing functions in the language,
we might want to restrict what can be changed by CREATE OR REPLACE.
For instance switching to a completely different language handler
doesn't seem like a great idea.

The equivalent problem for views and functions is handled by restricting
CREATE OR REPLACE to not change the output column set of a view or the
type signature of a function, independently of whether there are any
actual references to the object. So maybe the right thing is that
CREATE OR REPLACE LANGUAGE can change "inessential" properties of an
existing language, but not the core properties --- which might only be
the handler function, though you could make a case for the validator and
the trusted flag as well.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Hello,

On Sat, 03 May 2008 13:34:05 -0400 Tom Lane wrote:

> So maybe the right thing is that CREATE OR REPLACE LANGUAGE can change
> "inessential" properties of an existing language, but not the core
> properties --- which might only be the handler function, though you
> could make a case for the validator and the trusted flag as well.

Already thought about that: exchanging the handler function or the
libbrary might only be useful in a developing environment, i don't see
other use cases here. The same is true for the validator (but a missing
validator could be added afterwards) and in my opinion i would prefer
not to change the trust flag - some functions may depend on this.

The name cannot be changed at all so only the owner and maybe the
validator is left ...

Did i miss something?


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> The equivalent problem for views and functions is handled by restricting
> CREATE OR REPLACE to not change the output column set of a view or the
> type signature of a function, independently of whether there are any
> actual references to the object. So maybe the right thing is that
> CREATE OR REPLACE LANGUAGE can change "inessential" properties of an
> existing language, but not the core properties --- which might only be
> the handler function, though you could make a case for the validator and
> the trusted flag as well.

I'm not so sure. What about if a PL language wants to include a version number
in the language handler? Or if a new version has to change the name for some
reason -- perhaps they discover that the old name doesn't work on some linkers
for some reason.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> ... So maybe the right thing is that
>> CREATE OR REPLACE LANGUAGE can change "inessential" properties of an
>> existing language, but not the core properties --- which might only be
>> the handler function, though you could make a case for the validator and
>> the trusted flag as well.

> I'm not so sure. What about if a PL language wants to include a version number
> in the language handler? Or if a new version has to change the name for some
> reason -- perhaps they discover that the old name doesn't work on some linkers
> for some reason.

Not sure that I find those cases convincing. Remember that what CREATE
OR REPLACE LANGUAGE is going to be referring to is the handler
function's SQL-level name; there's already a layer of indirection
between it and link-level issues.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

On Sat, 3 May 2008 21:12:51 +0200 Andreas 'ads' Scherbaum wrote:
> On Sat, 03 May 2008 13:34:05 -0400 Tom Lane wrote:
>
> > So maybe the right thing is that CREATE OR REPLACE LANGUAGE can change
> > "inessential" properties of an existing language, but not the core
> > properties --- which might only be the handler function, though you
> > could make a case for the validator and the trusted flag as well.
>
> Already thought about that: exchanging the handler function or the
> libbrary might only be useful in a developing environment, i don't see
> other use cases here. The same is true for the validator (but a missing
> validator could be added afterwards) and in my opinion i would prefer
> not to change the trust flag - some functions may depend on this.
>
> The name cannot be changed at all so only the owner and maybe the
> validator is left ...

Even the owner does not make sense, because it seems it is not possible
that the owner will changed through the SQL interface. ALTER LANGUAGE
already exists for this purpose and CREATE LANGUAGE has no option for
the language owner.

So do we want to replace any data (in my opinion only the validator is
left) at all or just skip any error message?


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

On Sat, 10 May 2008 09:36:26 +0200 Andreas 'ads' Scherbaum wrote:

> On Sat, 3 May 2008 21:12:51 +0200 Andreas 'ads' Scherbaum wrote:
> > On Sat, 03 May 2008 13:34:05 -0400 Tom Lane wrote:
> >
> > > So maybe the right thing is that CREATE OR REPLACE LANGUAGE can change
> > > "inessential" properties of an existing language, but not the core
> > > properties --- which might only be the handler function, though you
> > > could make a case for the validator and the trusted flag as well.
> >
> > Already thought about that: exchanging the handler function or the
> > libbrary might only be useful in a developing environment, i don't see
> > other use cases here. The same is true for the validator (but a missing
> > validator could be added afterwards) and in my opinion i would prefer
> > not to change the trust flag - some functions may depend on this.
> >
> > The name cannot be changed at all so only the owner and maybe the
> > validator is left ...
>
> Even the owner does not make sense, because it seems it is not possible
> that the owner will changed through the SQL interface. ALTER LANGUAGE
> already exists for this purpose and CREATE LANGUAGE has no option for
> the language owner.

Attached is another version of the patch (still missing documentation),
which changes the language owner on update (the owner can still be
changed in pg_pltemplate).


> So do we want to replace any data (in my opinion only the validator is
> left) at all or just skip any error message?

Anyone has an opinion here?


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group


--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Andreas 'ads' Scherbaum wrote:
> Attached is another version of the patch (still missing documentation),
> which changes the language owner on update (the owner can still be
> changed in pg_pltemplate).

The other CREATE OR REPLACE commands don't change the owner, so CREATE
OR REPLACE LANGUAGE shouldn't do that either.

>> So do we want to replace any data (in my opinion only the validator is
>> left) at all or just skip any error message?

I think you should be able to change handler and validator functions,
and the trusted flag. Or is there a reason to not allow that?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches