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
>
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
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
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
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
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
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 @
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 ,
>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
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
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
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
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
Hi All,
Is there any reason to keep column names as usesysid and senate instead of
usersysid and username ?
postgres=# select * from pg_stat_replication ;
pid | usesysid | usename | application_name | client_addr |
client_hostname | client_port | backend_start |
14 matches
Mail list logo