On Tue, Nov 24, 2009 at 2:07 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> If it did so, that would be outside the apparent meaning of the
>> command, which is to do nothing if an object of that name exists.
>> That's why we've gone with CREATE OR REPLACE instead.
>
> I think that "fail on exi
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Yes, I'd expect the user to custom-code it, because it's not clear
>> exactly which properties the script would be depending on and which
>> ones it's okay to allow to vary. To take just one example, is it
>> okay if the object ownership is different
Scott Marlowe writes:
> On Tue, Nov 24, 2009 at 11:34 AM, Tom Lane wrote:
>> The point would be to reduce the risk that you're changing the language
>> definition in a surprising way. Extra args would imply that you're
>> trying to install a non-default definition of the language.
> But if you'
Tom Lane wrote:
> If it did so, that would be outside the apparent meaning of the
> command, which is to do nothing if an object of that name exists.
> That's why we've gone with CREATE OR REPLACE instead.
I think that "fail on existence of an object conflicting with given
definition" is behav
On Tue, Nov 24, 2009 at 11:34 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane wrote:
>>> But actually I thought we had more or less concluded that CREATE OR
>>> REPLACE LANGUAGE would be acceptable (perhaps only if it's given
>>> without any extra args?).
Robert Haas writes:
> On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane wrote:
>> But actually I thought we had more or less concluded that CREATE OR
>> REPLACE LANGUAGE would be acceptable (perhaps only if it's given
>> without any extra args?).
> I'm not sure there's any value in that restriction - s
"Kevin Grittner" writes:
> Tom Lane wrote:
>> The argument against CINE is that it's unsafe.
> By no means rhetorically, is that based on the assumption that the
> statement would not validate that the existing object (if any) matches
> the supplied definition?
If it did so, that would be outs
On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> So we're conceding that this is a valid need and people will now have
>> a way to meet it. Is the argument against having CINE syntax that it
>> would be more prone to error than the above, or that the code would be
Tom Lane wrote:
> The argument against CINE is that it's unsafe.
By no means rhetorically, is that based on the assumption that the
statement would not validate that the existing object (if any) matches
the supplied definition?
> The fragment proposed by Andrew is no safer, of course, but it
"Kevin Grittner" writes:
> So we're conceding that this is a valid need and people will now have
> a way to meet it. Is the argument against having CINE syntax that it
> would be more prone to error than the above, or that the code would be
> so large and complex as to create a maintenance burden
Andrew Dunstan wrote:
> Part of the motivation for allowing inline blocks was to allow for
> conditional logic. So you can do things like:
>
> DO $$
>
> begin
> if not exists (select 1 from pg_tables
> where schemaname = 'foo'
> and tablenam
On Tue, 2009-11-24 at 09:46 +, Thom Brown wrote:
> 2009/11/24 Hannu Krosing
> On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
> > Craig Ringer writes:
> > > I do think this comes up often enough that a built-in
> trigger "update
> > > named column wi
2009/11/24 Hannu Krosing
> On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
> > Craig Ringer writes:
> > > I do think this comes up often enough that a built-in trigger "update
> > > named column with result of expression on insert" trigger might be
> > > desirable.
> >
> > There's something o
On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
> Craig Ringer writes:
> > I do think this comes up often enough that a built-in trigger "update
> > named column with result of expression on insert" trigger might be
> > desirable.
>
> There's something of the sort in contrib already, I believe
On 23/11/2009 11:35 PM, Tom Lane wrote:
> Andrew Gierth writes:
>> "Tom" == Tom Lane writes:
>> Tom> Well, that's pretty much exactly the question --- are there? It
>> Tom> would certainly make it easier for someone to exploit any other
>> Tom> security weakness they might find.
>
>> Loops i
> "Tom" == Tom Lane writes:
>> Loops in plain SQL are no problem: see generate_series. The last
>> time we discussed this I demonstrated reasonably straightforward
>> SQL examples of how to do things like password-cracking (and that
>> was long before we had CTEs, so it would be even easi
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Well, that's pretty much exactly the question --- are there? It
> Tom> would certainly make it easier for someone to exploit any other
> Tom> security weakness they might find.
> Loops in plain SQL are no problem: see generate_series.
Tom Lane wrote:
Thom Brown writes:
As for having plpgsql installed by default, are there any security
implications?
Well, that's pretty much exactly the question --- are there? It would
certainly make it easier for someone to exploit any other security
weakness they might find. I
> "Tom" == Tom Lane writes:
> Thom Brown writes:
>> As for having plpgsql installed by default, are there any security
>> implications?
Tom> Well, that's pretty much exactly the question --- are there? It
Tom> would certainly make it easier for someone to exploit any other
Tom> secur
2009/11/23 Tom Lane
> Thom Brown writes:
> > As for having plpgsql installed by default, are there any security
> > implications?
>
> Well, that's pretty much exactly the question --- are there? It would
> certainly make it easier for someone to exploit any other security
> weakness they might
Thom Brown writes:
> As for having plpgsql installed by default, are there any security
> implications?
Well, that's pretty much exactly the question --- are there? It would
certainly make it easier for someone to exploit any other security
weakness they might find. I believe plain SQL plus SQL
On Sun, Nov 22, 2009 at 11:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane wrote:
>>> CREATE IF NOT EXISTS has been proposed and rejected before, more than
>>> once. Please see the archives.
>
>> Search for CINE to find the discussions. This is a good
2009/11/23 Tom Lane
> CREATE OR REPLACE has got far safer semantics from the viewpoint of a
> script that wants to bull through without having any actual error
> handling (which is more or less the scenario we are arguing here, no?)
> After successful execution of the command you know exactly wha
On Sun, Nov 22, 2009 at 10:41 PM, Craig Ringer
wrote:
> Tom Lane wrote:
> It'd be a HUGE benefit in deployment and update scripts to have PL/PgSQL
> installed and available by default, at least to the superuser and to
> the DB owner.
Are there any known security problems with plpgsql?
--
Sent
Tom Lane wrote:
> Andrew Dunstan writes:
>> Part of the motivation for allowing inline blocks was to allow for
>> conditional logic.
>
> I don't think that argument really applies to this case, because the
> complaint was about not being sure if plpgsql is installed. If it
> isn't, you can hard
On Sun, Nov 22, 2009 at 10:19 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Part of the motivation for allowing inline blocks was to allow for
>> conditional logic.
>
> I don't think that argument really applies to this case, because the
> complaint was about not being sure if plpgsql is instal
Andrew Dunstan writes:
> Part of the motivation for allowing inline blocks was to allow for
> conditional logic.
I don't think that argument really applies to this case, because the
complaint was about not being sure if plpgsql is installed. If it
isn't, you can hardly use a plpgsql DO block to
Tom Lane wrote:
[ thinks for awhile... ] Actually, CREATE LANGUAGE is unique among
creation commands in that the common cases have no parameters, at least
not since we added pg_pltemplate. So you could imagine defining CINE
for a language as disallowing any parameters and having these semanti
Robert Haas writes:
> On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane wrote:
>> CREATE IF NOT EXISTS has been proposed and rejected before, more than
>> once. Please see the archives.
> Search for CINE to find the discussions. This is a good place to start:
> http://archives.postgresql.org/pgsql-hac
On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane wrote:
> Craig Ringer writes:
>> I do think this comes up often enough that a built-in trigger "update
>> named column with result of expression on insert" trigger might be
>> desirable.
>
> There's something of the sort in contrib already, I believe, tho
> MySQL had the following syntax available:
> `updated_date` timestamp NOT NULL default CURRENT_TIMESTAMP on update
> CURRENT_TIMESTAMP
I wonder supporting this syntax would speed things up a little bit.
Here's a simple benchmark about the situation we are discussing here:
There are 2 tables:
Craig Ringer writes:
> I do think this comes up often enough that a built-in trigger "update
> named column with result of expression on insert" trigger might be
> desirable.
There's something of the sort in contrib already, I believe, though
it's so old it still uses abstime :-(
> So might "CRE
2009/11/22 Craig Ringer
> On 23/11/2009 4:15 AM, Scott Marlowe wrote:
> > On Sun, Nov 22, 2009 at 12:50 PM, Thom Brown
> wrote:
> >> Hi,
> >> This should be simple, but for some reason I'm not quite sure what the
> >> solution is. I want to be able to update the value of a column for rows
> >>
On 23/11/2009 4:15 AM, Scott Marlowe wrote:
> On Sun, Nov 22, 2009 at 12:50 PM, Thom Brown wrote:
>> Hi,
>> This should be simple, but for some reason I'm not quite sure what the
>> solution is. I want to be able to update the value of a column for rows
>> that have been updated. More specifical
34 matches
Mail list logo
