On Wed, Nov 8, 2017 at 12:41 AM, Alvaro Herrera wrote:
> Sachin Kotwal wrote:
>> 3. Notify or highlight these changes in release notes because this can
>> break some existing tools and user code.
>
> Notifying people when their tools no longer work with a new server is
> not the problem; they figu
Sachin Kotwal wrote:
> 3. Notify or highlight these changes in release notes because this can
> break some existing tools and user code.
Notifying people when their tools no longer work with a new server is
not the problem; they figure that out pretty quickly once they try the
new version. The p
On Mon, Nov 6, 2017 at 10:30 PM, Sachin Kotwal wrote:
>
> Please committers give their final view on this.
>
>
They, and others, have - its a "don't want".
IOW, don't expend any effort since that effort will have been wasted - not
that it would take zero effort to accomplish.
If there is an a
Hi,
It seems people worrying about failure of client side code after changes in
column names.
Melvin also mention that just change in one column was broken many things.
>
> > My intension is to improve naming conventions and increase naming string
> > where naming conventions are correct but m
Sachin Kotwal wrote:
> I believe these naming conventions will be at two levels:
>
> 1. Internal code of PostgreSQL , structures getting used internally
> 2. SQL/C functions get executed at the time of database initialization to
> create default objects and system catalogs.
>
>
> I will see how
On Mon, Nov 6, 2017 at 10:04 AM, Karsten Hilbert
wrote:
> On Mon, Nov 06, 2017 at 08:23:07PM +0530, Sachin Kotwal wrote:
>
> > You are right. Those naming conventions are old and that is why we have
> to
> > improve those where ever and when ever required.
>
> I'd love to see the "requirement" de
On Mon, Nov 06, 2017 at 08:23:07PM +0530, Sachin Kotwal wrote:
> You are right. Those naming conventions are old and that is why we have to
> improve those where ever and when ever required.
I'd love to see the "requirement" defined.
Regards,
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyserv
Hi Tom,
You are right. Those naming conventions are old and that is why we have to
improve those where ever and when ever required.
If no one has objection, I will give a try to improve this part.
I believe these naming conventions will be at two levels:
1. Internal code of PostgreSQL , struc
>Those naming conventions are twenty-five years old, and there is an
>astonishing amount of client code that would break if we ran around
>changing existing system catalog column names. It's very unlikely that
>any proposal to do that would even receive serious consideration.
>The bar to using n
Sachin Kotwal writes:
> I can understand that it is important to maintain naming pattern same as
> system catalogs, but in that case we may need to redefine system catalogs
> naming conventions .
Those naming conventions are twenty-five years old, and there is an
astonishing amount of client code
Hi Peter,
I can understand that it is important to maintain naming pattern same as
system catalogs, but in that case we may need to redefine system catalogs
naming conventions .
So that we can use those newly added naming conventions in system views as
well.
It is difficult to understand usename
On 11/6/17 05:36, Sachin Kotwal wrote:
> Is there any special reason to keep column names as usesysid
> and usename instead of usersysid and username in below system View?
The reason to *keep* them is compatibility. The reason they are like
that to start with is because that is the naming pattern
Hi All,
Correcting my words.
Is there any special reason to keep column names as usesysid
and usename instead of usersysid and username in below system View?
On Mon, Nov 6, 2017 at 4:03 PM, Sachin Kotwal wrote:
> Hi All,
>
> Is there any reason to keep column names as usesysid and senate ins
13 matches
Mail list logo
