Tom Lane wrote:
> Bruce Momjian writes:
> > The following attached, applied patch uses E'' for strings containing
> > backslashes in pg_dump. It does not modify COPY data output.
>
> ... ruleutils ...
OK, working on that now. In fact, I am going to add a macro called
something like SQL_STR_DOU
Bruce Momjian writes:
> The following attached, applied patch uses E'' for strings containing
> backslashes in pg_dump. It does not modify COPY data output.
... ruleutils ...
regards, tom lane
---(end of broadcast)---
TIP
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Tom, if you're watching, are you working on this? I can probably spend
> > some time today on it, if that'd be helpful.
>
> I am not; I was hoping you'd deal with SET ROLE. Is it really much
> different from SE
The following attached, applied patch uses E'' for strings containing
backslashes in pg_dump. It does not modify COPY data output.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive,
Oh, just realized after Tom's reply that you were talking about help, not
tab-completion...
On Fri, 1 Jul 2005, Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Bruce Momjian wrote:
Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help doesn't
On Fri, 1 Jul 2005, Bruce Momjian wrote:
Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help doesn't seem to know about the 2PC
command syntax yet.
True.
Should we add support for it? 2PC is not something you normally do
interactively...
Following up a previous thought I had, yesterday I realised how to
return arays nicely without having to make the plperl programmer aware
of anything. The attached patch allows plperl to return an arrayref
where the function returns an array type. It silently calls a perl
function to stringif
This is new version of SELECT FOR UPDATE NOWAIT patch.
Karel
On Sat, 2005-06-25 at 08:40 +0200, Hans-Juergen Schoenig wrote:
> yes, i think we can do it in time.
>
> regards,
>
>hans
>
>
>
> Bruce Momjian wrote:
>
> >Are you working on a updated version of this?
> >
Satoshi Nagayasu wrote:
>Hi all,
>
>Here is a first patch to allow these commands.
>
>
>
>>ALTER TABLE ENABLE TRIGGER
>>ALTER TABLE DISABLE TRIGGER
>>
>>
>
>Bruce said to allow them only super-user,
>but currently this patch allows also the table owner.
>
>
>
It would be convenient if
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, I notice that some but not all the call sites of ereport(ERROR) in
> PL/PgSQL's gram.y set plpgsql_error_lineno. Is there a reason for this?
Without looking at the code, I think it may be that you only need to set
the variable if you want the error t
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> The table owner can drop and create triggers - so why shouldn't they be
> able to enable and disable them?
Not triggers belonging to RI constraints on other tables.
regards, tom lane
---(end of
Pavel Stehule wrote:
this patch allows optional using label with END and END LOOP. Ending label
has only informational value, but can enhance readability large block and
enhance likeness with Oracle.
<>LOOP
...
...
END LOOP<>;
Attached is a revised version of this patch. Changes / comments
On Fri, 1 Jul 2005, Satoshi Nagayasu wrote:
> Hi,
>
> Gavin Sherry wrote:
> > Hmmm.. just thinking about it for a second. I wonder if we should also
> > support:
> >
> > ALTER TABLE DISABLE TRIGGERS
>
> I found some RDBMSes are supporting 'DISABLE TRIGGER ALL TRIGGERS' command.
>
> Does anyone kno
Hi,
Gavin Sherry wrote:
> Hmmm.. just thinking about it for a second. I wonder if we should also
> support:
>
> ALTER TABLE DISABLE TRIGGERS
I found some RDBMSes are supporting 'DISABLE TRIGGER ALL TRIGGERS' command.
Does anyone know about the SQL99 spec?
--
NAGAYASU Satoshi <[EMAIL PROTECTED]
On Fri, 1 Jul 2005, Satoshi Nagayasu wrote:
> Hi all,
>
> Here is a first patch to allow these commands.
>
> > ALTER TABLE ENABLE TRIGGER
> > ALTER TABLE DISABLE TRIGGER
>
Hmmm.. just thinking about it for a second. I wonder if we should also
support:
ALTER TABLE DISABLE TRIGGERS
which woul
On Fri, 1 Jul 2005, Satoshi Nagayasu wrote:
> Hi all,
>
> Here is a first patch to allow these commands.
>
> > ALTER TABLE ENABLE TRIGGER
> > ALTER TABLE DISABLE TRIGGER
There are three other areas which are worth looking at:
a) We may defer the execution of some triggers to the end of the
t
There is one more fix...
> + tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
> + SnapshotNow, 1,
> keys);
'1' was incorrect, must be '2'.
> + tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
>
Thanks for comments, Neil.
Some are fixed.
Neil Conway wrote:
> Also, you should probably skip the simple_heap_update() if the user
> tries to disable an already-disabled trigger, to avoid pointless MVCC
> bloat (and same for enabling an already-enabled trigger, of course).
Do we need some log
Hi,
BTW, the Postgres convention is to submit patches in context diff format
(diff -c).
Satoshi Nagayasu wrote:
+ while (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
+ {
+ HeapTuple newtup = heap_copytuple(tuple);
+ Form_pg_trigger pg_trigger = (
> I said why _shouldn't_. I was agreeing with you.
Oops. Sorry.
I don't know why only super-user shold be able to enable/disable tirggers.
I believe the table owner want to enable/disable triggers,
because I always need it.
Loading huge data set into the table with triggers(or fk) is very pai
Satoshi Nagayasu wrote:
>>The table owner can drop and create triggers - so why shouldn't they be
>>able to enable and disable them?
>
>
> For convenience or easy operation.
>
> I believe the user doesn't like to create same triggers again and again.
I said why _shouldn't_. I was agreeing wi
> The table owner can drop and create triggers - so why shouldn't they be
> able to enable and disable them?
For convenience or easy operation.
I believe the user doesn't like to create same triggers again and again.
Christopher Kings-Lynne wrote:
>>>ALTER TABLE ENABLE TRIGGER
>>>ALTER TABLE
>>ALTER TABLE ENABLE TRIGGER
>>ALTER TABLE DISABLE TRIGGER
>
>
> Bruce said to allow them only super-user,
> but currently this patch allows also the table owner.
The table owner can drop and create triggers - so why shouldn't they be
able to enable and disable them?
Chris
---
Hi all,
Here is a first patch to allow these commands.
> ALTER TABLE ENABLE TRIGGER
> ALTER TABLE DISABLE TRIGGER
Bruce said to allow them only super-user,
but currently this patch allows also the table owner.
If we need to restrict these operations,
we have to add more user checks.
> From
24 matches
Mail list logo
