Re: [BUGS] Prepared Statement Name Truncation - Mailing list pgsql-general

From David Johnston
Subject Re: [BUGS] Prepared Statement Name Truncation
Date
Msg-id 20152C83-CD88-4725-A790-0B32305751AE@yahoo.com
Whole thread Raw
In response to Re: [BUGS] Prepared Statement Name Truncation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] Prepared Statement Name Truncation  (Gavan Schneider <pg-gts@snkmail.com>)
List pgsql-general
On Nov 18, 2012, at 2:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Greg Sabino Mullane" <greg@turnstep.com> writes:
>>> If it's a postgres bug, what is the fix? Make the identifier max size
>>> longer?
>
>> I'd also be in favor of this, in addition to upgrading from a NOTICE.
>
> On the whole I'm not too excited about changing this.
>

Then I'd agree with the OP and think the notice should go away on usage in DML; though it should be kept for DDL.

Can the system be made smart enough to not allow intra-schema collisions in addition to same schema ones?  That would
seemto be the area of greatest concern - particularly around the usage of truncate/delete/drop. 

Thought: would there be some way to flag a table like this to always require the use of a schema prefix to be accessed
(sinceright now truncated names only have to be schema unique) in certain conditions (drop, delete, truncate)? 

David J.


pgsql-general by date:

Previous
From: Chris Angelico
Date:
Subject: Re: PG_TERMINATE_BACKEND not working.
Next
From: Vick Khera
Date:
Subject: Re: Difference between varchar and text?