From: | Jason Dusek <jason(dot)dusek(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: regclass and format('%I') |
Date: | 2015-03-15 02:09:44 |
Message-ID: | CAO3NbwP9dKQ=tYGjDFFKD6Pza60YjZoEKNA2w0YFfXUuO9zR_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 14 March 2015 at 09:17, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Saturday, March 14, 2015, Jason Dusek <jason(dot)dusek(at)gmail(dot)com> wrote:
>> It honestly seems far more reasonable to me that %s and %I should do
>> the exact same thing with regclass. My reasoning is as follows:
>>
>> ‘%I’ formats a something such that it is a valid identifier,
>>
>> regclass is already a valid identifier,
>>
>> therefore, do nothing.
>>
>> Another line of reasoning:
>>
>> If you format with ‘%s’ you are saying: I don’t care whether it’s a
>> valid identifier or literal or whatever, just put the string there,
>>
>> but when we sub a regclass into a string, we want it to be a valid
>> identifier,
>>
>> therefore we should write ‘%I’ when subbing it, so as not to confuse
>> our readers,
>>
>> therefore ‘%I’ should do nothing.
>>
>
> I agree with the theory but adding type specific logic to format is going to
> be difficult. The first thing the system does is convert all of the inputs
> to text. Inside format() everything is text and so it has no way to know
> that the type was regclass and should not be quoted again.
Could it work to add type-specific logic for the cast from `regclass`
to `name`? It would be nice to have something formulaic: always format
identifiers with `%I`, always cast to `name` before formatting.
Kind Regards,
Jason Dusek
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-03-15 05:20:20 | Re: regclass and format('%I') |
Previous Message | Denver Timothy | 2015-03-15 00:21:27 | Unexpected custom type behavior using ROW(NULL) |