[7.4] "permissions problem" with pl/pgsql function

Lists: pgsql-hackers
From: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: [7.4] "permissions problem" with pl/pgsql function
Date: 2004-01-19 19:47:05
Message-ID: 20040119154535.L15422@ganymede.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


Just had a client point this out to me, and am wondering if its supposed
to happen:

420_test=> select
dropgeometrycolumn('420_test','lroadline61','roads61_geom');
ERROR: permission denied for relation pg_attribute
CONTEXT: PL/pgSQL function "dropgeometrycolumn" line 19 at execute statement

the database was created as:

CREATE DATABASE <db> WITH OWNER = <owner>

and I'm connected to the database as the owner ... shouldn't the "system
tables" also be owned by the owner?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [7.4] "permissions problem" with pl/pgsql function
Date: 2004-01-19 20:29:45
Message-ID: 10240.1074544185@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> Just had a client point this out to me, and am wondering if its supposed
> to happen:

> 420_test=> select
> dropgeometrycolumn('420_test','lroadline61','roads61_geom');
> ERROR: permission denied for relation pg_attribute
> CONTEXT: PL/pgSQL function "dropgeometrycolumn" line 19 at execute statement

Can't tell much about this without seeing the contents of the function ...
in particular, what SQL command is it trying to execute when it chokes?

regards, tom lane


From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [7.4] "permissions problem" with pl/pgsql function
Date: 2004-01-20 00:22:56
Message-ID: 400C74E0.4050205@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


> 420_test=> select
> dropgeometrycolumn('420_test','lroadline61','roads61_geom');
> ERROR: permission denied for relation pg_attribute
> CONTEXT: PL/pgSQL function "dropgeometrycolumn" line 19 at execute statement
>
> the database was created as:
>
> CREATE DATABASE <db> WITH OWNER = <owner>
>
> and I'm connected to the database as the owner ... shouldn't the "system
> tables" also be owned by the owner?

No, you have to have the usecatupd field set to true in your pg_shadow
row to be able to modify the catalogs. This is automatically assigned
to a superuser, not the database owner. (Otherwise it's trivial to munt
someone else's database by deleting from pg_database or pg_shadow...)

Chris


From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: PostGIS dropgeometrycolumn function (Was: Re: [7.4] "permissions problem" with pl/pgsql function )
Date: 2004-01-20 16:13:23
Message-ID: 20040120120838.G15422@ganymede.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Mon, 19 Jan 2004, Tom Lane wrote:

> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> > Just had a client point this out to me, and am wondering if its supposed
> > to happen:
>
> > 420_test=> select
> > dropgeometrycolumn('420_test','lroadline61','roads61_geom');
> > ERROR: permission denied for relation pg_attribute
> > CONTEXT: PL/pgSQL function "dropgeometrycolumn" line 19 at execute statement
>
> Can't tell much about this without seeing the contents of the function ...
> in particular, what SQL command is it trying to execute when it chokes?

The function is executing:

EXECUTE ''update pg_attribute set attnotnull = false from pg_class where
pg_attribute.attrelid = pg_class.oid and pg_class.relname = '' ||
quote_literal(table_name) ||'' and pg_attribute.attname = '' ||
quote_literal(column_name);

I'm going to hit up the PostGis folks, since right at the top of the
function it stats:

-- There is no ALTER TABLE DROP COLUMN command in postgresql
-- There is no ALTER TABLE DROP CONSTRAINT command in postgresql
-- So, we:
-- 1. remove the unwanted geom column reference from the
-- geometry_columns table
-- 2. update the table so that the geometry column is all NULLS
-- This is okay since the CHECK srid(geometry) = <srid> is not
-- checked if geometry is NULL (the isstrict attribute on srid())
-- 3. add another constraint that the geometry column must be NULL
-- This, effectively kills the geometry column
-- (a) its not in the geometry_column table
-- (b) it only has nulls in it
-- (c) you cannot add anything to the geom column because it must be NULL
--
-- This will screw up if you put a NOT NULL constraint on the geometry
-- column, so the first thing we must do is remove this constraint (its a
-- modification of the pg_attribute system table)
--
-- We also check to see if the table/column exists in the geometry_columns
-- table

Anyone on this list working with the PostGis development team?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4] "permissions problem" with pl/pgsql function )
Date: 2004-01-20 16:36:26
Message-ID: 24549.1074616586@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> On Mon, 19 Jan 2004, Tom Lane wrote:
>> in particular, what SQL command is it trying to execute when it chokes?

> The function is executing:

> EXECUTE ''update pg_attribute set attnotnull = false from pg_class where
> pg_attribute.attrelid = pg_class.oid and pg_class.relname = '' ||
> quote_literal(table_name) ||'' and pg_attribute.attname = '' ||
> quote_literal(column_name);

Well, no wonder. You have to be superuser to do that, and it's a pretty
bad idea even then.

We do have ALTER TABLE ... SET/DROP NOT NULL since 7.3, so hacking
pg_attribute directly isn't necessary for this anymore.

regards, tom lane


From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4]
Date: 2004-01-20 16:50:48
Message-ID: 20040120124911.F930@ganymede.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, 20 Jan 2004, Tom Lane wrote:

> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> > On Mon, 19 Jan 2004, Tom Lane wrote:
> >> in particular, what SQL command is it trying to execute when it chokes?
>
> > The function is executing:
>
> > EXECUTE ''update pg_attribute set attnotnull = false from pg_class where
> > pg_attribute.attrelid = pg_class.oid and pg_class.relname = '' ||
> > quote_literal(table_name) ||'' and pg_attribute.attname = '' ||
> > quote_literal(column_name);
>
> Well, no wonder. You have to be superuser to do that, and it's a pretty
> bad idea even then.
>
> We do have ALTER TABLE ... SET/DROP NOT NULL since 7.3, so hacking
> pg_attribute directly isn't necessary for this anymore.

So, if we replace that with:

ALTER TABLE table_name ALTER column_name DROP NOT NULL; ?

should be good to go? still not as clean as doing the straight DROP
COLUMN, but its a fast fix ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4] "permissions problem" with pl/pgsql function )
Date: 2004-01-20 17:07:42
Message-ID: 24754.1074618462@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> So, if we replace that with:
> ALTER TABLE table_name ALTER column_name DROP NOT NULL; ?
> should be good to go? still not as clean as doing the straight DROP
> COLUMN, but its a fast fix ...

Yeah, that's what I'd do until the PostGIS guys can rethink things at a
higher level.

regards, tom lane


From: Paul Ramsey <pramsey(at)refractions(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4]
Date: 2004-02-03 18:17:54
Message-ID: 490D4511-5675-11D8-B42D-000393D33C2E@refractions.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

One of the great annoyances of the OpenGIS spec is the requirement for
a "geometry_columns" table, that has a list of all the spatial columns
and a little bit of metadata on them (what type are they, what is the
spatial reference system of their coordinates, what is their
dimensionality).

Unfortunately, we have been reduced to "manually" maintaining this
table through the mechanism of the "AddGeometryColumn"
"DropGeometryColumn" functions. As you noted, we had some old scruft in
there dating back to the pre-DROP COLUMN days. That's gone in the
current version.

In an idea world though, we would construct the thing as a view, so
that when you did a CREATE TABLE that included a geometry type, you
would automatically get a row in geometry_columns. That requires a view
on system tables though, and that just does not work. :/

Any thoughts on a nice implementation?

Paul

On Tuesday, January 20, 2004, at 09:07 AM, Tom Lane wrote:

> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
>> So, if we replace that with:
>> ALTER TABLE table_name ALTER column_name DROP NOT NULL; ?
>> should be good to go? still not as clean as doing the straight DROP
>> COLUMN, but its a fast fix ...
>
> Yeah, that's what I'd do until the PostGIS guys can rethink things at a
> higher level.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo(at)postgresql(dot)org
>
Paul Ramsey
Refractions Research
Email: pramsey(at)refractions(dot)net
Phone: (250) 885-0632


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Ramsey <pramsey(at)refractions(dot)net>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4] "permissions problem" with pl/pgsql function )
Date: 2004-02-03 19:00:39
Message-ID: 29877.1075834839@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Paul Ramsey <pramsey(at)refractions(dot)net> writes:
> In an idea world though, we would construct the thing as a view, so
> that when you did a CREATE TABLE that included a geometry type, you
> would automatically get a row in geometry_columns. That requires a view
> on system tables though, and that just does not work. :/

Uh, what makes you say it doesn't work?

regards, tom lane


From: Paul Ramsey <pramsey(at)refractions(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, dblasby(at)refractions(dot)net
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4]
Date: 2004-02-03 19:13:39
Message-ID: 13173ADF-567D-11D8-B42D-000393D33C2E@refractions.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bitter experience... I am going to cc Dave here, because I could swear
we went through many conniptions trying to make this work.

And yet I just did this:

create view mytables as select relname from pg_class where relam = 0
and relname not like 'pg_%';

And it seems to work fine.

Oh, now I remember. The deal was not views, it was triggers. Since our
geometry_columns contains some information not available via a query on
existing data, a trigger was what we wanted, so we could harvest the
information from a variety of places, and have some spare columns for
things like the geometry selectivity stats.

Paul

On Tuesday, February 3, 2004, at 11:00 AM, Tom Lane wrote:

> Paul Ramsey <pramsey(at)refractions(dot)net> writes:
>> In an idea world though, we would construct the thing as a view, so
>> that when you did a CREATE TABLE that included a geometry type, you
>> would automatically get a row in geometry_columns. That requires a
>> view
>> on system tables though, and that just does not work. :/
>
> Uh, what makes you say it doesn't work?
>
> regards, tom lane
>
Paul Ramsey
Refractions Research
Email: pramsey(at)refractions(dot)net
Phone: (250) 885-0632


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Ramsey <pramsey(at)refractions(dot)net>
Cc: dblasby(at)refractions(dot)net, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4] "permissions problem" with pl/pgsql function )
Date: 2004-02-03 20:06:10
Message-ID: 738.1075838770@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Paul Ramsey <pramsey(at)refractions(dot)net> writes:
> Oh, now I remember. The deal was not views, it was triggers.

Oh, okay. You're right, we don't do triggers on system tables. But
couldn't you combine a view on the system tables with storage of
additional data outside?

regards, tom lane


From: Paul Ramsey <pramsey(at)refractions(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>
Cc: dblasby(at)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: PostGIS Integration
Date: 2004-02-03 20:19:56
Message-ID: 55A45278-5686-11D8-B42D-000393D33C2E@refractions.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Actually, in my wet dream, we stored everything in system tables.
Dimensionality and SRID became parameters of the geometry, the
selectivity stats lived in the system stats table (as Mark's patch
should hopefully do) and the geometry_columns view just pulled
everything together into one user-convenient location.

CREATE TABLE foo ( mygeom POLYGON(4326) );
CREATE TABLE bar ( mygeom MULTILINESTRING(20711, 2 ) );

I think we had this discussion before though, and the "parameterized"
types, like varchar(256), were not available for extended types, like
our geometries.

P.

On Tuesday, February 3, 2004, at 12:06 PM, Tom Lane wrote:

> Paul Ramsey <pramsey(at)refractions(dot)net> writes:
>> Oh, now I remember. The deal was not views, it was triggers.
>
> Oh, okay. You're right, we don't do triggers on system tables. But
> couldn't you combine a view on the system tables with storage of
> additional data outside?
>
> regards, tom lane
>
Paul Ramsey
Refractions Research
Email: pramsey(at)refractions(dot)net
Phone: (250) 885-0632


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Ramsey <pramsey(at)refractions(dot)net>
Cc: Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>, dblasby(at)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS Integration
Date: 2004-02-03 23:03:16
Message-ID: 2543.1075849396@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Paul Ramsey <pramsey(at)refractions(dot)net> writes:
> I think we had this discussion before though, and the "parameterized"
> types, like varchar(256), were not available for extended types, like
> our geometries.

I can't see any way to handle parameterized types without extending the
grammar individually for each one --- otherwise it's too hard to tell
them apart from function calls. That makes it a bit hard to do 'em
as plug-ins :-(. The grammar hacks are certainly ugly though, and if
someone could think of a way, I'm all ears...

regards, tom lane


From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Paul Ramsey <pramsey(at)refractions(dot)net>, Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>, dblasby(at)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS Integration
Date: 2004-02-04 07:01:20
Message-ID: 402098C0.2050100@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> I can't see any way to handle parameterized types without extending the
> grammar individually for each one --- otherwise it's too hard to tell
> them apart from function calls. That makes it a bit hard to do 'em
> as plug-ins :-(. The grammar hacks are certainly ugly though, and if
> someone could think of a way, I'm all ears...

Disallow it in table definitions, but allow it in domain definitions...

Chris


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Paul Ramsey <pramsey(at)refractions(dot)net>, Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>, dblasby(at)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS Integration
Date: 2004-02-04 07:07:06
Message-ID: 7250.1075878426@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> I can't see any way to handle parameterized types without extending the
>> grammar individually for each one --- otherwise it's too hard to tell
>> them apart from function calls.

> Disallow it in table definitions, but allow it in domain definitions...

Those two cases are not hard, because in those scenarios the parser
knows it is expecting a type specification. The real problem is this
syntax for typed literals:
typename 'string'
which occurs in ordinary expressions. So when you see "name(" you
aren't real sure if you're seeing the start of a function call or the
start of a typed-literal construct. And it's very hard to postpone that
decision until you see what comes after the right paren.

regards, tom lane


From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Paul Ramsey <pramsey(at)refractions(dot)net>, Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>, dblasby(at)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS Integration
Date: 2004-02-04 07:23:08
Message-ID: 40209DDC.2080306@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> Those two cases are not hard, because in those scenarios the parser
> knows it is expecting a type specification. The real problem is this
> syntax for typed literals:
> typename 'string'
> which occurs in ordinary expressions. So when you see "name(" you
> aren't real sure if you're seeing the start of a function call or the
> start of a typed-literal construct. And it's very hard to postpone that
> decision until you see what comes after the right paren.

Just disallow that particular case for custom types :P

Will this work: 'string'::typename

Chris


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Paul Ramsey <pramsey(at)refractions(dot)net>, Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>, dblasby(at)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS Integration
Date: 2004-02-04 07:48:00
Message-ID: 7784.1075880880@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> Those two cases are not hard, because in those scenarios the parser
>> knows it is expecting a type specification. The real problem is this
>> syntax for typed literals:
>> typename 'string'

> Just disallow that particular case for custom types :P

Well, maybe we could --- comments? Tom Lockhart went to some lengths to
support that, but now that he's gafiated we could perhaps rethink it.
AFAICS the SQL spec only requires this syntax for certain built-in types.
Tom wanted to generalize that to all datatypes that Postgres supports,
and that seems like a reasonable goal ... but if it prevents getting to
other reasonable goals then we ought to think twice.

> Will this work: 'string'::typename

Yes, since the :: cues the parser to expect a typename next.

regards, tom lane


From: strk <strk(at)keybit(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Paul Ramsey <pramsey(at)refractions(dot)net>, Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>, dblasby(at)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostGIS Integration
Date: 2004-02-04 17:35:11
Message-ID: 20040204183511.A87894@freek.keybit.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

tgl wrote:
> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
> >> Those two cases are not hard, because in those scenarios the parser
> >> knows it is expecting a type specification. The real problem is this
> >> syntax for typed literals:
> >> typename 'string'
>
> > Just disallow that particular case for custom types :P
>
> Well, maybe we could --- comments? Tom Lockhart went to some lengths to
> support that, but now that he's gafiated we could perhaps rethink it.
> AFAICS the SQL spec only requires this syntax for certain built-in types.
> Tom wanted to generalize that to all datatypes that Postgres supports,
> and that seems like a reasonable goal ... but if it prevents getting to
> other reasonable goals then we ought to think twice.

If it's not for SQL conformance
I don't think we really need to generalize that.
As far as there are other means to gain the same result...

'string'::type(parameter) can be the "general" postgres version.
while varchar(2) 'string' can be the standard SQL version (not general).

--strk;

>
> > Will this work: 'string'::typename
>
> Yes, since the :: cues the parser to expect a typename next.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend