Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Дата
Msg-id CAFj8pRButqSCthq4gRCjRBn_m9A++vz_3kZBGWKWcK_S3icQ8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Thoughts on "SELECT * EXCLUDING (...) FROM ..."?  (Eric Ridge <eebbrr@gmail.com>)
Ответы Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?  (Eric Ridge <eebbrr@gmail.com>)
Список pgsql-hackers
2011/11/1 Stephen Frost <sfrost@snowman.net>:
> * Marti Raudsepp (marti@juffo.org) wrote:
>> Unfortunately it's far less efficient. Fields would be truncated in
>> psql, so full values are still detoasted and transmitted over the
>> network.
>
> I'm thinking that we're not too worried about performance of ad-hoc
> psql queries..?  At least, for the queries that I'd use this for, I
> wouldn't be worried about that.
>
> The various syntax proposals do seem overly long for this, however..  I
> was just wondering about something like:
>
> select ~* blah, blah, blah FROM ...
>
> Strikes me as pretty unlikely that making a new 'version' of * like this
> is going to break anything or be broken by the SQL standard.  Note- I
> haven't looked at the * production or tried to do anything w/ gram.y to
> support this yet, but it's a heck of a lot shorter..
>

some other idea - but only for psql

we can define a special values, that ensure a some necessary
preexecution alchemy with entered query

\pset star_exclude_names col1, col2, col3
\pset star_exclude_types xml, bytea, text(unlimited)

select * from ...

1) get result descriptor from query
2) update a query to SELECT expected_columns FROM (original query) x
3) eval new query

point1 1,2,3 will be transparent for user and it has not any performance issue

Regards

Pavel


>        Thanks,
>
>                Stephen
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk6wGEsACgkQrzgMPqB3kii8fwCeM0TR8eeVsETjs8TEfi04mDvs
> nwEAoJ1I58IGUdRjJvRZPBaYLkQF3PiF
> =BPha
> -----END PGP SIGNATURE-----
>
>


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Compiler branch prediction hints (was: So, is COUNT(*) fast now?)
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Hot Backup with rsync fails at pg_clog if under load