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 cr
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
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 broadcast)-
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 t
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
> 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 -
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 broadcast)
What if you try this:
SELECT date_part('epoch','2002-08-28'::TIMESTAMP WITH TIME ZONE)
It's probably 8 hours time different to GMT or somethign like that...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Josh Berkus
> Sent: Wednesday, 28 A
"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 da
--On mardi 27 août 2002 15:38 -0700 Josh Berkus <[EMAIL PROTECTED]> wrote:
>
> 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
16 matches
Mail list logo