Hi
I want to do a generic function that I can add to triggers to add every
inserts, updates and deletes from many differents tables into a common
format in another table. the idea is :
create function do_it_all () returns opaque '
begin
IF TG_OP = ''INSERT'' THEN
cycle through all of NEW
hallo somebody,
what do the functions encode and decode expect as arguments ?
I was puzzled when I got the following:
pgdocsample=# \encoding
SQL_ASCII
pgdocsample=# select decode('hallo','SQL_ASCII');
ERROR: No such encoding as 'SQL_ASCII'
What have I understood wrong ?
Fritz
Fritz Lehmann-Grube wrote:
hallo somebody,
what do the functions encode and decode expect as arguments ?
test= \df decode
List of functions
Result data type | Schema | Name | Argument data types
OK, no one has commented on this, so I guess I am going to have to guess
the group's preference.
My guess, seeing as very few probably use LIMIT and FOR UPDATE together,
is to swap them and document it in the release notes. Was I correct in
my guess?
This is what I did:
1: I reinstalled postgresql RPMs from scratch (I removed all the logs,
data files, backup files)
2: su root
3: su postgres
4: psql template1
And here I got the error message:
psql: FATAL 1: IDENT authentication failed for user foobar
User foobar was an old user I
Bruce Momjian [EMAIL PROTECTED] writes:
My guess, seeing as very few probably use LIMIT and FOR UPDATE together,
is to swap them and document it in the release notes.
That will surely piss someone off. Can't you try a little harder to
support either order?
regards,
On Tue, 2002-08-27 at 17:07, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
My guess, seeing as very few probably use LIMIT and FOR UPDATE together,
is to swap them and document it in the release notes.
That will surely piss someone off. Can't you try a little harder to
support
Wei Weng [EMAIL PROTECTED] writes:
What could have gone wrong? I must have left the trace of user foobar
somewhere in my system but I couldn't find it.
PGUSER environment variable?
regards, tom lane
---(end of
Mathieu,
The thing I need, is to be able to know what does NEW contains, and I have
not found out any mean to do so. If it's not possible to do so, I'll write
a function per table, but for the beauty of all this, I would have liked to
do it the way above.
You can't do this in PL/pgSQL.
Yes we did. By the way, how often is it recomended?
Ligia
mark carew [EMAIL PROTECTED] wrote in message
akgr6p$vp2$[EMAIL PROTECTED]">news:akgr6p$vp2$[EMAIL PROTECTED]...
Hi Ligia,
Are you running VACUUM ANALYSE or is it VACUUM ANALYZE (can never
remember, though reasonably sure that its
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
My guess, seeing as very few probably use LIMIT and FOR UPDATE together,
is to swap them and document it in the release notes.
That will surely piss someone off. Can't you try a little harder to
support either order?
Sure. I just
OK, no one has commented on this, so I guess I am going to have to guess
the group's preference.
My guess, seeing as very few probably use LIMIT and FOR UPDATE together,
is to swap them and document it in the release notes. Was I correct in
my guess?
I'm sure very few people do it - but
Folks,
I'm having a problem with:
SELECT date_part('epoch','2002-08-28'::TIMESTAMP)
Which is consistently returning an epoch timestamp that evaluates to
8.27.2002. Is this a known issue? A cross-platform problem?
Suggestions?
-Josh Berkus
---(end of
Josh Berkus [EMAIL PROTECTED] writes:
I'm having a problem with:
SELECT date_part('epoch','2002-08-28'::TIMESTAMP)
Which is consistently returning an epoch timestamp that evaluates to
8.27.2002. Is this a known issue? A cross-platform problem?
In 7.2 I get:
regression=# SELECT
14 matches
Mail list logo
