Re: [SQL] Trigger functions with dynamic SQL

Andreas Haumer <[EMAIL PROTECTED]> writes: > I just can't figure out where and how many quotation marks > I have to place in my function. It's messy all right. The "dollar quoting" feature in 7.5 should make it a lot less painful, since you can stop having to double and re-double quote marks. If

Re: [SQL] Trigger functions with dynamic SQL

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Many thanks for your reply! Tom Lane wrote: > Andreas Haumer <[EMAIL PROTECTED]> writes: > >>It seems I would have to use EXECUTE on dynamically constructed >>PL/PGSQL statements in order to have my trigger function recognize >>the parameters giv

Re: [SQL] Trigger functions with dynamic SQL

Andreas Haumer <[EMAIL PROTECTED]> writes: > It seems I would have to use EXECUTE on dynamically constructed > PL/PGSQL statements in order to have my trigger function recognize > the parameters given to the trigger in TG_ARGV[] Yup, that's exactly right. plpgsql isn't designed for this; it's des

Re: [SQL] Is a backend id or something available for use as a foreign key?

Markus Bertheau <[EMAIL PROTECTED]> writes: > Is there a backend id available or something similar that would allow > me to define a view like this: IIRC there is a function to get your backend's PID. It was meant for identifying rows relevant to you in the pg_stat views, so look in that part of

[SQL] Trigger functions with dynamic SQL

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I could use some help in writing PL/PGSQL trigger functions with dynamic SQL statements. The problem is not exactly an easy one but I hope it is of general interest to this list :-) I'm currently working on a database with several temporal tables

Re: [SQL] surrogate key or not?

Josh Berkus wrote: > Given: Surrogate keys, by definition, represent no real data; > Given: Only items which represent real data have any place in > a data model > Conclusion: Surrogate keys have no place in the data model But, once a surrogate key is assigned to a row, doesn't it become

[SQL] Is a backend id or something available for use as a foreign key?

Hi, I have this application which has various users. I want the results of functions to depend on which user is currently logged on. The usual reply to this is to use CURRENT_USER. But in my case the application's users are separate from the database users; the application always uses the same use

Re: [SQL] surrogate key or not?

Just for the record, the GnuMed schema docs are done nightly with PostgreSQL Autodoc in HTML mode: http://www.rbt.ca/autodoc/ Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ---(end of broadcast)

Re: [SQL] surrogate key or not?

On Fri, Jul 23, 2004 at 10:07:48AM -0400, Tom Lane wrote: > The other standard reason for using a made-up value as primary key is > that it's under your control and you can guarantee it isn't going to > change: one record will have the same primary key for its entire life, > which vastly simplifie

Re: [SQL] surrogate key or not?

Josh, > > In other words, with surrogate keys, you eliminate the chance > > that your original design was flawed due to lack of important > > initial knowledge. > > Well, you don't *eliminate* it, but you do decrease it. > > I'd say, yes, this is an important 4th reason: > > 4) Your spec