Re: Can we go beyond the standard to make Postgres radically better?

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Can we go beyond the standard to make Postgres radically better?
Дата
Msg-id CAFj8pRCD9SzLiUpaTZUMpfsSHp_mGtn+J+q6q_vjQqiYAdU1FQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Can we go beyond the standard to make Postgres radically better?  (Guyren Howe <guyren@gmail.com>)
Ответы Re: Can we go beyond the standard to make Postgres radically better?  (Mladen Gogala <gogala.mladen@gmail.com>)
Re: Can we go beyond the standard to make Postgres radically better?  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-general


ne 13. 2. 2022 v 10:45 odesílatel Guyren Howe <guyren@gmail.com> napsal:

The MySQL autocomplete is designed without context filtering. Maybe we can have this implementation too (as alternative)

so using all column names + all table names + aliases.column names (when we know defined alias)

Another idea about column excluding. Any implementation on the client side is very complex, because you need to parse sql. But maybe we can enhance SQL with some syntax.

SELECT ... and LAST optional clause can be HIDE, OR EXCLUDE NAME or EXCLUDE TYPE

SELECT * FROM postgistab HIDE TYPE LIKE 'wkb%'
SELECT * FROM postgistab ORDER BY ... EXCLUDE COLUMN LIKE 'shape%'

WITH x AS (SELECT * FROM xx)
SELECT * FROM x EXCLUDE COLUMN x1,x2

The column excluding should be separate *last* clase.

More with this syntax is less possibility of collision with ANSI SQL
Not against this. Seems somewhere in here might be a nice quality of life change.

Still.

I originally suggested that SQL is terrible and we should fearlessly either replace it or migrate it toward something better. And the thread winds up with a debate about a minor change to a development tool.

I’m back to just having no earthly idea why anyone who finds relations to be a productive tool for building a model would think that SQL being the only means to do that is Okay.

I think the rating of data langues is very subjective, and I am happy with SQL more than with special languages like D or Quel, or other. I know SQL has a lot of disadvantages, but it was designed for humans and it works for me.

I don't think using a special query language needs some special interface in Postgres. You can use COBOL with SQL databases today, The overhead of some middle layers should be low.

But there can be a valid second question - it can be nice to use extensions with availability to define their own communication protocol. Postgres has a special protocol for replication or for backup. With this possibility you can do what you need without the necessity of an external application server.

Regards

Pavel

 

SMH.

В списке pgsql-general по дате отправления:

Предыдущее
От: Guyren Howe
Дата:
Сообщение: Re: Can we go beyond the standard to make Postgres radically better?
Следующее
От: Torsten Förtsch
Дата:
Сообщение: Re: How to split normal and overtime hours