Is anyone actually working on Postgres-R ? Last git commit was in January 2011.
What are the chances of it getting integrated with the core, which it
is probably targeted for ?
If I picked it up, and tried to make usable for my own needs - instead
of implementing trigger/log (slony like) multi
I'm guessing I won't get much more from devs , without providing more
info here which unfortunately has been lost.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2011/9/13 Merlin Moncure mmonc...@gmail.com:
2011/9/13 Grzegorz Jaśkiewicz gryz...@gmail.com:
I'm guessing I won't get much more from devs , without providing more
info here which unfortunately has been lost.
yup -- you destroyed all the evidence. if it happens again, try
posting some more
It probably won't fix it, but you'll avoid possible issues in the future.
However you should look at possibly upgrading to 8.4 or later, as 8.0
is either out of its support life, or getting close to it.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
So here's the thing. I got a message from one of the developers, that
running 'create temporary sequence xyz;' hangs on the database.
That seemed suspicious. I tried running any ddl command, and that hang.
No other connections to the database.
It turned out that it had a power failure earlier in
2011/9/12 Merlin Moncure mmonc...@gmail.com:
It seems odd that you could not create a temp sequence but you were
able to reindex the entire database. did you confirm you were
blocking on a non-granted lock?
I could revacuum/reindex all stuff, only if I had to do the system
catalogues first.
On Thu, Sep 1, 2011 at 11:14 AM, Sim Zacks s...@compulab.co.il wrote:
On 09/01/2011 12:26 PM, Pavel Stehule wrote:
Hello
postgres=# create table tt(a int, b varchar);
CREATE TABLE
postgres=# insert into tt values(10,'hello');
INSERT 0 1
postgres=# select
Alternatively you can get the 'server' package from app store, it has
postgresql already in it :) (9.0)
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
what you probably looking for is formatting the output into a string.
Postgresql will store it as 2.3, because that is what 2.30 is anyway.
Its up to you to format it before passing it on to the user/business
logic/whatever.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
On Mon, Jun 27, 2011 at 4:12 PM, F T ouk...@gmail.com wrote:
Hello list,
I use PostgreSQL 8.4 and Postgis 1.4.
I use FME to insert 772185 records in a table (multipolygons that represent
parcels).
Everything seems fine but...
If I type select count(*), I get the right number of records :
The answer is: SSL. SSL will compress things, before encrypting
(depends on setup obviously).
As far as I know, postgresql it self doesn't compress any data over the wire.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#comp
That applies in general to SSL apps.
In cryptography it is always recommended, and sometimes even mandatory
to compress data before encryption. This reduces the risk of finding
patterns, etc.
And SSL includes that option as well.
But that's
It could be worth considering 9.1. Probably by the time you get
production ready version, 9.1 will be already stable (few months I
guess).
The usual answer to that question is - it will be ready when its ready.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
Cursors only see the data that is the effect of the query. That output
doesn't get updated. It would actually be pretty bad if that was the
case.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
There's a generic trigger that sends a signal to a process whenever
changes are made (via listen/notify mechanism), but when FK cascade
fires it will cause a mass amount of notifies to be send out and I
want to avoid it.
2011/3/18 David Johnston pol...@yahoo.com:
Don't know if this would work
Considering the following example.
Tables A and B.
Table A contains some data.
Table B reefers to table A using FK with 'on delete cascade'. Table B
has a trigger on it, after delete per row
Now, is there any way I can tell in the trigger on table B that it has
been called from a direct delete on
On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe scott_r...@elevated-dev.com wrote:
On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
* simple to generate, and 128bit random is almost globally unique,
Almost? Should be totally unique, as long as your random source is decent
quality.
But I
On Wed, Jan 5, 2011 at 3:03 PM, Mike Christensen m...@kitchenpc.com wrote:
2011/1/5 Grzegorz Jaśkiewicz gryz...@gmail.com:
On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe scott_r...@elevated-dev.com
wrote:
On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
* simple to generate, and 128bit
I don't think planner should do things like creating an index. But it
might hint at doing it in the logs.
There was a discussion around that sort of feature on -hackers not so
long time ago. I don't remember what the conclusion was, but probably
that it just isn't worth wasting planner's cycles
lookup CASE WHEN END in docs.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in some other.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
2010/11/24 Florian Weimer fwei...@bfk.de:
* Grzegorz Jaśkiewicz:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in some other
Timing is on.
psql (9.1devel)
Type help for help.
# select count(hashtext(a::text)) FROM generate_series(1,1) a;
count
---
1
(1 row)
Time: 106.637 ms
# select count(hashtext(a::text)) FROM generate_series(1,100) a;
count
-
100
(1 row)
Time: 770.823 ms
# select
read documentation on backups.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
try gdb --args ./pg_upgrade -d /var/pgsql-8_4_3/data/ -D
/var/pgsql-9_0_1/data/ -b /var/pgsql-8_4_3/bin/ -B
/var/pgsql-9_0_1/bin/ --check -P 5433 -v -g -G debug
and when it fails, type in 'bt' and paste it here please.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
OLD.column_name
NEW.column_name ?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/10/20 Merlin Moncure mmonc...@gmail.com:
In recent versions of postgres (I think 8.4+?) you can add columns to
the view via create/replace (not drop of course). This greatly
reduces the practical annoyances of dropping view dependencies, at
least for me...
Ok, We're still on 8.3 here,
On Tue, Oct 19, 2010 at 3:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ravi Katkar ravi.kat...@infor.com writes:
Is there any feature to drop the view with out cascading the dependents.
No. But why don't you use CREATE OR REPLACE VIEW?
only caveat is, it won't work if he adds/removes any
select regexp_replace(myval, E'(\\D)', '', 'g') from foo;
for added speed, you might consider this:
CREATE INDEX ON foo((regexp_replace(myval, E'(\\D)', '', 'g'))::bigint);
which is also going to protect you against inserts where value doesn't
contain any digits.
and added benefit of index:
you can pass in/out very large set of data inside a transaction by
using temp tables. Temporary tables are one of the greatest features
of SQL dbs.
Here's one fact, it most often takes as long to transfer data from/to
a query/function as it takes to execute it. By storing data on the
server side,
If you use QT, it has PG connector classes I believe (it had in 3.x).
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
no you can't
but you have have multiple clusters running at the same time on the
same box. Just set them up on different ports, and in different
directories.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
Use JOIN sherlock.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I got bitten Today by 'alter table disable trigger all' vs 'trigger user'.
Basically , assuming that psql doesn't show me that FKs are disabled
some code was using 'trigger all' instead of 'user'.
Is that a bug of psql, or a feature ? As far as I can see
pg_catalog.pg_constraint doesn't contain
2010/9/29 Tom Lane t...@sss.pgh.pa.us:
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com writes:
I got bitten Today by 'alter table disable trigger all' vs 'trigger user'.
Basically , assuming that psql doesn't show me that FKs are disabled
some code was using 'trigger all' instead of
prior to 8.4 not in will be slow. Just use left join.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Tue, Sep 28, 2010 at 12:37 AM, Tim Uckun timuc...@gmail.com wrote:
If the table is large, I sometimes use the following pattern:
The table is very large so I will use your advice thanks.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
or even better, learn English properly and contribute your translation.
I'm not whining that there's no Polish translation.
French people are somewhat specific in that matter, don't get me
started on aviation (cos it drives me insane).
--
Sent via pgsql-general mailing list
2010/9/23 Raymond O'Donnell r...@iol.ie:
On 23/09/2010 13:55, Grzegorz Jaśkiewicz wrote:
or even better, learn English properly and contribute your translation.
I'm not whining that there's no Polish translation.
French people are somewhat specific in that matter, don't get me
started
try reindex database;
and move away from 7.4, it is unsupported, and ancient history.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I wonder if there's an equivalent of gcore on windows. If there is, it
might be useful.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
show us explain analyze on this
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Jun 30, 2010 at 2:41 PM, Andrea Lombardoni and...@lombardoni.ch wrote:
You need to use EXECUTE for the INSERT statement as well per error:
CONTEXT: SQL statement INSERT INTO idmap (oldid, type, newid) VALUES(1,
1, 1) PL/pgSQL function test line 16 at SQL statement
Thanks, this
On Wed, Jun 23, 2010 at 7:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown thombr...@gmail.com writes:
Yes, I'm still not exactly sure why it's seeing uncommitted changes. :/
Because it's all one transaction. A transaction that couldn't see its
own changes wouldn't be very useful.
I
because in my case I have many tables with FK pointing at foob. So
writing that many triggers is going to be a royal pain.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
that Id refers to 'name' column that I need. There still is FK on it,
so basically it is broken inside transaction, from trigger's
perspective.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
it is slightly more complicated than that, cos I need information from
fooA too. So we have a chicken and egg problem.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I'll fix it this way:
CREATE TABLE foob(id serial primary key, name varchar default '');
CREATE TABLE fooA(id serial primary key, fooBook int not null
references fooB(id) on update cascade on delete cascade DEFERRABLE,
name varchar default '');
CREATE FUNCTION foobarrB() RETURNS trigger AS
$_$
consider following example:
CREATE TABLE foob(id serial primary key, name varchar default '');
CREATE TABLE fooA(id serial primary key, fooB int not null references
fooB(id) on update cascade on delete cascade, name varchar default
'');
CREATE FUNCTION foobarrA() RETURNS trigger AS
$_$
BEGIN
this is 8.3.7, for the record. And no, They won't let me update it to 8.3.11 :/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
any ideas than, how can make it actually do what I wanted it to do please ?
Making FK deferrable doesn't help.
thanks.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
nope, that's not the thing. This is just specific to my example. But
production code I have, doesn't have such confusing name, and still
fails.
Plus postgresql doesn't rely on names, but on oids rather.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
not really, as it depends on pretty much both tables.
This is where de-normalization would actually makes sens, except for
that it wouldn't - because it will badly effect all my other queries
(joining on varchar is so slow).
I could drop FK, and replace that with my own trigger(s), but that's a
well, change foob column name to something else, and try yourself. It
still fails.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
the delete will succeed.
That's not the point of the exercise tho.
The point, is to print name in trigger, rather than null!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
it is confusing to me, because I thought triggers are firring BEFORE
anything goes away. So I assume that all data is still going to be
visible to the trigger, as it is firing BEFORE. The only thing is, it
looks like the FKs are doing the deletion and than things are handed
over to triggers.
--
I do understand what you are saying, but still it is highly
unintuitive. Since trigger is BEFORE, developer will expect that data
to be there.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Tue, May 25, 2010 at 11:15 AM, Alban Hertroys
dal...@solfertje.student.utwente.nl wrote:
On 25 May 2010, at 11:38, Malm Paul wrote:
Hi,
I'm trying to update postgresql ver 8.7.3 to 8.4.4
I know it's totally unrelated, but when did it become popular to send (HTML)
messages in a very
every single query in postrgresql runs as a transaction, on top of it,
some are atomic, like when you use RETURNING statement. This is
because postgresql doesn't actually have to select these rows as
separate query.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
by default query is wrapped in a transaction (if it is not run under a
transaction). And this will be default transaction isolation level.
some people think it works magic, but that's not true.
find in docs part that talks about transaction isolation levels, and
translate it to your problem.
--
don't lock tables explicitly. That's a killer for (concurrent) performance.
Just write queries properly, and use appropriate transaction level.
And you are sorted.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
anyone please ?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
no it is not slony related.
It is a postgresql problem.
my original post:
http://archives.postgresql.org/pgsql-general/2010-05/msg00402.php
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Wed, May 12, 2010 at 10:57 AM, Glyn Astill glynast...@yahoo.co.uk wrote:
Hi Grzegorz,
Is it always the same OID(s)?
Usually this means something somewhere has a link to an OID that has been
removed.
You could try digging through pg_catalog lookng for an oid column that refers
to the
On Wed, May 12, 2010 at 11:09 AM, Alban Hertroys
dal...@solfertje.student.utwente.nl wrote:
On 12 May 2010, at 12:01, Glyn Astill wrote:
Did you not mention that this server was a slony slave at some point though?
Just because you have removed slony, and the error comes from postgresql
2010/5/12 Glyn Astill glynast...@yahoo.co.uk:
--- On Wed, 12/5/10, Grzegorz Jaśkiewicz gryz...@gmail.com wrote:
Alban Hertroys
dal...@solfertje.student.utwente.nl
wrote:
On 12 May 2010, at 12:01, Glyn Astill wrote:
Did you not mention that this server was a slony
slave at some point
If you think about it, NULL is not a value.
It makes sens that it allows multiple NULLs.
If you don't agree, than your SQL point of view doesn't match the
majority, and your designs won't fit in the SQL paradigm .
I think it is just a matter of experimenting, and experience to see
how useful it
I got that sort of error on 8.3.7 (can't upgrade really), is it
something that can be easily resolved ? I do understand that OID is
gone from the pg catalogue , but still in memory.
Will restart of database help in this case ? Was it fixed in
following revisions ?? (8.3.x, x7).
--
GJ
--
Having seen that all previous problems went unresolved, heres a bit
more info. The system is 32 bit, running on enterprise redhat 4.7. It
is slony's slave node, so it will be hit with quite few updates.
My guess is that it happened when we ere adding/removing slony to the
system for Nth time (due
2010/5/3 Peter Eisentraut pete...@gmx.net:
It was a convenient choice. You could propose a different method for
generating the specific routine name, but given that it has to fit into
an identifier and has to allow for function overloading, some kind of
number makes the most sense, in absence
2010/5/4 Peter Eisentraut pete...@gmx.net:
On tis, 2010-05-04 at 09:19 +0100, Grzegorz Jaśkiewicz wrote:
2010/5/3 Peter Eisentraut pete...@gmx.net:
It was a convenient choice. You could propose a different method for
generating the specific routine name, but given that it has to fit
On Tue, May 4, 2010 at 3:16 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, May 4, 2010 at 9:40 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Sat, May 1, 2010 at 4:14 PM, John R Pierce pie...@hogranch.com wrote:
If your 'natural key' is a large text field, I'd have to assume there's
the rule of thumb for me is:
- if you have more than one column as PK - and are variable length,
or more than 2 columns, fixed length, no bigger than 8 bytes - go for
surrogate - always.
- if PK is variable length, on average longer than 8 bytes, or can
change - go surrogate.
- Otherwise leave
why specific_name column on that view contains also OID ?
This makes two databases that are identical, have different values
there. Is there any specific reason for that ?
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
it tells you that it is not able to compare timestamp with text. Different
types. Cast if you have to explicitly.
--
GJ
however you are going to validate it, create yourself a domain for it
(custom type). That way, if it changes, you have to only update it in one
place, instead of doing it on column by column basis.
if you have a primary key on the table, and you should, you might get better
performance using LEFT JOIN.
EXCEPT will compare all columns, which might not be that fast, especially if
those are text. (hence why I always tell others to use int as key in a
table, but that's a different story).
--
a) you can't explicitly control transactions in plpgsql. If you need some
sort of a form of it, use save points.
b) you are trying to outsmart database software, and this is just a biiig
mistake, and you should stop doing that completely.
2010/4/1 Birgit Laggner birgit.lagg...@vti.bund.de
Hi Grzegorz,
sorry, but that doesn't help me, perhaps you could get a little bit
clearer:
@a) Does the use of SAVEPOINT avoid memory overflow? I could not find an
explanation about memory use in the documentation of SAVEPOINT.
create temporary table, insert your data, and than run update with join
against the table you wish to modify. And than drop your temp table.
simple.
you can't really do any updates sensibly unless you know what the relation
is. So, I kind of silently assume that you know that.
2010/3/23 Filip Rembiałkowski plk.zu...@gmail.com
For the record, I've recently observed such behaviour on non-cheap
64bit server harware.
That was Pg 8.4.0. hardware specs available on request.
EXPLAIN ANALYZE SELECT was over 2 times slower that SELECT. repeatedly.
Answering an
yes, if you really want to do it - analyze should be running following
cluster, as it moves data around.
plus, with 8.4 autovacuum should do the job.
altho not an answer to your question, you might want to start using table
name aliases, to make queries more readable.
so instead of:
SELECT dsclient_logs.ev_id,dsclient_
logs.type,to_timestamp(dsclient_logs.ev_time)
as
the reason you are using joins, most often is because your schema is
normalized. One way or another, de-normalisation + queries will cost you
more, than normalised tables and joins.
That's at least the short answer.
select count(*) AS count, error, ev_text FROM clients_event_log GROUP BY
error, ev_text;
you can add 'HAVING count(*) X'; , if you want to see only those with
count above X, etc.
--
GJ
just try if it does what you want it to do ;)
do a vacuum analyze verbose on it, and see if it complains about FSM (free
space map) setting. Which it probably will be.
don't use 'NOT EXISTS', as this will be damn slow. Use LEFT JOIN.
all statements in postgresql are self contained transactions, and you cannot
change that.
To answer your question directly, you don't have to, it will all be a
transaction.
The best example of that is to run following query in psql:
CREATE TEMP TABLE foo() ON COMMIT DROP;
the table will not
use $$
Or you can always use double single quotes, which is going to
translate into single one, ie : blah = 'foo '' bar';
will give you foo ' bar string.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Fri, Feb 5, 2010 at 1:29 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
In your case, by using ''Cote dIvoire''.
single quotes for string literals. So again: 'Cote d''lvoire'.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
try reindexing table.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
SET client_min_messages = error;
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/1/23 Craig Ringer cr...@postnewspapers.com.au:
An InnoDB `AUTO_INCREMENT' column under MySQL 5.x is pretty similar to a
sequence.
I increasingly think it's pretty safe to just
's/AUTO_INCREMENT/SERIAL/g'
in DDL. Apps that use MyISAM aren't going to be fussy about how it works,
and
2010/1/22 John Mitchell mitchellj...@gmail.com:
When is the new version of postgres (8.5) scheduled to be released as the
latest stable version?
there will be no 8.5.
It was decided to name it 9.0.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
and to answer the question of the release date, I believe sometime
around summer holiday.
There is a schedule, but in reality things usually slip by couple
weeks, especially when you add quite few not so trivial patches like
replication.
--
Sent via pgsql-general mailing list
On Fri, Jan 22, 2010 at 7:15 PM, Erik Jones ejo...@engineyard.com wrote:
Hello,
Given that the EU has approved Oracle's acquisition of Sun w/ MySQL it's
fairly likely that there may be a number of people and companies looking to
move from MySQL to Postgres in the coming months. Does anyone
http://www.pubbs.net/pgsql/201001/16503/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/1/21 Vincenzo Romano vincenzo.rom...@notorand.it:
And, BTW:
EXECUTE 'INSERT INTO '||partition-table-name||' SELECT $1.*' USING NEW;
won't work on 8.3 where I need it however :)
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
1 - 100 of 486 matches
Mail list logo
