-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Jan 26, 2008 at 07:32:35PM +0100, Ivan Voras wrote:
> Andrew Dunstan wrote:
[...]
> >Or you could use an hstore (see contrib).
>
> Doesn't seem applicable.
Have a closer look: it might :-)
regards
- -- tomás
-BEGIN PGP SIGNATURE-
Ver
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > iirc, the suggestion was to exclude the non-SQL-spec things from 'GRANT
> > ALL' to avoid just that issue. Having to grant TRUNCATE and/or DDL
> > operation permissions explicitly would be reasonable. This might
Ivan,
have you seen contrib/hstore ? It's perl-like hash data type and can be
ideally suited for you.
Oleg
On Sat, 26 Jan 2008, Ivan Voras wrote:
Andrew Dunstan wrote:
Why not create the audit tables with composite types rather than strings?
create table audit_foo_table as (who text, whe
Tom Lane wrote:
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
On 26/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
Although this won't work at the SQL level in 8.1, I think you might be
able to accomplish the equivalent within plpgsql by assigning the
rowtype value to a text variable.
you lost n
On Sat, 2008-01-26 at 11:19 -0500, Robert Treat wrote:
> On Friday 25 January 2008 06:40, Simon Riggs wrote:
> > Notes: As the syntax shows, these would be statement-level triggers
> > (only). Requesting row level triggers will cause an error. [As Chris
> > Browne explained, if people really want,
Stephen Frost <[EMAIL PROTECTED]> writes:
> iirc, the suggestion was to exclude the non-SQL-spec things from 'GRANT
> ALL' to avoid just that issue. Having to grant TRUNCATE and/or DDL
> operation permissions explicitly would be reasonable. This might create
> a disconnect with what 'revoke all'
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> On 26/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Although this won't work at the SQL level in 8.1, I think you might be
>> able to accomplish the equivalent within plpgsql by assigning the
>> rowtype value to a text variable.
> you lost names :(.
* Tom Lane ([EMAIL PROTECTED]) wrote:
> There are also some compatibility concerns involved. If we add
> grantable privileges for TRUNCATE and/or DDL operations, then GRANT ALL
> ON TABLE suddenly conveys a whole lot more privilege than it did before.
> This could lead to unpleasant surprises in s
On 26/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> Ivan Voras <[EMAIL PROTECTED]> writes:
> > Andrew Dunstan wrote:
> >> Or you could possibly use some of the XML support in 8.3 for serialization.
>
> > I need this for 8.1 :)
>
> There's an even easier way in 8.3: just cast the rowtype to text.
>
Ivan Voras <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Or you could possibly use some of the XML support in 8.3 for serialization.
> I need this for 8.1 :)
There's an even easier way in 8.3: just cast the rowtype to text.
regression=# select row(1,2,false)::text;
row
-
Andrew Dunstan wrote:
Why not create the audit tables with composite types rather than strings?
create table audit_foo_table as (who text, when timestamptz, old foo,
new foo);
Because this would lead to having a log/shadow/audit table for every
table I wish to log. (or is there an opaque
Stephen Frost <[EMAIL PROTECTED]> writes:
> Of course, the last time this went around the argument was that we
> shouldn't add alot of extra code until we actually needed to, while at
> the same time we shouldn't use up the few remaining bits we have. The
> fact that this makes for an impossible s
Robert Treat <[EMAIL PROTECTED]> writes:
> This seems to completly hand-wave away the idea of implementing row level
> visibility in statement level triggers, something I am hoping to see
> implemented somewhere down the line. Am I missing something?
That was discussed already --- we agreed that
Pavel Stehule wrote:
Hello,
use plperl.
I'd like something more light-weight to reduce complexity of deployment.
Something in pgplsql would be ideal. Is there a way to simply iterate
over the fields of a row and retrieve field names and values?
PostgreSQL hasn't simple tool for it. Maybe
Ivan Voras wrote:
Hi,
I'd like to implement some simple data logging via triggers on a small
number of infrequently updated tables and I'm wondering if there are
some helpful functions, plugins or idioms that would serialize a row
(received for example in a AFTER INSERT trigger) into a stri
Hello,
use plperl.
PostgreSQL hasn't simple tool for it. Maybe this link will be usefull for you
http://www.ciselant.de/projects/pg_ci_diff/
Pavel
On 26/01/2008, Ivan Voras <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'd like to implement some simple data logging via triggers on a small
> number of i
Hi,
I'd like to implement some simple data logging via triggers on a small
number of infrequently updated tables and I'm wondering if there are
some helpful functions, plugins or idioms that would serialize a row
(received for example in a AFTER INSERT trigger) into a string that I'd
store in
On Friday 25 January 2008 10:11, Andrew Dunstan wrote:
> Florian Weimer wrote:
> > This doesn't work because '\' is turned into '\\' by PostgreSQL, and
> > not '\134':
> >
> > my $arg = shift;
> > $arg =~ s!\\(\d{3})!chr(oct($1))!ge;
> >
> > Something like this might be better:
> >
> >
On Sat, Jan 26, 2008 at 04:33:53PM +, Gregory Stark wrote:
> "Robert Treat" <[EMAIL PROTECTED]> writes:
>
> > the idea of implementing row level visibility in statement level triggers
>
> Huh?
I think he means that statement level triggers can see the rows that
got affected, presumably by NE
Robert Treat wrote:
On Friday 25 January 2008 06:40, Simon Riggs wrote:
Notes: As the syntax shows, these would be statement-level triggers
(only). Requesting row level triggers will cause an error. [As Chris
Browne explained, if people really want, they can use these facilities
to create a B
"Robert Treat" <[EMAIL PROTECTED]> writes:
> the idea of implementing row level visibility in statement level triggers
Huh?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
---(end of broadc
On Friday 25 January 2008 06:40, Simon Riggs wrote:
> Notes: As the syntax shows, these would be statement-level triggers
> (only). Requesting row level triggers will cause an error. [As Chris
> Browne explained, if people really want, they can use these facilities
> to create a Before Statement tr
thank you :)
> -Original Message-
> From: Robert Treat [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 26, 2008 4:29 PM
> To: pgsql-hackers@postgresql.org
> Cc: Gevik Babakhani
> Subject: Re: [HACKERS] PostgreSQL Programmer's Guide Books
>
> On Friday 25 January 2008 19:02, Gevik Ba
On Friday 25 January 2008 19:02, Gevik Babakhani wrote:
> Hi,
>
> I was wondering how accurate there books are (perhaps not so much) , if one
> wants to learn more about the internals?
> http://www.postgresql.org/docs/7.3/static/programmer.html
> http://www.cs.helsinki.fi/u/laine/postgresql/program
Hello,
there is one implementation of variadic functions. The base premis is
transformation type:
anyparams -> n x any
anyelements -> n x anyelement
Currently variadic functions can be only in C language. PL/pgSQL
cannot access to array of params. I implented some JSON functions
(based on Bauman
25 matches
Mail list logo
